OK, let's see. Let me do the AtomBIOS part first, it's shorter.
There have always been debates in the driver development world (both open and closed source) about whether relying on BIOS calls is a Good Thing or a Bad Thing. The benefits are obvious -- the BIOS provides a great way for a manufacturer to store any board- or chip-specific programming info or tables (rather than having to update the driver for every single board and laptop in the market) but there are some obvious drawbacks as well. The main ones are (a) BIOS code is traditionally x86 assembler which requires an emulator to run on non-x86 processors, and the API specs for BIOS are very restrictive, ie a driver can call BIOS to change modes but only to modes which are natively supported by the BIOS.
AtomBIOS is our (ATI/AMD)'s solution to keep the benefits of leveraging BIOS without the drawbacks. Rather than being a big mess of x86 code, it contains a small interpreter written in C (but compiled to x86) plus the actual BIOS code written in a portable interpreted language. As part of the open source initiative, we released C source code for the interpreter plus header files and a bit of documentation describing how to use the available calls and to interpret the data tables in each BIOS ROM.
The big benefit of AtomBIOS from our perspective is that it allows a driver to use BIOS calls for many of the functions, simplifying the task of supporting new ASICs and boards, but avoids most of the drawbacks which normally come with reliance on VBIOS.
Now, back to drivers. It's not really three -- there are at least five X drivers worth understanding :
1. Fglrx is the proprietary driver developed by ATI/AMD. Used to be targeted entirely at workstations but we are now working on ramping up support for consumer users.
2. Avivo was the first open source driver to support 5xx/6xx. Developed primarily with reverse engineered information by a team including Jerome Glisse, [EDIT] Daniel Stone, Matthew Garrett and others (sorry for anyone I left out). When we announced formal support for open source development the Avivo guys wound down avivo development and moved onto other interesting areas like kernel modesetting and reverse-engineering NVidia products
3. Radeon (aka xf86-video-ati) is probably the best known ATI open source driver, historically supporting everything from R100 to R4xx, although everything past R2xx was pretty heavily dependent on reverse engineered info. ATI contributed a bit past R200 but not much. A number of folks were involved in the development over time (pretty much every famous name in open source graphics has contributed to it) but Dave Airlie and Alex Deucher have been the primary contributors over the last couple of years
4. Dave Airlie wrote a 5xx driver which was never released. Dave had access to R5xx programming information under NDA via his employer a couple of years ago. He wrote a 5xx driver using that information (no problem as long as he didn't release it) then contacted us for permission to release the driver and associated header files. We were not able to give Dave approval to release the driver so he buried it and stayed away from R5xx open source development to avoid any risk of violating NDA.
5. Radeonhd is the most recently created driver. When we decided to ramp up support for open source development, we partnered with the Novell/SuSE development team (Luc, Egbert and Matthias plus others) to produce an all new display driver for 5xx and up. This was released in September as the radeonhd driver.
In the meantime, a number of interesting things happened :
- Dave Airlie joined Red Hat to work on graphics drivers but still had to stay away from 5xx development because of the information he had under NDA. We eventually worked through the legal details so that Dave could work on 5xx and 6xx parts without NDA concerns.
- Dave and Alex were interested in AtomBIOS so they added 5xx/6xx support to the display driver making heavy use of the AtomBIOS calls. One side effect of this was that there were two drivers supporting 5xx/6xx, but since some parts of the 5xx chips really haven't changed from earlier generations (eg. 2d acceleration) there are some real opportunities to speed up development by leveraging existing radeon code
- Alex recently joined AMD to help drive the documentation and support efforts and to work on driver development as part of his day job rather than a hobby, so he is actually helping with both radeonhd and radeon efforts.
I expect that over time the two open drivers (radeonhd and radeon) will grow together but realistically I don't expect that to happen for at least six more months. In the meantime, though, code and ideas are moving back and forth between the drivers (including avivo) and I expect that will continue for quite a while.
In terms of differences between the drivers, here's one way to look at them. Others may jump in and disagree.
- fglrx has the most features and capabilities, and runs most games quite a bit faster than the open source drivers. Downside is that it is closed source and when there is a problem you often have to wait for the next release or more.
- radeonhd is the most polished on 5xx/6xx and has the most resources working on end user issues. Downside is that it is display/modesetting only, although on a modern system you can still get some pretty nice performance without acceleration.
- radeon has immediate access to all the code and experience from previous ATI chip generations, including 2d, 3d and video acceleration. On 5xx/6xx it is primarily display/modesetting as well, however 2d acceleration is running on 5xx today.
EDIT - as of late 2008 the radeon and radeonhd drivers are at roughly the same level in terms of features and support. New GPU support has generally gone into radeonhd first, while initiatives which affect multiple GPU generations have generally gone into radeon first since changes there can be used on a broader range of GPUs (right back to R100 in cases).
For a full graphics stack you need three different drivers :
1. X driver
- sometimes referred to as DDX
- handles display/modesetting, 2D and video acceleration
- accesses hardware directly for modesetting; acceleration can access hardware directly or use drm driver
- acceleration must go through drm driver if also running 3D
- modesetting is starting to migrate to kernel/drm; for "kernel modesetting" (KMS) the X driver calls drm to set modes
- memory management is done by X driver today but starting to migrate to kernel/drm (GEM, TTM) (now fully migrated)
- started using glamor (X rendering on OpenGL) rather than writing separate acceleration code beginning with SI hardware
- generic "modesetting" driver introduced recently, uses standard glamor and kms interfaces
- source code in cgit.freedesktop.org/xorg/driver/xf86-video-ati, xf86-video-amdgpu, xf86-video-modesetting, xf86-video-radeonhd
2. DRM aka kernel driver
- manages DMA mechanism for feeding commands to GPU, typically ring buffer
- starting to include memory management and modesetting (as these move from X driver to drm)
- comes built into kernel or you can download & install a newer copy
- kernel driver source in Linus's tree at drivers/gpu/drm/<driver>
- userspace wrapper library source code in mesa/drm
3. Mesa aka 3D driver
- originally written for software rendering, accessed via X server ("indirect rendering")
- hardware acceleration added years ago; interface for plugging in hardware drivers
- Mesa itself supports full GL 2.1, most hardware drivers support less
- submits commands to GPU via drm driver (#2 above)
- two modes - "direct" rendering (interface lib calls Mesa directly) or "indirect" rendering (interface lib passes commands to X server, X server calls Mesa)
- when running "direct" rendering the DRI protocols allow 3D and 2D (X) drivers to work together
- when running "indirect" rendering the X server can coordinate everything itself and convert pixmaps to textures for compositing through GL
- Accelerated Indirect GL rendering through X = AIGLX
Gallium3D vs Mesa
Gallium3D is a new low-level API developed by Tungsten Graphics, which can either be called directly (using TGSI shader language) or be used as a foundation for building higher level drivers (OpenGL, DirectX etc). Gallium is being "built into" Mesa as a replacement for the existing Mesa hw driver model, among other things.
ATI's initial Linux driver support was developed via contract with Precision Insight back in ~1999. Precision Insight sort of became VA Linux, which sort of became Tungsten Graphics, which sort of became LunarG, who are now driving Vulkan implementation and adoption.
There have always been debates in the driver development world (both open and closed source) about whether relying on BIOS calls is a Good Thing or a Bad Thing. The benefits are obvious -- the BIOS provides a great way for a manufacturer to store any board- or chip-specific programming info or tables (rather than having to update the driver for every single board and laptop in the market) but there are some obvious drawbacks as well. The main ones are (a) BIOS code is traditionally x86 assembler which requires an emulator to run on non-x86 processors, and the API specs for BIOS are very restrictive, ie a driver can call BIOS to change modes but only to modes which are natively supported by the BIOS.
AtomBIOS is our (ATI/AMD)'s solution to keep the benefits of leveraging BIOS without the drawbacks. Rather than being a big mess of x86 code, it contains a small interpreter written in C (but compiled to x86) plus the actual BIOS code written in a portable interpreted language. As part of the open source initiative, we released C source code for the interpreter plus header files and a bit of documentation describing how to use the available calls and to interpret the data tables in each BIOS ROM.
The big benefit of AtomBIOS from our perspective is that it allows a driver to use BIOS calls for many of the functions, simplifying the task of supporting new ASICs and boards, but avoids most of the drawbacks which normally come with reliance on VBIOS.
Now, back to drivers. It's not really three -- there are at least five X drivers worth understanding :
1. Fglrx is the proprietary driver developed by ATI/AMD. Used to be targeted entirely at workstations but we are now working on ramping up support for consumer users.
2. Avivo was the first open source driver to support 5xx/6xx. Developed primarily with reverse engineered information by a team including Jerome Glisse, [EDIT] Daniel Stone, Matthew Garrett and others (sorry for anyone I left out). When we announced formal support for open source development the Avivo guys wound down avivo development and moved onto other interesting areas like kernel modesetting and reverse-engineering NVidia products
3. Radeon (aka xf86-video-ati) is probably the best known ATI open source driver, historically supporting everything from R100 to R4xx, although everything past R2xx was pretty heavily dependent on reverse engineered info. ATI contributed a bit past R200 but not much. A number of folks were involved in the development over time (pretty much every famous name in open source graphics has contributed to it) but Dave Airlie and Alex Deucher have been the primary contributors over the last couple of years
4. Dave Airlie wrote a 5xx driver which was never released. Dave had access to R5xx programming information under NDA via his employer a couple of years ago. He wrote a 5xx driver using that information (no problem as long as he didn't release it) then contacted us for permission to release the driver and associated header files. We were not able to give Dave approval to release the driver so he buried it and stayed away from R5xx open source development to avoid any risk of violating NDA.
5. Radeonhd is the most recently created driver. When we decided to ramp up support for open source development, we partnered with the Novell/SuSE development team (Luc, Egbert and Matthias plus others) to produce an all new display driver for 5xx and up. This was released in September as the radeonhd driver.
In the meantime, a number of interesting things happened :
- Dave Airlie joined Red Hat to work on graphics drivers but still had to stay away from 5xx development because of the information he had under NDA. We eventually worked through the legal details so that Dave could work on 5xx and 6xx parts without NDA concerns.
- Dave and Alex were interested in AtomBIOS so they added 5xx/6xx support to the display driver making heavy use of the AtomBIOS calls. One side effect of this was that there were two drivers supporting 5xx/6xx, but since some parts of the 5xx chips really haven't changed from earlier generations (eg. 2d acceleration) there are some real opportunities to speed up development by leveraging existing radeon code
- Alex recently joined AMD to help drive the documentation and support efforts and to work on driver development as part of his day job rather than a hobby, so he is actually helping with both radeonhd and radeon efforts.
I expect that over time the two open drivers (radeonhd and radeon) will grow together but realistically I don't expect that to happen for at least six more months. In the meantime, though, code and ideas are moving back and forth between the drivers (including avivo) and I expect that will continue for quite a while.
In terms of differences between the drivers, here's one way to look at them. Others may jump in and disagree.
- fglrx has the most features and capabilities, and runs most games quite a bit faster than the open source drivers. Downside is that it is closed source and when there is a problem you often have to wait for the next release or more.
- radeonhd is the most polished on 5xx/6xx and has the most resources working on end user issues. Downside is that it is display/modesetting only, although on a modern system you can still get some pretty nice performance without acceleration.
- radeon has immediate access to all the code and experience from previous ATI chip generations, including 2d, 3d and video acceleration. On 5xx/6xx it is primarily display/modesetting as well, however 2d acceleration is running on 5xx today.
EDIT - as of late 2008 the radeon and radeonhd drivers are at roughly the same level in terms of features and support. New GPU support has generally gone into radeonhd first, while initiatives which affect multiple GPU generations have generally gone into radeon first since changes there can be used on a broader range of GPUs (right back to R100 in cases).
For a full graphics stack you need three different drivers :
1. X driver
- sometimes referred to as DDX
- handles display/modesetting, 2D and video acceleration
- accesses hardware directly for modesetting; acceleration can access hardware directly or use drm driver
- acceleration must go through drm driver if also running 3D
- modesetting is starting to migrate to kernel/drm; for "kernel modesetting" (KMS) the X driver calls drm to set modes
- memory management is done by X driver today but starting to migrate to kernel/drm (GEM, TTM) (now fully migrated)
- started using glamor (X rendering on OpenGL) rather than writing separate acceleration code beginning with SI hardware
- generic "modesetting" driver introduced recently, uses standard glamor and kms interfaces
- source code in cgit.freedesktop.org/xorg/driver/xf86-video-ati, xf86-video-amdgpu, xf86-video-modesetting, xf86-video-radeonhd
2. DRM aka kernel driver
- manages DMA mechanism for feeding commands to GPU, typically ring buffer
- starting to include memory management and modesetting (as these move from X driver to drm)
- comes built into kernel or you can download & install a newer copy
- kernel driver source in Linus's tree at drivers/gpu/drm/<driver>
- userspace wrapper library source code in mesa/drm
3. Mesa aka 3D driver
- originally written for software rendering, accessed via X server ("indirect rendering")
- hardware acceleration added years ago; interface for plugging in hardware drivers
- Mesa itself supports full GL 2.1, most hardware drivers support less
- submits commands to GPU via drm driver (#2 above)
- two modes - "direct" rendering (interface lib calls Mesa directly) or "indirect" rendering (interface lib passes commands to X server, X server calls Mesa)
- when running "direct" rendering the DRI protocols allow 3D and 2D (X) drivers to work together
- when running "indirect" rendering the X server can coordinate everything itself and convert pixmaps to textures for compositing through GL
- Accelerated Indirect GL rendering through X = AIGLX
Gallium3D vs Mesa
Gallium3D is a new low-level API developed by Tungsten Graphics, which can either be called directly (using TGSI shader language) or be used as a foundation for building higher level drivers (OpenGL, DirectX etc). Gallium is being "built into" Mesa as a replacement for the existing Mesa hw driver model, among other things.
ATI's initial Linux driver support was developed via contract with Precision Insight back in ~1999. Precision Insight sort of became VA Linux, which sort of became Tungsten Graphics, which sort of became LunarG, who are now driving Vulkan implementation and adoption.
Comment