F5F Stay Refreshed Software Operating Systems Nvidia might develop drivers for MacOS independently of Apple's support.

Nvidia might develop drivers for MacOS independently of Apple's support.

Nvidia might develop drivers for MacOS independently of Apple's support.

T
TheGear123
Junior Member
Find
9
11-01-2021, 07:14 PM
#1
Recently I've been pondering the inner workings of graphics drivers and that helped clarify why Nvidia's usual drivers failed on macOS 10.14. A GPU driver consists of two main components: one) a kernel or user-space extension that communicates with the PCIe device, and two) a shared library that all apps (especially those with a graphical interface) load at startup, providing access to APIs like OpenGL/dx11. These shared libraries are essentially dynamic libraries. On Windows, you'll frequently encounter them with .dll extensions, while on macOS they typically appear as .so or .dylib files—just like .dll. The crucial element here is the DLL file supplied by the GPU driver; it's what caused Nvidia's drivers to stop functioning in that version. Before diving deeper, let's clarify what a DLL is. # DLL (Dynamic Link Library) These are segments of compiled code that any application on the system can load and execute as part of itself. The main concept is they establish a predefined interface, allowing an app to rely on specific functions being available. However, loading a DLL means the program running within it inherits those privileges—so if an admin account loads a DLL, it operates with elevated rights. With increasing security measures and sandboxing, especially against crypto-lockers, exploiting DLL injection has become a serious concern. If a malicious actor manages to trick a trusted program into loading a custom DLL like `opengl.dll`, they could execute code within that trusted context. # Enter macOS 10.14 In macOS 10.14, Apple introduced major changes to the operating system. Applications signed by developers—including Apple’s own software—could no longer load dynamic libraries unless they were also signed by the developer or Apple itself. This effectively prevented Nvidia from distributing a driver that replaced the standard system files `opengl.dylib` and `metal.dylib`. For Apple to do this, the firmware would need to sign those files with its own developer keys, which Apple wouldn’t do unless Nvidia granted permission. # But Nvidia Could Still Ship Drivers By supplying the DLL portion of their drivers to app developers, who could then bundle and sign them with their own developer keys. This approach is similar to how Nvidia handles CUDA support on Windows. They impose certain conditions: * only system or Apple-signed apps could load these DLLs, and the system’s compositing still relied on Apple’s drivers; thus, an Intel CPU with an integrated GPU or an AMD GPU was required. * There would be a slight delay in rendering when the GPU output is transferred to the system GPU before compositing. * Updating the DLL part of a driver would require developers to release a new version (or at least a single .dylib update). * Only apps that included this DLL could leverage the Nvidia GPU. # Why haven't we seen drivers for macOS 10.14+? It's not Apple blocking them, nor is Apple concerned enough to act. Nvidia simply didn’t need to—because it already provided the necessary DLLs for app developers to distribute. # However, Nvidia could still proceed by handing over the DLL files to app developers for bundling and signing with their own keys. This method has been used for CUDA support even on Windows. They set some boundaries: * only system or Apple-signed applications could use these DLLs, and the Apple drivers would still handle compositing; thus, you’d need at least an Intel CPU with integrated GPU or an AMD GPU. * A minor frame delay would occur when the GPU output is copied to the system GPU before compositing. * When a driver’s DLL is updated, developers would need to release a new version—or at least a single .dylib update. * Only applications that incorporated this DLL would gain access to the Nvidia GPU.
Reply
Reply
T
TheGear123
11-01-2021, 07:14 PM #1

Recently I've been pondering the inner workings of graphics drivers and that helped clarify why Nvidia's usual drivers failed on macOS 10.14. A GPU driver consists of two main components: one) a kernel or user-space extension that communicates with the PCIe device, and two) a shared library that all apps (especially those with a graphical interface) load at startup, providing access to APIs like OpenGL/dx11. These shared libraries are essentially dynamic libraries. On Windows, you'll frequently encounter them with .dll extensions, while on macOS they typically appear as .so or .dylib files—just like .dll. The crucial element here is the DLL file supplied by the GPU driver; it's what caused Nvidia's drivers to stop functioning in that version. Before diving deeper, let's clarify what a DLL is. # DLL (Dynamic Link Library) These are segments of compiled code that any application on the system can load and execute as part of itself. The main concept is they establish a predefined interface, allowing an app to rely on specific functions being available. However, loading a DLL means the program running within it inherits those privileges—so if an admin account loads a DLL, it operates with elevated rights. With increasing security measures and sandboxing, especially against crypto-lockers, exploiting DLL injection has become a serious concern. If a malicious actor manages to trick a trusted program into loading a custom DLL like `opengl.dll`, they could execute code within that trusted context. # Enter macOS 10.14 In macOS 10.14, Apple introduced major changes to the operating system. Applications signed by developers—including Apple’s own software—could no longer load dynamic libraries unless they were also signed by the developer or Apple itself. This effectively prevented Nvidia from distributing a driver that replaced the standard system files `opengl.dylib` and `metal.dylib`. For Apple to do this, the firmware would need to sign those files with its own developer keys, which Apple wouldn’t do unless Nvidia granted permission. # But Nvidia Could Still Ship Drivers By supplying the DLL portion of their drivers to app developers, who could then bundle and sign them with their own developer keys. This approach is similar to how Nvidia handles CUDA support on Windows. They impose certain conditions: * only system or Apple-signed apps could load these DLLs, and the system’s compositing still relied on Apple’s drivers; thus, an Intel CPU with an integrated GPU or an AMD GPU was required. * There would be a slight delay in rendering when the GPU output is transferred to the system GPU before compositing. * Updating the DLL part of a driver would require developers to release a new version (or at least a single .dylib update). * Only apps that included this DLL could leverage the Nvidia GPU. # Why haven't we seen drivers for macOS 10.14+? It's not Apple blocking them, nor is Apple concerned enough to act. Nvidia simply didn’t need to—because it already provided the necessary DLLs for app developers to distribute. # However, Nvidia could still proceed by handing over the DLL files to app developers for bundling and signing with their own keys. This method has been used for CUDA support even on Windows. They set some boundaries: * only system or Apple-signed applications could use these DLLs, and the Apple drivers would still handle compositing; thus, you’d need at least an Intel CPU with integrated GPU or an AMD GPU. * A minor frame delay would occur when the GPU output is copied to the system GPU before compositing. * When a driver’s DLL is updated, developers would need to release a new version—or at least a single .dylib update. * Only applications that incorporated this DLL would gain access to the Nvidia GPU.

Reply
Reply