mbucchia

No that's something I put in my signature a while ago. I don't read DMs, but I come sometimes here and there and check out threads. FYI I no longer work in the VR industry and barely do any work any more on open source projects. ED had never censored me or treated me poorly for my posts. I speak my mind, sure. They probably would have cause sometimes to moderate my posts but they don't. I wish there had been a bit better listening from them. It's a bit late now since as I me mentioned I no longer have time for this stuff.

AMD doesn't support foveated rendering with DX11 apps. See the compatibility chart and documentation on the website.

Time will tell you if it breaks in some scenarios, I'd expect it will. I gave instructions like 2.5years ago to ED on how to make OpenXR Toolkit FR work, and guess what they did? The same thing they always did with anything I wrote to them: they ignored it. Even if it might work in today's update, good luck with next month update... Regardless, VRS foveated rendering (OpenXR Toolkit) will give you much much less of a gain than quad views, unless you have very little CPU headroom. You're not going to see the +50 +100% boosts of quad views. Perhaps +20% at best.

Edit: I shouldn't be ranting so I'll edit my post. Bottom line: please start holding the right people accountable instead of this false impression that you have. ED literally has a blatant BUG in their code. THAT is the problem, existing since Day 1 of DCS OpenXR support. Reported to them on many occasions in the last year and a half.

Please please please stop calling the unofficial build a "fix", because it is anything but a fix

But how do you think DCS loads this DLL? It is installed system-wide via a registry key (what we call "Implicit API layer loading"). Every single OpenXR game that launches will go and load that DLL, regardless of if it's DCS or of it uses quad views at all. There is no way to "filter" the loading of the DLL for each game. We have to cast the wider net - aka ALL OPENXR APPS - and them the API layer has detection logic for whether it is needed or not. The problem is that this detection logic is inside the DLL. So the lack of signing will make all OpenXR apps try to load the unsigned code, which will flag all anti-cheat software.

See the unsigned DLL will screw up ALL OpenXR games that have anti-cheat, regardless of whether these games use or not use quad views. It will make them fail in a way that will also pop up my name on the screen "failed to load XR_MBUCCHIA_quad_views...." aka pointing fingers at me This is why I'm not distributing the unsigned DLL. Some examples of games using OpenXR and Anti-cheat that will break with an unsigned DLL system-wide: Pavlov, WRC, Contractors Showdown, Roblox... In others words: people are going to copy this file, forget about it, then eventually they will run some game that will crash, point to me, and people will come and complain that I broke their games On top of that, PLEASE, we have to stop bailing out Eagle Dynamics. They wrote some buggy OpenXR code. They need to fix it. By having people adding more and more duct tape to "hide" their problems, we are removing their accountability and continuing to deepen the problem. They're not going to take this seriously and do the proper fix, if we keep bailing them out:

