Aside from GSP, What are the legal & software limitations that would stop this from being supported with more architectures? Linked to #19

[Daasin]

Issue #19 - Partially raised here.

And yes, I am aware of the original intention of the opening the code around GSP being the original goal but is that then the only roadblock that is preventing the support for Non-Turing/Ampere Architectures?

I suppose the main point of this that I wanted discussed was:
"If there was a need/high-demand for a move like this on something like Pascal then would there be a will from devs at Nvidia to help with efforts to get similar support?"

---

One example would be because DXVK/VKD3D for Linux that had issues with DX12 over Vulkan that could be solved with a more open-source standard base to work with or just co-ordination with developers from Nvidia due to a solution being used for Windows. A roadblock ended up being hit because of mutable descriptors & non-bindless uniform buffers with Vulkan.
In that scenario, it could have been a simple fix but we'll never know because it instead lead to Pascal & Maxwell getting dropped in a messy grey area of support on Linux whereas both older and newer architectures had strong support either from the FOSS Community or from Nvidia themselves.

For Reference purposes:
https://boilingsteam.com/nvidia-pascal-gpu-dx12-and-vkd3d-slideshow-time/
https://www.reddit.com/r/linux_gaming/comments/q9yt2j/eli5_why_is_dx12_translation_worse_on_nvidia/
HansKristian-Work/vkd3d-proton#465
ValveSoftware/Proton#5156
ValveSoftware/Proton#5613
ValveSoftware/gamescope#492

[SpidFightFR]

One example would be because DXVK/VKD3D for Linux that had issues with DX12 over Vulkan that could be solved with a more open-source standard base to work with or just co-ordination with developers from Nvidia due to a solution being used for Windows.

On wayland too, many issues could be fixed by the community if only an open source module existed for those cards.
I mean, it's not normal that when we have an issue with a software, the first question asked by the devs are "What GPU are you using ?" to then tell you that "compatibility with nvidia GPUs is broken due to the proprietary drivers"...

[aritger]

Yes, a fully open source driver would make a large class of issues easier to resolve.

open-gpu-kernel-modules is hopefully an improvement, but certainly has many limitations (kernel-space only, only Turing and newer, etc).

In reality, I think it is unlikely that we'll be able to add support for pre-Turing GPUs to open-gpu-kernel-modules.

For driver interaction problems with vulkan, wayland, or anything else, I think it is going to be up to NVIDIA to fix NVIDIA driver problems. I know that isn't ideal.

Do you have details on the vulkan mutable descriptors & non-bindless uniform buffers issue? Were you able to resolve it on Turing and later due to the existence of open-gpu-kernel-modules?

[ghost]

Or just let the community make the driver themselves? By releasing the sources, No money usage.

[ghost]

Buying an NVIDIA gpu was one of the worst decisions I ever made.

[Daasin]

@aritger Oh no, the existence is almost exclusive to Pascal and worse in VKD3D. There was a workaround on windows but since people working on the Linux stuff outside of Nvidia weren't able to find out how to address the issues/find solutions based off of the causes then it kind of left them in the dark & made DirectX over Vulkan mess up for some versions.

For Reference purposes:
https://boilingsteam.com/nvidia-pascal-gpu-dx12-and-vkd3d-slideshow-time/
https://www.reddit.com/r/linux_gaming/comments/q9yt2j/eli5_why_is_dx12_translation_worse_on_nvidia/
HansKristian-Work/vkd3d-proton#465
ValveSoftware/Proton#5156
ValveSoftware/Proton#5613
ValveSoftware/gamescope#492

[gardotd426]

@doitsujin sorry for the ping since I know you're constantly swamped, but I figured instead of me trying to remember the conversation we had about it like a year ago and then properly explain it (and fail), I thought you could maybe help the Nvidia guys understand.

For everyone else, I will say that the aforementioned conversation did include some details I can give but only at the highest level:

• IIRC, it is not a Pascal issue, it's an all Nvidia GPUs from Pascal and earlier.
• This is because they lack support for Bindless UBO on an architectural level, which obviously cannot be fixed by opening the code, the hardware doesn't exist on the cards, and VKD3D-Proton (or D3D12) depends on it quite heavily for performance, but it's NOT universal. That is to say, it is NOT all D3D12 titles ran on Linux through VKD3D-Proton+DXVK's DXGI +DXVK-NVAPI + whatever. There are games that aren't affected, but they're in the minority.
• The Bindless UBO problem is not the sole cause, which is probably the only "good" news. I remember that some of the performance is for Pre-Turing NV GPUs lacking support for certain Vulkan extensions. Philip didn't mention the exact extensions, so I can't go check if support has been added to those generations since then or not, nor can I check and see if any of them are obvious "unsolvable because of architecture limits" extensions. But, again, there will ALWAYS be a performance hit in affected DX12 titles with those cards because of the lack of Bindless UBO.
• This isn't from the conversation doitsujin and I had, but this is related: The guys behind VKD3D-Proton - which is mainly a triumvirate of doitsujin, Joshua Ashton and Hans-Kristian Arntzen (much like DXVK only with DXVK it's just doitsujin and Josh)* - added an experimental flag you can enable with an environment variable specifically to give Pre-Turing NV GPU owners the option to try and improve performance at the cost of stability. Now, I say again, this is literally a hack, the github README's description is "Unsafe speed hack for Nvidia," at least it was for a long time. You just use force_static_cbv in your VKD3D_CONFIG= environment variables (or if you don't already have any, you just do VKD3D_CONFIG=force_static_cbv).

