Accelerated Graphic Cards: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
(Added reference to the ViRGE driver forum thread)
mNo edit summary
 
(39 intermediate revisions by 9 users not shown)
Line 1: Line 1:
While it is nice to have some graphics on the screen, it would be even nicer to have the video card do the dirty work. Beware though, things are not always as easy as they seem.
While it is nice to have some graphics on the screen, it would be even nicer to have the video card do the dirty work. Beware though, things are not always as easy as they seem.
<!-- Alternative [[VESA BIOS Extension/Accelerator Functions]] (this doesn't seem to be updated for a decade, probably best to delete this instead) -->


== Cards with documentation ==
== Cards with documentation ==

=== 3Dfx ===
=== 3Dfx ===
These are a sort of good news for 3dfx cards (those with a Voodoo chipset). These cards could be the only ones with relatively fast 3D support (Glide/OpenGL) and [http://digilander.libero.it/F1Land/3dfxarchive/ open specifications]. Voodoo cards are still available from sources such as eBay.
These are a sort of good news for 3dfx cards (those with a Voodoo chipset). These cards could be the only ones with relatively fast 3D support (Glide/OpenGL) and [http://darwin-3dfx.sourceforge.net/ open specifications]. Voodoo cards are still available from sources such as eBay.


=== Intel Integrated Graphics ===
=== Intel Integrated Graphics ===
Line 10: Line 10:
* [ftp://download.intel.com/support/graphics/intel740/29061902.pdf Intel 740 Graphics Accelerator]
* [ftp://download.intel.com/support/graphics/intel740/29061902.pdf Intel 740 Graphics Accelerator]
* [http://www.x.org/docs/intel/ Intel Graphics Documentations on X.org]
* [http://www.x.org/docs/intel/ Intel Graphics Documentations on X.org]
* [https://01.org/linuxgraphics/documentation/ Intel Graphics Documentation on the 01.org]


The intel-gpu-tools package mentioned on the 01.org page is recommended as it can be used to dump current register values for examination.
=== ATI / AMD ===
AMD has [[topic:14887|recently started]] to open up the specifications for their recent video cards. The ones regarding a R630 or M56 chip can be downloaded from [http://www.x.org/docs/AMD/ X.org].


=== ATI/AMD ===
== Where can I find low-level information about nVidia/Matrox/ATI/... 3D graphic cards? ==
[[topic:14887|Since September 2007]], AMD started opening up specifications for their recent GPUs.
The ones regarding a R630 or M56 chip can be downloaded from [https://www.x.org/docs/AMD/old/ X.org].


Since early 2014, AMD maintains up to date open programming guides for all their GPUs, including a specific email address for support.
Good question. Unless you find something else, there is virtually no information publicly available (for free or otherwise) about the internal workings of current 3D graphics cards. There are only small bits that are relevant to game programmers but nothing an OS developer could use.


X.org provides a documentation for AMD GPUs in [https://www.x.org/wiki/RadeonFeature/#index13h2 their website]. An official AMD Open GPU documentation is also available on [https://developer.amd.com/resources/developer-guides-manuals/#open_gpu AMD's website] and an implementation for the Linux kernel is available on [https://github.com/GPUOpen-Drivers/AMDVLK GitHub].
Now, if you have a VIA graphics chip, things may be better since they recently released an [http://www.viaarena.com/default.aspx?PageID=2&Type=4 open source driver] for both 2D and 3D operations.


=== NVIDIA ===
There are virtually no tutorials or datasheets for the 2D acceleration features either, but at least we have open-source code for them. Among other sources, the Xfree drivers, [http://cvs.sourceforge.net/viewcvs.py/open-beos/current/src/add-ons/accelerants/ BeOS accelerants] and [http://www.talula.demon.co.uk/freebe/ FreeBE/AF]. They may provide enough information to reverse-engineer and figure out a model that could be used to program/port for your environment. Some older cards with only 2D acceleration might be documented by the [http://pdos.csail.mit.edu/6.828/2008/readings/hardware/vgadoc/ VGADoc].
<!-- NVIDIA now provides official documents for their GPUs and open sources their GPU drivers for Linux


NVIDIA doesn't provide official specifications, but a lot of community effort is spent in the [http://nouveau.freedesktop.org/wiki/ nouveau] project, which can be sourced for examples and documentation even though such reverse engineered specifications aren't complete nor guaranteed to be accurate. Marcin Kościelnicki has been writing down unofficial specs in his [http://0x04.net/cgit/cgit.cgi/envytools/tree/ envytools] repository (the link is dead, however envytools is [https://github.com/envytools/envytools available on GitHub]).
Although having missing bits here and there, they are certainly an interesting resource for learning about the internals of these graphic cards. These docs cover the entire range of NVIDIA hardware, from the first to the latest card, and might prove sufficient to write a native driver.
-->

NVIDIA now provides official documentations for most of their GPUs [https://nvidia.github.io/open-gpu-doc/ on GitHub] and open sourced their Linux kernel module for their GPUs [https://github.com/NVIDIA/open-gpu-kernel-modules also on GitHub]. Before NVIDIA officially open sourced their GPU stuff, there are many NVIDIA GPU reverse engineering projects like [http://nouveau.freedesktop.org Nouveau] and [https://github.com/envytools/envytools EnvyTools] and a group of hackers even leaked most of NVIDIA's GPU stuff like documentation and even full-on reference FPGA codes, which led to NVIDIA officially open sourcing of their GPU documentation and Linux kernel module. Most of these reverse engineering project aren't complete unlike NVIDIA's official documentation but you can still use it as an another source of NVIDIA GPU documentation in addition with NVIDIA's official open source documentation.

=== VMware SVGA-II ===
Not exactly an actual GPU, but the [[VMWare SVGA-II]] device makes for a nice virtual machine device for some 3D acceleration. It is available on both VMware and QEMU. A well-documented and easy-to-port reference driver has also been made available by VMware under the MIT license. Although it is deprecated, the device works perfectly fine under QEMU and is relatively simple to work with, thus it makes for a very good starting point for graphics acceleration. Reference driver available at [http://vmware-svga.sourceforge.net/index.old.html the old vmware-svga page on SourceForge].

== Where can I find low-level information about NVIDIA, AMD, and other graphic cards? ==
Good question. Unless you find something else, there is virtually no information publicly available (for free or otherwise) about the internal workings of current GPUs. There are only small bits that are relevant to game programmers but nothing an OS developer could use.

Now, if you have a VIA integrated GPU, things may be better since they released an [http://linux.via.com.tw/ open source driver] for both 2D and 3D operations.

There are virtually no tutorials or datasheets for the 2D acceleration features either, but at least we have open-source code for them. Among other sources, the X.org/XFree86 drivers, [https://github.com/haiku/haiku/tree/master/src/add-ons/accelerants Haiku (was Open BeOS) accelerants] and [http://www.shawnhargreaves.com/freebe/ FreeBE/AF]. They may provide enough information to reverse-engineer and figure out a model that could be used to program/port for your environment. Some older GPUs with only 2D acceleration might be documented by the [https://pdos.csail.mit.edu/6.828/2018/readings/hardware/vgadoc/ VGADoc] ([https://pdos.csail.mit.edu/6.828/2018/readings/hardware/vgadoc4b.zip vgadoc4b.zip], also on [https://github.com/achernya/iap-6.828-website/tree/master/readings/hardware/vgadoc GitHub]).
Anyone who wishes to put time into that kind of research is welcome to post their results here.
Anyone who wishes to put time into that kind of research is welcome to post their results here.


== What can 2D acceleration do for me? ==
== What can 2D acceleration do for me? ==

* Hardware mouse cursor, drawn and managed (e.g. you provide coordinates, the card does the rest)
* Hardware mouse cursor, drawn and managed (e.g. you provide coordinates, the card does the rest)
* Bitblt (for "BIT BLock Transfer") can be used for screen-to-screen memory copy like windows moving, scrolling, etc. You provide from and to boxes and the card does the rest. Some might know this as the "rasterop" or remember the hardware "blitter" in Amiga computers.
* Bitblt (for "'''BIT''' '''BL'''ock '''T'''ransfer") can be used for screen-to-screen memory copy like window moving, scrolling, etc. You provide from and to boxes and the card does the rest. Some might know this as the "rasterop" or remember the hardware "blitter" in Amiga computers.
* Tiles. You enter a small NxN dataset (usually a bitmap of between 8x8 and 32x32), a foreground color and a mixing style plus some coordinates and the card "paints" the area with the given pattern. That can be handy to render Win95-like backgrounds (tiled ones) or even to draw fonts quickly.
* Tiles. You enter a small NxN dataset (usually a bitmap of between 8x8 and 32x32), a foreground color and a mixing style plus some coordinates and the card "paints" the area with the given pattern. That can be handy to render Win95-like backgrounds (tiled ones) or even to draw fonts quickly.


== How do 3D-accelerated programs talk to 3D-accelerating hardware? ==
== How do 3D-accelerated programs talk to 3D-accelerating hardware? ==
Let's assume that you have a strong knowledge of OpenGL and that you don't need it covered here. If you take the example of NVIDIA's GPU driver for Linux (if you have a correctly configured NVIDIA GPU, you can see almost all this by a simple "strace" on a 3D program in linux), things are organized this way:

I'll be assuming that you have a strong knowledge of OpenGL etc and that you don't need it covered here. If you take the example of nVidia's 3D driver for linux (if you have a correctly configured nVidia card, you can see almost all this by a simple "strace" on a 3D program in linux), things are organized this way:


* Two libraries libGL.so and libGLcore.so will be loaded by any program that wishes to do accelerated 3D operations. Upon startup, those libraries open "/dev/nvidiactl" and "/dev/nvidia0".
* Two libraries libGL.so and libGLcore.so will be loaded by any program that wishes to do accelerated 3D operations. Upon startup, those libraries open "/dev/nvidiactl" and "/dev/nvidia0".
<!-- Since the kernel module is now open sourced, should this section removed completely? -->
* The kernel module is made of an "obscure" file nv-kernel.o which contains only "anonymized" symbols and an "open source" part that mainly glues the nv-kernel (which is actually almost system transparent) to the linux kernel.
* The kernel module is made of an "obscure" file nv-kernel.o which contains only "anonymized" symbols and the open source part that mainly glues the nv-kernel (which is actually almost system transparent) to the Linux kernel.
* The actual "conversation" between the library and the driver cannot be traced: /dev/nvidia* only allows "ioctl" operations and mmap. The values you can observe in "/proc/XXXXX/maps" while the 3D program is running let me believe the driver actually exposes the hardware resources (e.g. texture space, vertex space, etc) directly to the library.
* The actual "conversation" between the library and the driver cannot be traced by conventional means: /dev/nvidia* only allows "ioctl" operations and mmap. The values you can observe in "/proc/XXXXX/maps" while the 3D program is running, which let us believe the driver actually exposes the hardware resources (e.g. texture space, vertex space, etc) directly to the library. Current Linux kernels can however be compiled with the mmiotrace option which can then be used to log all individual accesses to mmapped space.


l /proc/pci
l /proc/pci
Line 62: Line 79:


== External links ==
== External links ==
*[[topic:23548|A topic on duplicating/reverse engineering existing driver code]]
* [[topic:23548|A topic on duplicating/reverse engineering existing driver code]]

[[Category:Video]]
[[Category:Video]]

Latest revision as of 10:00, 6 March 2023

While it is nice to have some graphics on the screen, it would be even nicer to have the video card do the dirty work. Beware though, things are not always as easy as they seem.

Cards with documentation

3Dfx

These are a sort of good news for 3dfx cards (those with a Voodoo chipset). These cards could be the only ones with relatively fast 3D support (Glide/OpenGL) and open specifications. Voodoo cards are still available from sources such as eBay.

Intel Integrated Graphics

The Intel video chipsets also have open standards (see www.intel.com). Some useful links:

The intel-gpu-tools package mentioned on the 01.org page is recommended as it can be used to dump current register values for examination.

ATI/AMD

Since September 2007, AMD started opening up specifications for their recent GPUs. The ones regarding a R630 or M56 chip can be downloaded from X.org.

Since early 2014, AMD maintains up to date open programming guides for all their GPUs, including a specific email address for support.

X.org provides a documentation for AMD GPUs in their website. An official AMD Open GPU documentation is also available on AMD's website and an implementation for the Linux kernel is available on GitHub.

NVIDIA

NVIDIA now provides official documentations for most of their GPUs on GitHub and open sourced their Linux kernel module for their GPUs also on GitHub. Before NVIDIA officially open sourced their GPU stuff, there are many NVIDIA GPU reverse engineering projects like Nouveau and EnvyTools and a group of hackers even leaked most of NVIDIA's GPU stuff like documentation and even full-on reference FPGA codes, which led to NVIDIA officially open sourcing of their GPU documentation and Linux kernel module. Most of these reverse engineering project aren't complete unlike NVIDIA's official documentation but you can still use it as an another source of NVIDIA GPU documentation in addition with NVIDIA's official open source documentation.

VMware SVGA-II

Not exactly an actual GPU, but the VMWare SVGA-II device makes for a nice virtual machine device for some 3D acceleration. It is available on both VMware and QEMU. A well-documented and easy-to-port reference driver has also been made available by VMware under the MIT license. Although it is deprecated, the device works perfectly fine under QEMU and is relatively simple to work with, thus it makes for a very good starting point for graphics acceleration. Reference driver available at the old vmware-svga page on SourceForge.

Where can I find low-level information about NVIDIA, AMD, and other graphic cards?

Good question. Unless you find something else, there is virtually no information publicly available (for free or otherwise) about the internal workings of current GPUs. There are only small bits that are relevant to game programmers but nothing an OS developer could use.

Now, if you have a VIA integrated GPU, things may be better since they released an open source driver for both 2D and 3D operations.

There are virtually no tutorials or datasheets for the 2D acceleration features either, but at least we have open-source code for them. Among other sources, the X.org/XFree86 drivers, Haiku (was Open BeOS) accelerants and FreeBE/AF. They may provide enough information to reverse-engineer and figure out a model that could be used to program/port for your environment. Some older GPUs with only 2D acceleration might be documented by the VGADoc (vgadoc4b.zip, also on GitHub). Anyone who wishes to put time into that kind of research is welcome to post their results here.

What can 2D acceleration do for me?

  • Hardware mouse cursor, drawn and managed (e.g. you provide coordinates, the card does the rest)
  • Bitblt (for "BIT BLock Transfer") can be used for screen-to-screen memory copy like window moving, scrolling, etc. You provide from and to boxes and the card does the rest. Some might know this as the "rasterop" or remember the hardware "blitter" in Amiga computers.
  • Tiles. You enter a small NxN dataset (usually a bitmap of between 8x8 and 32x32), a foreground color and a mixing style plus some coordinates and the card "paints" the area with the given pattern. That can be handy to render Win95-like backgrounds (tiled ones) or even to draw fonts quickly.

How do 3D-accelerated programs talk to 3D-accelerating hardware?

Let's assume that you have a strong knowledge of OpenGL and that you don't need it covered here. If you take the example of NVIDIA's GPU driver for Linux (if you have a correctly configured NVIDIA GPU, you can see almost all this by a simple "strace" on a 3D program in linux), things are organized this way:

  • Two libraries libGL.so and libGLcore.so will be loaded by any program that wishes to do accelerated 3D operations. Upon startup, those libraries open "/dev/nvidiactl" and "/dev/nvidia0".
  • The kernel module is made of an "obscure" file nv-kernel.o which contains only "anonymized" symbols and the open source part that mainly glues the nv-kernel (which is actually almost system transparent) to the Linux kernel.
  • The actual "conversation" between the library and the driver cannot be traced by conventional means: /dev/nvidia* only allows "ioctl" operations and mmap. The values you can observe in "/proc/XXXXX/maps" while the 3D program is running, which let us believe the driver actually exposes the hardware resources (e.g. texture space, vertex space, etc) directly to the library. Current Linux kernels can however be compiled with the mmiotrace option which can then be used to log all individual accesses to mmapped space.
l /proc/pci
Bus  0, device   0, function  0:
    Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev 196).
      Prefetchable 32 bit memory at 0xfc000000 [0xfdffffff].

Bus  1, device   0, function  0:
    VGA compatible controller: nVidia Corporation RIVA TNT2 Model 64 (rev 21).
      IRQ 11.
      Master Capable.  Latency=248.  Min Gnt=5.Max Lat=1.
      Non-prefetchable 32 bit memory at 0xf7000000 [0xf7ffffff].
      Prefetchable 32 bit memory at 0xfa000000 [0xfbffffff].
cat /proc/XXXXX/maps
...
40019000-40029000 rw-s f7810000 03:06 54934      /dev/nvidia0
40029000-4002a000 rw-s 0ba98000 03:06 54934      /dev/nvidia0
...
40a9b000-42a9b000 rw-s fa000000 03:06 54934      /dev/nvidia0
42a9b000-42b79000 rw-p 00000000 00:00 0
42b79000-42c7a000 rw-s fc010000 03:06 54934      /dev/nvidia0
42c7a000-42d7c000 rw-p 00000000 00:00 0
42d7c000-42dfc000 rw-s fc111000 03:06 54934      /dev/nvidia0

External links