nvapi: Forward NVAPI multiview calls to DXVK - #388
Conversation
This PR is to enable SMP/MVP support in iRacing. With triple monitors a user really needs to enable Render scene using 3 projections to remove warping on all monitors due to one very wide camera. But this incurs a large performance loss due to drawing a scene three times per frame (one per screen). SMP/MVP changes how the game makes the calls, compiling the shaders directly through NVIDIA creation calls rather than DirectX with extra position data for each viewport/screen. This means a scene draw only needs to be done once instead of three times reducing the cpu work meaning the GPU is not waiting as much leading to higher framerates. Before the work in this PR, neither DXVK or dxvk-nvapi had any idea SMP existed and the toggle in iRacing was greyed out because when the game asked if the feature was available the answer was no. The capability query now correctly enables the toggle by exposing the feature when the graphics card is known to support SMP/MVP in its various feature levels, which means it won't magically activate on an AMD card for example. Enabling the toggle was not the end of the work, dxvk-nvapi needed to know how to forward the multiview calls to DXVK which then did the actual work needed to display the graphics correctly when using SMP. ID3D11VkExtDevice2 and ID3D11VkExtContext2 are the transition from the game to DXVK. Understandably, SMP/MVP has never been implemented or even stubbed due to the less than a handful list of games that use it. A previous request from myself (issue jp7677#233) a few years ago became a "fine I'll do it myself" and resulted in heavy research to do this work. Testing required getting the SMP toggle functional then using RenderDoc to review viewport and location data to align them correctly. Operational testing became toggling settings on and off and the data (admittedly due to my weak cpu) showed a substantial increase in fps as one would expect with SMP being enabled. The viewport masking was inferred from constants as the NVIDIA documentation appears to have no description of it, but that's more on the DXVK side. As far as I am aware, iRacing is the only game to fully utilise SMP but I have noticed some of the work in the PR may overlap with some VR technology as NVIDIA's own documented cases for this API are VR, single-pass stereo on Pascal and other parts which could be useful.
a3132d4 to
6f67b06
Compare
|
Hi, thanks for the PR. Getting this landed obviously depends on how the discussion on DXVK side goes. This is indeed a lot of code for just a single title with a very specific setup. But if it lands there, cool to add our side as well. A few generals notes from briefly looking at the changes:
|
|
Hi, I'm going to say the same as my comment on the DXVK side, apologies for dumping something so big and so specific on you like this. My knowledge of the processes for this side of things is certainly lacking. As with the DXVK comment, this PR is included in my decision to go away and work on improving the PRs as now it is clear both of you have made some very valid points about how this has been presented and I need to resolve them. For the concerns from both of you about the changes being very specific to not only one game but also the unique architecture being used I have already completed a quick test using lavapipe to do the rendering and aside from the completely hilarious software rendering speed of 45-50s per frame, that worked. That was done by installing lavapipe, editing launch options and a temporary code edit to force Turing detection and continue anyway. I have released a custom proton tool for users to test with these changes and knowing people have downloaded it, I am taking the no news is good news approach as iRacing users are very vocal if something doesn't work, but don't say anything when it does! So with the lavapipe result, there is very good potential for me to resolve the device agnostic issue in DXVK and your quick skim over is already noted down to review those parts. Those were part of the mistakes of me being so heavily focused on the single task to complete the goal. I hope you can understand I am very passionate about the end goal of showing iRacing that their game can successfully work on Linux but now I know things need to be somewhat different compared to merely just slapping code on a website, any help in understanding and completing what should be done will be greatly appreciated! I want to get this right! Thank you for your time! |
|
All good. Having things in a working state and then refining / splitting it up is not a wrong approach. I started this whole project to just get a few more fps in Assetto Corsa Competizione on Linux/NV, so I certainly understand the passion :) |
2 participants
This PR is to enable SMP/MVP support in iRacing by exposing the SMP capability to iRacing and also forwards the calls from iRacing to DXVK.
As far as I can tell iRacing is the only game to use SMP/MVP for triple screen gaming. These changes only affect users with an NVIDIA card of the Turing generation or newer and nothing changes for any users not using this feature either with an incompatible graphics card or SMP simply being disabled in game.
Multiple test runs and the DXVK_HUD and Mangohud data collected from them are in this graphic:
(performance changes are as expected when enabling SMP, FPS should increase significantly over SMP off)
doitsujin/dxvk#5828 is necessary for a reviewer to be aware of as both the DXVK and dxvk-nvapi changes need to work together.
This work is the result of my issue #233 18 months ago. I understood and accepted the reasoning given there as it was a very fair comment to make. It did inspire me to work on doing it myself though! I have been spearheading an unofficial campaign to ask for iRacing to reintroduce some form of support regarding Linux with the most recent path asking for the EOS Linux module to be built. iRacing hasn't pushed back on anticheat being the reason they won't let users play on Linux but instead pointing to "third party APIs, hardware support" (etc). This is part of my response by looking to close off excuses and narrow down their replies to simply being "we won't do it because of cheaters" or them running dry of excuses.
I'm happy to do further testing that may be needed.