Software: Difference between revisions
No edit summary |
No edit summary |
||
Line 9: | Line 9: | ||
In all cases, the [[Resource Manager]] implements the actual interaction with the hardware. The RM initialises, controls and shuts down (if required) the graphics hardware; multiple types of APIs are provided in order to interact with the RM. The first model is the OS-provided IOCTL interface can be used (this model is used byt). A second model is calling into APIs exposed by the Resource Manager through the NVAPI interface (basically a function, a la Quake-based game engine, that takes a single parameter, which is a very large C struct with many function pointers for different functions), typically implemented via the mechanism of a stub DLL that forwards each function to the Resource Manager. The implementation varies by driver version and intended operating system. For instance, in the case of NV3 drivers for Windows 9x, the 32-bit API <code>NV3API.DLL</code> thunks into a 16-bit dll <code>NV3SYS.DLL</code> by passing a large array of function pointers (which also exports, via traditional DLL exporting, the same API but for 16-bit apps) which then ''calls back into the 32-bit Resource Manager VxD'' to perform API calls. The interface to the GPU is implemented via a pseudo-C++ class system classes are indicated by object IDs, with a large array of class structures providing "methods" based on each class ID. Some classes are [[PFIFO#Object submission|implemented in hardware]] (using the <code>grHWMthd</code>) function: if a class is implemented in hardware, it is simply stubbed out in software. | In all cases, the [[Resource Manager]] implements the actual interaction with the hardware. The RM initialises, controls and shuts down (if required) the graphics hardware; multiple types of APIs are provided in order to interact with the RM. The first model is the OS-provided IOCTL interface can be used (this model is used byt). A second model is calling into APIs exposed by the Resource Manager through the NVAPI interface (basically a function, a la Quake-based game engine, that takes a single parameter, which is a very large C struct with many function pointers for different functions), typically implemented via the mechanism of a stub DLL that forwards each function to the Resource Manager. The implementation varies by driver version and intended operating system. For instance, in the case of NV3 drivers for Windows 9x, the 32-bit API <code>NV3API.DLL</code> thunks into a 16-bit dll <code>NV3SYS.DLL</code> by passing a large array of function pointers (which also exports, via traditional DLL exporting, the same API but for 16-bit apps) which then ''calls back into the 32-bit Resource Manager VxD'' to perform API calls. The interface to the GPU is implemented via a pseudo-C++ class system classes are indicated by object IDs, with a large array of class structures providing "methods" based on each class ID. Some classes are [[PFIFO#Object submission|implemented in hardware]] (using the <code>grHWMthd</code>) function: if a class is implemented in hardware, it is simply stubbed out in software. | ||
=== NV1 to NV3 === | === NV1 to NV3 === |
Revision as of 21:32, 20 April 2025
Nvidia has produced many pieces of software for users of their graphics cards. The main piece of software required is their drivers: they are required to make the GPU function at all, beyond the very basic (VGA, VESA, or Windows Advanced Rasterisation Platform - WARP in Windows 7 and later) level of compatibility assured for all forms of graphical hardware that are supported by Windows; any Nvidia-specific features require their drivers to be installed on the system. The first ever variant of the Nvidia driver set was the series of VxDs running under Windows 3.x that allowed the NV0 to be simulated. There have historically been several sets of drivers for Nvidia hardware: initially, the first was Nvidia's drivers, based on their Resource Manager, which started development in 1994, and the very early versions of the NT miniport driver which programmed the hardware directly rather than through the RM, as a stopgap measure until the real Resource Manager was ported over to NT, starting with the NV1, in roughly 1996. There was also a semi-official, very basic nv
driver set for Linux, which was not judged sufficient for use of the card under Linux, was updated infrequently with few features and Nvidia required to be partially obfuscated (and was generally hard to deal with as a company)[1]
: several driver projects started to provide a more complete emulation, with nouveau
, under the purview of the wider freedesktop project, being the most popular and long-lasting, although Utah GLX (which successfully achieved 3D acceleration on the Riva 128 at least) and RivaTV, aimed at using the TV-out functionality and Mediaport of these cards, also existed; nv
was also ported to BeOS and several other operating systems to allow Nvidia GPUs to be used on their operating systems. Later on, most of these projects experienced sharp declines in development activity, or were discontinued entirely as Nvidia ported their full Resource Manager drivers to Linux and eventually partially open-sourced them, although parts of it were moved to the firmware running on modern nVidia GPUs' on-die Falcon and RISC-V cores prior to this.
Nvidia has also provided both industry-standard APIs (such as DirectX, OpenGL and Vulkan) several custom APIs for their products for both graphics and non-graphics related applications, such as Cg (C for graphics) starting on the NV20, and for GPGPU applications, CUDA (Compute Unified Device Architecture) starting on the G80. However, these are largely implemented as Resource Manager clients or otherwise as parts of their drivers: for example, the game physics API PhysX, the Nintendo Switch graphics API nvn
and its Switch 2 successor nvn2
, the extremely confusingly named "NVIDIA Riva" AI speech generation API, NeMo for generative AI, RAPIDS for data science, CUDA-X for general AI libraries, and many more are all implemented in a similar fashion.
Presumably, the NV2 did not use any form of drivers, or used a light vendor-supplied library (similar to the "OS" library for the Nintendo 64, per Goddard) and was intended to be programmed directly by the game developer while running on Saturn V08, as was the style for consoles at that time.
Design
While Nvidia has changed their drivers' design over time, at least for early models there are two pretty basic setups for the "full fat" Nvidia Resource Manager-based drivers, one which was used for NV1 through NV3 and a new design which was used starting with NV4 (although there are obviously variations of both).
In all cases, the Resource Manager implements the actual interaction with the hardware. The RM initialises, controls and shuts down (if required) the graphics hardware; multiple types of APIs are provided in order to interact with the RM. The first model is the OS-provided IOCTL interface can be used (this model is used byt). A second model is calling into APIs exposed by the Resource Manager through the NVAPI interface (basically a function, a la Quake-based game engine, that takes a single parameter, which is a very large C struct with many function pointers for different functions), typically implemented via the mechanism of a stub DLL that forwards each function to the Resource Manager. The implementation varies by driver version and intended operating system. For instance, in the case of NV3 drivers for Windows 9x, the 32-bit API NV3API.DLL
thunks into a 16-bit dll NV3SYS.DLL
by passing a large array of function pointers (which also exports, via traditional DLL exporting, the same API but for 16-bit apps) which then calls back into the 32-bit Resource Manager VxD to perform API calls. The interface to the GPU is implemented via a pseudo-C++ class system classes are indicated by object IDs, with a large array of class structures providing "methods" based on each class ID. Some classes are implemented in hardware (using the grHWMthd
) function: if a class is implemented in hardware, it is simply stubbed out in software.
NV1 to NV3
From NV1 to NV3 the Resource Manager is unique for each graphics card - it is a different branch in Nvidia's source control system. This is not shared for all parts of the d
NV4
Supported platforms
Note: These are platforms that were supported for any length of time, not platforms that are currently supported, or which GPUs they can be used with.
Operating system | Driver supported |
---|---|
Windows for Workgroups 3.11 | Full drivers[2]
|
Windows 95 | Full drivers |
Windows 98/98SE | Full drivers |
Windows ME | Full drivers |
Windows NT 3.51 | Miniport driver only |
Windows NT 4.0 | Miniport driver, later full Resource Manager-based driver[3]
|
Windows 2000 | Full drivers[4]
|
Windows XP | Full drivers[5]
|
Windows Vista | Full drivers |
Windows 7 | Full drivers |
Windows 8 | Full drivers |
Windows 8.1 | Full drivers |
Windows 10 | Full drivers |
Windows 11 | Full drivers |
Xbox (original) | Modified full drivers ("minix") |
macOS | Full drivers |
Android | Full drivers, also nv
|
Linux | Initially nv or open-source project only, later full drivers.
|
BeOS, Haiku, EOS, AsusWRT (linux-based) | These OSes support the nv driver only
|
OS/2 | Full drivers |
PlayStation 3 (CellOS) | Custom |
Horizon OS (Switch) | Full drivers (with custom API) |
Horizon OS (Switch 2) | Full drivers (with custom API) |
Known driver versions
Notes
- ^ These issues in the relationship eventually led to the infamous "Fuck you, Nvidia!" comment and middle finger by Linus Torvalds at a 2012 event.
- ^ They are officially marked as being for 3.11, but unless they depend on the 32-bit File Access feature backported from Windows 95, or any other feature that was exclusively added in WfW 3.11, there should be no reason why they cannot work on any other version of Windows 3.1, such as the original 1992 release, standalone Windows 3.11, or Windows for Workgroups 3.1: however, the drivers have not been tested with these older versions, so the compatibility, or lack thereof, is unknown.
- ^ Initially 2D only, then OpenGL only: no D3D.
- ^ Initially OpenGL only, later Direct3D support was added. Beta only for NV3.
- ^ 2D only officially for NV3, although hooks to load the OpenGL drivers still exist; they do not load using the Windows 2000 drivers, but they can likely be patched to work.