NvWiki - Recent changes [en-gb]

NV3 Getting Started

Starfrost — Wed, 11 Nov 2026 01:05:19 GMT

← Older revision		Revision as of 01:05, 11 November 2026
(One intermediate revision by the same user not shown)
Line 3:		Line 3:
	== Introduction ==		== Introduction ==
	Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of heart. You are directly programming complex graphics hardware (old does not mean simple - the RIVA 128 has 3.5 million transistors, far more than any human can individually comprehend) that is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or some other piece of software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus working under a DOS box such as the Windows 9x DOS box.		Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of heart. You are directly programming complex graphics hardware (old does not mean simple - the RIVA 128 has 3.5 million transistors, far more than any human can individually comprehend) that is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or some other piece of software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus working under a DOS box such as the Windows 9x DOS box.

			== Concepts ==
			Before we start programming, there are many concepts, some that are more general to raw-level GPU development and other very specific to Nvidia, that need to be explained.

	== Pre-initialisation ==		== Pre-initialisation ==
Line 54:		Line 57:
	Then the two addresses returned must have their lower 24 bits masked off, so that they are aligned to a 16 MB boundary, as the lower byte is used for determining if prefetching is enabled (which it is) rather than store the lower byte of the address. Additionally, the RIVA 128 only decodes the upper 8 bits of its PCI BAR values, so if these values are not aligned, MMIO addresses will be misaligned, which is fatal for graphics programming. This is especially important if you want to change the PCI BARs later. Since these addresses are not mapped within your CPU's memory management unit (MMU), they now need to be mapped in order to actually perform memory-mapped I/O. This is done, on x86 architectures, by adding additional segment descriptors to the local descriptor table (LDT) of your CPU, with a base address for each BAR and a "limit" (MMU parlance for size) of 16 MB. In DJGPP, this is done by <code>#including</code> the file <code>dpmi.h</code> allocating two LDT descriptors with the function <code>__dpmi_allocate_ldt_descriptors(1);</code>. The parameter 1 is the number of descriptors to allocate, as it is is easier syntactically to allocate them one at a time. The function returns an integer that is later used to actually interface with the MMIO space. After this, the functions <code>__dpmi_set_segment_base_address</code> and <code>__dpmi_set_segment_limit</code> are done to actually assign the base and limit values to the LDT descriptors.		Then the two addresses returned must have their lower 24 bits masked off, so that they are aligned to a 16 MB boundary, as the lower byte is used for determining if prefetching is enabled (which it is) rather than store the lower byte of the address. Additionally, the RIVA 128 only decodes the upper 8 bits of its PCI BAR values, so if these values are not aligned, MMIO addresses will be misaligned, which is fatal for graphics programming. This is especially important if you want to change the PCI BARs later. Since these addresses are not mapped within your CPU's memory management unit (MMU), they now need to be mapped in order to actually perform memory-mapped I/O. This is done, on x86 architectures, by adding additional segment descriptors to the local descriptor table (LDT) of your CPU, with a base address for each BAR and a "limit" (MMU parlance for size) of 16 MB. In DJGPP, this is done by <code>#including</code> the file <code>dpmi.h</code> allocating two LDT descriptors with the function <code>__dpmi_allocate_ldt_descriptors(1);</code>. The parameter 1 is the number of descriptors to allocate, as it is is easier syntactically to allocate them one at a time. The function returns an integer that is later used to actually interface with the MMIO space. After this, the functions <code>__dpmi_set_segment_base_address</code> and <code>__dpmi_set_segment_limit</code> are done to actually assign the base and limit values to the LDT descriptors.

	It is highly recommended to write utility functions to make it easier to read and write to MMIO space. Most Nvidia registers are 32-bit, but 8-bit versions of the functions are also required in order to write to 8-bit legacy VGA registers. In DJGPP, these functions would be written like this; ~~they~~ are ~~likely~~ easy to port to any other 32-bit flat DOS environment of your choosing:		It is highly recommended to write utility functions to make it easier to read and write to MMIO space. Most Nvidia registers are 32-bit, but 8-bit versions of the functions are also required in order to write to 8-bit legacy VGA registers. In DJGPP, these functions would be written like this, with <code>bar0_selector</code> being the selector that you allocated earlier; these functions are very easy to port to any other 32-bit flat DOS environment of your choosing:

	<pre>		<pre>