@BIGNEWY I am going to write this up one more time, especially since it looks like my message from March 2023 was partially lost. The following trace is captured today with DCS MT and quad views enabled on a Varjo. But it doesn't matter, it's the same issue with Pimax, Quest Pro, etc. The trace shows 2 consecutive OpenXR frames (xrBeginFrame -> xrEndFrame). As reminder, with quad views, per OpenXR 1.0 spec section 12.143.1 > The first two views (XrViewConfigurationView) will be for the left and right eyes for the outer viewport. The views 2 and 3 are for the left and right eyes for the inner viewport. This means in the trace below, when you are seeing 4 consecutive "xrEndFrame_View", the bottom two are for the inner viewport (the region that moves with your eye gaze). This trace clearly exhibits the bug in DCS frame submission code. The order of operation might look confusing at first: this is because in MT mode, the processing (on CPU) of frame N+1 begins before the processing (on both CPU and GPU) of frame N ends. 1) The top of the trace corresponds to frame N's pre-processing. Frame N has a predicted display time of 1000084542856849400, and the tracking data needed in order to render that frame is queried through the xrLocateViews() API call. This call returns the data necessary to compute projection matrices for all 4 viewports that need to be rendered. We observe, circled in green, the values for the FOV of the inner viewports. 2) Meanwhile, DCS performs rendering and submission of frame N-1, with a "display time" of 1000084542846147700. This is the xrEndFrame() call that we see in between the green and red annotations. We sort of don't care about frame N-1 here, so let's just move on to frame N and N+1 to understand the problem. 3) The engine is now going to perform two things in quick succession: it will begin pre-processing of frame N+1, through a call to xrLocateViews() similar to what we've already described, and it will render and submit frame N. Remember frame N: the one we pre-processed earlier, at the very top of the trace in 1). a) We see the call to xrLocateViews() for frame N+1, annotated in red, with a predicted time of 1000084542868214700, and that returns a new set of FOV values for the inner viewport: this is because the eye gaze moved between frame N and N+1. b) Right after that, the succession of xrBeginFrame+xrEndFrame() corresponds to frame N being rendered and submitted. You can see a jump in time of about 8ms... that's our frame time. We can tell this is the submission for frame N because we look at the value of "displayTime" circled in green, and it is the same value 1000084542856849400 that we saw being used in step 1). 4) Now here is the bug: when you look at the FOV values that DCS was returned in step 1) and computed its projection matrices with, and you compare them to the "UnpatchedFov" values that DCS is submitting in step 3)b), they are not the same. DCS is telling OpenXR: "you know the inner viewport you gave me earlier to render into? well I didn't use that! I used other values instead, so you will have to perform reprojection from the viewport I used into the viewport you need to display on screen". This reprojection causes the freaky glitches we are seeing. You can also observe next to these "UnpatchedFov" values, the "Fov" values that are the correct ones: this is the workaround that Varjo-Foveated and Quad-Views-Foveated implement to mask this bug. It keeps track of the displayTime used in 1), then it stores the FOV value and retrieve them in step 3)b) based on that same displayTime. This is the workaround that today is only enabled when XrInstanceCreateInfo.applicationInfo.applicationName is set to "DCS World" - the value you were passing for 1.5yr, and that today you changed to "DCS", which causes the workaround to not turn itself on. But what we need really, is DCS to submit the correct values here. Now to go even further into it, and to tell you exactly what line of code you need to look into, here the other observation: in step 3)b), instead of submitting the FOV values acquired for frame N in step 1), you are instead submitting the FOV values acquired in step 3)a) for frame N+1. This is the result of a very simple bug. As you can see looking at the Thread column, there are two threads working here: thread 32252 which is doing the pre-processing (xrLocateViews) and thread 27000 which is doing the rendering and submission. My guess is that your code is using a single set of a shared variable between the two threads to "carry" the XrPosef/XrFovf values from the calls to xrLocateViews() into the calls to xrEndFrame(). This approach is fine when you are doing single-threaded, sequential frame processing. But since here you get started on frame N+1 before frame N is submitted, you overwrite the content of the XrPosef/XrFovf that you have stashed between your two threads. Note that you do not have this problem for the value of the displayTime: you are correctly retrieving this value from xrWaitFrame(), passing it to xrLocateViews() on your pre-processing thread, and eventually carrying it into xrEndFrame(). So whatever logic you are doing today for the predictedDisplayTime/displayTime between your two threads, you want to replicate that logic for the XrPosef/XrFovf values as well. You need a latching mechanism for these values between the moment you use them for computing your projection matrices and to carry them along with your rendering into your submission thread, WITHOUT overwriting these values with the "most recent" values when you start pre-processing frame N+1.

All of the above would resolve your issue, but of course with the potential to reduce performance.

It's possible (but unlikely) that the game engine is now rendering left and right eye in a different order. I highly doubt this really works, all of the previous experiments with this showed that either FR wasn't really applied (no gain) or FR was incorrectly applied in certain situations (unexplained blurriness in the middle of the screen). For VRS to perform better than QVFR, you must have had extremely low CPU headroom, which isn't the case of the large majority of QVFR users.

To be very clear, the unsigned DLL will screw up ALL OpenXR games that have anti-cheat, regardless of whether these games use or not use quad views. It will make them fail in a way that will also pop up my name on the screen "failed to load XR_MBUCCHIA_quad_views...." aka pointing fingers at me This is why I'm not distributing the unsigned DLL. Some examples of games using OpenXR and Anti-cheat that will break with an unsigned DLL system-wide: Pavlov, WRC, Contractors Showdown, Roblox... EDIT: FYI this is the bill for getting a digital cert in 2024. Per year. We can thank the anti-cheat companies for that. I wish Epic and friends would pick up that bill... null

