570 release feedback & discussion

Graphics / Linux Linux
613

Hi @metux,

First, I want to apologize for not being responsive to your freedesktop.org merge requests lately. I’ll do my best to provide quicker responses in the future.

It might help if I clarify exactly how we build nvidia_drv.so and how it handles supporting different versions of Xorg in a single binary:

  • The core code that interfaces with the rest of the graphics driver components doesn’t use any Xorg headers at all. This includes stuff like initializing and tearing down GPUs, translating rendering requests into GPU commands, and handling synchronization of direct-rendering clients such as GLX and Vulkan.

  • The rest of the code that talks to the Xorg server is built multiple times, once for each supported ABI version. This includes anything that accesses a pScreen or pScrnInfo or plugs function pointers into the wrapping chain. Each time this code is built, it includes a different snapshot of the /usr/include/xorg header directory, and uses compile-time flags to handle anything that changed at an API level. That’s why I’m confident that, for example, the driver will never try to call dixLookupPrivate on an X server where it doesn’t exist: the headers it compiled against don’t include it and it would have failed to compile if it tried.

  • All of these support modules get linked together into a single nvidia_drv.so module.

  • When the driver is loaded, the first thing it does is call LoaderGetABIVersion and find a suitable support module to load. All communication with the X server goes through that module for the lifetime of the server.

  • During the Xorg release process, we generally declare the ABI frozen somewhere during the RC phase of the release. This doesn’t mean no ABI changes are allowed, it just means the version number needs to be bumped if the ABI changes. At the freeze point, I take a snapshot of the headers in /usr/include/xorg and that becomes the official set of headers for that ABI version. The freeze process during RC releases allows me to enable support for the new version in the next driver release so it can get into the hands of users before distributions pick up the new version of Xorg.

We have enterprise customers who use very old software and expect it to remain stable. That’s why our support timeframes are so long for things like old X ABI versions. Yes, the updated minimum for the release 580 series is still very old, but it shouldn’t affect your work at all: that ABI is frozen and it doesn’t affect the version of the code that is built for ABI 27.

We considered shipping multiple different versions of nvidia_drv.so, but that creates a big hassle for distribution packagers and users when upgrading the X server causes the driver to break. For users that use the .run package, we’d also have to identify the Xorg version at install time and users would be left with a broken driver if they upgrade Xorg without reinstalling the driver. A similar problem for the kernel modules is generally solved by DKMS, but we don’t have anything like that for Xorg modules.

You’d do everybody a huge favor. 90% of the hassles people have with it on daily basis would be just gone.

Can you clarify exactly what hassles you’re referring to? I haven’t been able to skim all of the forum traffic, but problems with installing or loading nvidia_drv.so don’t really show up on the radar as far as I’ve seen. This method for supporting Xorg has worked reliably for a very long time.

– Aaron

4 Likes