Line 69:		Line 72:
	}		}

			/* Write 8-bit value to the MMIO */
	void NV_WriteMMIO8(uint32_t offset, uint8_t val)		void NV_WriteMMIO8(uint32_t offset, uint8_t val)
	{		{
Line 74:		Line 78:
	}		}

			/* Write 32-bit value to the MMIO */
	void NV_WriteMMIO32(uint32_t offset, uint32_t val)		void NV_WriteMMIO32(uint32_t offset, uint32_t val)
	{		{
Line 81:		Line 86:

	== Initialisation ==		== Initialisation ==
	After this the actual initialisation of the GPU can commence. But before that, ''what do you actually get?'' from those two descriptors?		After this the actual initialisation of the GPU can commence. But before that, ''what do you actually get?'' from those two descriptors?

			BAR0 is a pointer into the GPU's register space. Registers are very sparsely grouped together; the vast majority of addresses decode to open bus (often, but not entirely consistent, garbage, seemingly related to what the GPU is currently writing into Video RAM). A header file with the addresses of the registers can be obtained here: ((TODO : UPLOAD UNOFFICIAL NV3_REF.H)); see [[NV3 memory mapping]] for an explanation of which regions correspond to which functional blocks within the chip. It also contains (at offset <code>0x110000</code>) a mirror of the Video BIOS, if one is installed (an integrated chip may not have one).

			'''Warning: ''' If the "mediaport" region (at <code>0x200000-0x200FFF</code>) is written to or read from without something being plugged into the mediaport, or certain other regions like the object registers, '''the entire PCI bus will lock up''', and the system will hard freeze, with the only option for recovering the system being using the rocker switch (the switch at the back).

			'''Note: ''' For some reason, at least under Windows 9x, if you open a DOS box, the top left corner of the window will be mirrored in the legacy VGA space (BAR0 <code>0xA0000-0xBFFFF</code>), in whatever graphics format the GPU is set up to use, but interlaced. This is, quite frankly, bizarre.

	~~== Concepts ==~~		BAR1 has two primary purposes on NV3. The first chunk of the BAR1 space is
	~~Before we start programming, there are many concepts, some that are more general to raw-level GPU development and other very specific to Nvidia, that need to be explained~~.

NV3 memory mapping

Starfrost — Wed, 11 Nov 2026 00:59:31 GMT

← Older revision		Revision as of 00:59, 11 November 2026
Line 44:		Line 44:
	\| <code>0x400000</code> \|\| <code>0x401FFF</code> \|\| <code>[[NV3 PGRAPH\|PGRAPH]]</code> \|\| 2D & 3D graphics rendering engine. Allows up to 4 buffers to be used for rendering 2D and 3D graphics (mostly DirectX 5.0 and OpenGL 1.1 compliant); can render graphics at 8, 16 or 32bpp in 2D at up to theoretical maximum resolution (set by <code>PFB</code>) of 20481536 (but in practice 19201200, sometimes 16001200) and up to 960720 (NV3) or 1600*1200 (?) (NV3T) at 16bpp for 3D.		\| <code>0x400000</code> \|\| <code>0x401FFF</code> \|\| <code>[[NV3 PGRAPH\|PGRAPH]]</code> \|\| 2D & 3D graphics rendering engine. Allows up to 4 buffers to be used for rendering 2D and 3D graphics (mostly DirectX 5.0 and OpenGL 1.1 compliant); can render graphics at 8, 16 or 32bpp in 2D at up to theoretical maximum resolution (set by <code>PFB</code>) of 20481536 (but in practice 19201200, sometimes 16001200) and up to 960720 (NV3) or 1600*1200 (?) (NV3T) at 16bpp for 3D.
	\|-		\|-
	\| <code>0x400648</code> (index) \|\| <code>0x40064C</code> (address/data) \|\| <code>[[NV3 ~~DPRAM~~\|~~DPRAM~~]]</code> \|\| Internal port (as part of <code>PGRAPH</code>) to access on-die texture and vertex cache (12 KB)		\| <code>0x400648</code> (index) \|\| <code>0x40064C</code> (address/data) \|\| <code>[[NV3 PGRAPH cache\|PGRAPH_CACHE]]</code> \|\| Internal port (as part of <code>PGRAPH</code>) to access on-die texture and vertex cache (12 KB)
	\|-		\|-
	\| <code>0x410000</code> \|\| <code>0x411FFF</code> \|\| <code>[[NV3 graphics objects#UBETA\|UBETA]]</code> \|\| Internal write-only registers used while executing methods for the beta factor object		\| <code>0x410000</code> \|\| <code>0x411FFF</code> \|\| <code>[[NV3 graphics objects#UBETA\|UBETA]]</code> \|\| Internal write-only registers used while executing methods for the beta factor object

NV3 Getting Started

Starfrost — Wed, 11 Nov 2026 00:52:17 GMT

Show changes

Timeline

Starfrost — Wed, 11 Nov 2026 00:26:16 GMT

← Older revision		Revision as of 00:26, 11 November 2026
Line 70:		Line 70:
	* April 8, 1993: Curtis Priem changes the description of his SPARCstation 1 UUCP server to read "Nvidia"<ref>UUCP Mapping Project: https://groups.google.com/g/comp.mail.maps/c/QmEyGC73D_c/m/34dhQKz4ZOYJ</ref>		* April 8, 1993: Curtis Priem changes the description of his SPARCstation 1 UUCP server to read "Nvidia"<ref>UUCP Mapping Project: https://groups.google.com/g/comp.mail.maps/c/QmEyGC73D_c/m/34dhQKz4ZOYJ</ref>
	* Mid 1993: Nvidia, despite a bad pitch involving a commodity PC being hacked to use a Sun GX, receives $4 million in seed funding from Sutter Hill Ventures and Sequoia Capital, mostly due to the founders' reputation. Shortly after this, the company rented office space in Sunnyvale, California. <ref>The Nvidia Way (Kae, Tim; 2024), pp. 53. ISBN 9781324086710).</ref>		* Mid 1993: Nvidia, despite a bad pitch involving a commodity PC being hacked to use a Sun GX, receives $4 million in seed funding from Sutter Hill Ventures and Sequoia Capital, mostly due to the founders' reputation. Shortly after this, the company rented office space in Sunnyvale, California. <ref>The Nvidia Way (Kae, Tim; 2024), pp. 53. ISBN 9781324086710).</ref>
	* June 29, 1993: Nvidia refiles its articles of incorporation to allow the issuance of "Series A" ~~stock~~ shares to third parties other than the founders. This is most likely an ~~approximate~~ date ~~to when~~ Sutter Hill and Sequoia invested.		* June 29, 1993: Nvidia refiles its articles of incorporation to allow the issuance of "Series A" venture capital shares to third parties other than the founders. This is most likely an approximation of the date that Sutter Hill and Sequoia invested in the company.
			* September 7, 1993: Oldest known date for a file in any Nvidia source code. This file is OS.C, which is the interface between the Resource Manager and its underlying operating system.
	* October 20, 1993: Version 1.0 of the "NV Architecture Specification" document is produced; it is an overview of the architecture of the graphics accelerators that Nvidia intends to build.<ref>SGS-Thomson/Nvidia Strategic Collaboration Agreement (SEC filing), including 1996 and 1998 amendments. Available online at https://contracts.onecle.com/nvidia/sgs.collab.1993.11.10.shtml)</ref>		* October 20, 1993: Version 1.0 of the "NV Architecture Specification" document is produced; it is an overview of the architecture of the graphics accelerators that Nvidia intends to build.<ref>SGS-Thomson/Nvidia Strategic Collaboration Agreement (SEC filing), including 1996 and 1998 amendments. Available online at https://contracts.onecle.com/nvidia/sgs.collab.1993.11.10.shtml)</ref>
	* November 1993: Pellucid is taken over by another company called Media Vision to develop sound cards and 2D/3D graphics products.		* November 1993: Pellucid is taken over by another company called Media Vision to develop sound cards and 2D/3D graphics products.
Line 101:		Line 102:

	== 1996 ==		== 1996 ==
	February 9, 1996: NVIDIA NV2 hardware reference file NV2_REF.H is compiled.		* February 9, 1996: NVIDIA NV2 hardware reference file NV2_REF.H, version 4, is compiled.
	May 21, 1996: NVIDIA receives the source code to the cancelled WEITEK Power 9100 successor and starts modifying it to become the NV3 VBIOS.		* February 1996: Around this time, the NV2 is cancelled by Sega; Nvidia enters into severe financial stress and lays off most of its employees.
			* May 21, 1996: NVIDIA receives the source code to the cancelled WEITEK Power 9100 successor and starts modifying it to become the NV3 VBIOS.

	== Notes ==		== Notes ==
	== References ==		== References ==

Software

Starfrost — Sun, 08 Nov 2026 18:28:33 GMT

← Older revision		Revision as of 18:28, 8 November 2026
Line 55:		Line 55:
	\| Android \|\| Full drivers, also <code>nv</code>		\| Android \|\| Full drivers, also <code>nv</code>
	\|-		\|-
	\| Linux \|\| Initially <code>nv</code> or open-source ~~project~~ only, later full drivers.		\| Linux \|\| Initially <code>nv</code> or open-source projects only, later full drivers.
	\|-		\|-
	\| BeOS, Haiku, EOS, AsusWRT (linux-based) \|\| These OSes support the <code>nv</code> driver only		\| BeOS, Haiku, EOS, AsusWRT (linux-based), RISC OS (Iyonix machines only) \|\| These OSes support the <code>nv</code> driver only
	\|-		\|-
	\| OS/2 \|\| Full drivers		\| OS/2 \|\| Full drivers