Appreciate that but obtaining a signing certificate would take like 2 weeks (the whole idea of it is that they verify you are the person who you say you are, so it's a slow process, sometimes might require to visite a notary). Then on top of it, there are several hours of work to setup the new signing process on the cloud. My hope is something that simple and easy will be fixed by then. Meanwhile there are multiple solutions: - Use DCS ST (single-threaded), make sure to run with `--force_OpenXR`) - If you are on Varjo, you can revert to using Varjo-Foveated instead of Quad-Views-Foveated.

I can't speak for ED, my guess is just like any software team, the more consuming part isn't the code change itself but the review, validation and rollout process that comes with it. From the code change itself, I don't know what their code looks like, but I can't imagine that them storing the proper FOV values (they retrieved from xrLocateViews() to compute the projection matrix) into a variable that follows the frame's lifetime until submission (via xrEndFrame()) would be complex. The code in QVFR and VFR does that, and it's something like 20-30 lines of code that were written in well under an hour.

Not a Varjo issue. DCS submits information incorrectly to OpenXR. My original post from March 2023 had a screenshot of the OpenXR calls that made the problem very obvious, but somehow the forum doesn't have the image anymore and it shows as a broken URL... Edit: ugh the broken link is my fault, my image file was hosted on Discord, and with the deletion of my server, it's gone.

I assume you mean "Varjo native DFR" as in the new registry key they've released in 4.3. That would be correct, the Varjo runtime doesn't do the incorrect FOV submission "recovery" that I added in Varjo-Foveated and Quad-Views-Foveated. That's because this workaround is super sketchy (we guess which dynamic projection the game should have submitted), it uses a FOV cache to try to re-correletate the FOV information with the previous frame(s). This is why I only activate this if I am sure the app is DCS, since this is fragile code that could break other apps intentionally doing FOV manipulation. Note that this isn't an uncommon bug that ED have in their code: there's quite a few apps doing incorrect pose/FOV submission, but most of the time it only affects ever-so-slightly the reprojection (or adds a bit of instability). Here with the very low latency eye tracking, the effect is absolutely dramatic.

Ahaha yes that's right. This rename is also going to be another source of issues for that scenario

I've explained my position below. TL;DR, no I cannot do much without creating more problems for myself (eg: unsigned build that would break other apps), for an issue that I have already spent HOURS explaining in details to ED, and that isn't even my bug in the first place.

Reminder that Varjo-Foveated requires you to turn off OpenXR Toolkit, in case that's your issue here.

FYI this is the specific line that checks for DCS and enables the workaround to their incorrect multi-thread frame submission logic: https://github.com/mbucchia/Quad-Views-Foveated/blob/957ff0327185ea29acc41fc86c4cdc3caf428fb9/openxr-api-layer/layer.cpp#L175 The new version of DCS seems to report "DCS" instead of "DCS World". As mentioned above, while this looks like an easy change for me, it isnt: 1) ED needs to provide the real fix, as explained in March 2023 and again in December 2023. If the real issue had been addressed at the source, this wouldn't be happening today (since there would not be a need for a game-activated workaround). Changing the name in QVFR only opens the door to it breaking when ED decides to use "Digital Combat Simulator" as the app name in the future. Always activating the workaround creates a maintainability issue where the workaround could potentially break non-DCS apps. 2) I don't have a code signing certificate today, so any release I'd make would break anti-cheat software (not in DCS, just ANY OpenXR game installed on your machine), which isn't something I'm going to do (cause then that is more fallout coming in my direction, for something that isn't even my problem). Acquiring a code signing certificate with Cloud Signing is >$1000 AND also several hours setting up a token vault and all of the other goodies that the digital government now requires. Not really sure what is the point of me spending hours of my time writing all this this stuff and explaining best practices and making detailed bug reports, pointing out issues, if this work just goes down the trash can without probably being read at all

Note that the bug is specific to ED'S multi-threaded code (they are submitting data from the wrong frame, a blantant violation of the OpenXR standard), so the ST version of DCS isn't affected (someone confirmed to me that it worked). Also, if you are on Varjo, you could disable Quad-Views-Foveated and instead use Varjo-Foveated, because that tool did not have the conditional check on the app name (unlike Quad-Views-Foveated, the Varjo-Foveated tool is pretty much only useful for DCS, so I never checked which app is running before activating the workaround).

I cannot release any new version because my signing certificate expired in February and the cost of digital signing has gone from $200 to >$1,000 in 2024, so I'm not getting a new one. I'm also real real real tired of repeating myself ED And specifically initial report point 2) here (March 2023):

See my reply here Same bug I reported to ED for >1 year but apparently no traction to fix it. They renamed the app so now the workaround doesn't kick in anymore.

@BIGNEWY this is the same bug I reported to you guys over a year ago, with incorrect FOV submissions in xrEndFrame(). There is a workaround to YOUR bug in Quad-Views-Foveated, but it looks for the application name being "DCS World", but it looks like you changed that string to "DCS", so the workaround doesn't kick in. Please fix the real issue anyway... your code is violating the OpenXR standard. Reported originally March 2023 with a very clear explanation (point 2):

That's the right answer, since the game one is done at the proper stage of rendering. I'll add for the streaming options (like Virtual Desktop) it's also nice to use the sharpening in the streaming app (done on the headset side) since it happens after the encoding+decoding, where some of the sharpeness was lost. Note that sharpening before the encoding will also increase bandwidth but it's quite necessary as it produces better results.

Better to ask on Varjo Discord, that's where Arch promised me it was going to happen.