I don't have a Pascal card, I have a 3090, so I can't do much to help test, but I can at least gather data on performance in known-affected titles, which y'all can use to extrapolate and see how much performance you're losing (like if my GPU is 3X more powerful than your Pascal card, but my fps at the same resolution and settings isn't even 1/5th of mine, we'll know it's "the bug" which I'm just gonna refer to as the hydra from here on, since it has multiple causes.

I could also compare my normal performance vs performance using the open modules, but I would have to test a wide range of games using every API Pascal supports - OpenGL, Vulkan, D3D9, D3D10/11, and D3D12 because I've not used the open modules to know what I should expect in general, and there are surely other bugs that might affect all games, or might only affect one API, etc.

If anyone needs me to sanity check anything, grab some performance benchmark data or if someone with an Ampere GPU that can git-bisect properly is needed, just ping me. My displays are 2560x1440@165Hz, so I can't test 4K, I guess I could but it would be over HDMI using my TV instead of my gaming monitors

But as far as who the actual authority regarding knowledge of the issue from the VKD3D-Proton/DXVK side goes, it is doitsujin, Josh, and Hans-Kristian. @openglfreak is also extremely knowledgeable and can contribute more knowledge than I could ever hope to, but he's also very very busy.

NOTE: For the love of god, do NOT go post issues on the vkd3d-proton repo regarding this. It's known, it's literally a meme in the linux gaming dev server, and has been for years, and any issue will just be closed immediately and just waste their time. I've pinged Philip and oglfreak despite the fact that I hate having to do that, but yeah it's up to them if they want to come shed some more light or if they wanna holler at Josh or Hans to do it, etc. Those guys work their asses off constantly, and they know anything you might tell them already, and as far as I know the current status quo is "the ball is in Nvidia's court regarding anything that CAN be fixed, but performance can't be "fixed" to match expected levels."

🐸 🐸 🐸

[Daasin]

Wasn't there a workaround that MS & Nvidia found for using Windows with the official drivers? In regards to the Bindless UBO's? I know it's a matter of missing hardware but I could've sworn there was something mentioned about that @gardotd426 @aritger @cubanismo

I know it'll never be perfect but I've been hoping for some kind of (and I use this term relatively) 'fix' for it since Lockdowns & GPU's became like gold-dust. Like Pascal isn't dead yet, right? Or it wasn't when the issue was common knowledge (Even tho it could be argued that it's getting old and everything before it is ancient)

[SpidFightFR]

Not gonna lie: it's sad as a corporation being this much against it's community. Really, making this process easier only can be benefit economically and "morally", because all you manage to do by not helping the community with those problem is to build yourself a bad reputation...

Now surely, the Linux community is small, i don't tell, but regardless, it still is sad to see.
Again, making things easier for the Linux community will only help everyone. Both Nvidia and the community.

The choice is yours Nvidia, you made a great move with releasing an open source module for Linux. Some will troll you, others will say "huh, soon enough", but i prefer seeing this as a great step further, towards your community.

Don't waste this effort, and help us make your driver the real way it's meant to be played.

[throwaway1037]

NVIDIA, there are dozens of free software programmers who want to write and maintain these drivers for you.
All you have to do in return is respect our freedom by making all the components free/libre software.

[Menelkir]

Or at least give what the nouveau developers need to make it happens. Power management documentation would be an astronomical step.

[gardotd426]

NVIDIA, there are dozens of free software programmers who want to write and maintain these drivers for you. All you have to do in return is respect our freedom by making all the components free/libre software.

There could be a million developers that are "willing," none of the 3 dGPU makers would ever in a million years hire an additional <23 ("dozens" = at least 24) developers to work specifically on this problem, or even specifically on their open-source Linux graphics code en toto. Honestly I legitimately believe AMD has under 15 employees assigned to the Linux kernel amdgpu driver ALTOGETHER, and Alex Deucher still does 90% of any of the work regarding bugs that I ever see. And while they do have a Vulkan driver technically I guess, it's garbage, everyone knows it, and they don't contribute a single line of code to the AMD Vulkan driver that actually exists in any meaningful way (Mesa's RADV). Look for yourself, they contribute nothing to it. They only contribute to the OpenGL Mesa AMD driver, the Vulkan one is all Valve, Collabora, RedHat, and maybe a couple Google employees, plus some free agents or Mesa bigwigs like Dave (who I think does work for RedHat but still).

Like, this is not reddit. This is an issue/discussion thread on the official Nvidia Linux Kernel GPU Modules Git repository. Every single person that comes here to whine about the drivers not being all fully open (who don't know what they're talking about, since there is almost certainly licensed code owned by OTHER companies in those drivers, or GPL issues, which make that constant demand completely inane), or to legitimately treat this thread like a UseNet/Reddit flamewar and just insult Nvidia because "Nvidia bad, today, used to be Nvidia good, but Nvidia bad," you're objectively a) disrespecting the developers and volunteers that are actually working to try and help mitigate the issue, b) wasting everyone's time, c) doing it in a GIT ISSUE THREAD, and d) making it a nightmare to actually TRY and help, because anyone who tries has to sift through all the literally meaningless posts to get actual good information. If this was on a Repo I had admin rights to like Regolith-Linux, I'd delete every one of those comments and just create an issue thread titled "flame comments go here." so everyone could get their jobs done and know to just ignore that thread