No announcement yet.

What Is AtomBIOS & These Different Drivers?

  • Filter
  • Time
  • Show
Clear All
new posts

  • bridgman
    started a topic What Is AtomBIOS & These Different Drivers?

    What Is AtomBIOS & These Different Drivers?

    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, 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.
    Last edited by bridgman; 12-09-2017, 11:10 AM.

  • rjaduthie
    Thanks for this explanation. I've been on a mission to understand the software stack on my computers, especially the graphics. For one reason, my current systems are stuck with fglrx or radeon (e.g pre-GCN). I have it from a good source that the radeon driver is a pretty good performer wrt the proprietary fglrx. However, navigating the discussion of mesa-this, gallium-that, vulkan-the-other, I've a way to go, but am getting a better handle on it. I think if I ever get around to experimenting with coding around the linux graphics ecology, then I'll learn!

    Leave a comment:

  • bridgman
    Originally posted by b15hop View Post
    Here from Australia.
    If it helps, I believe Dave Airlie works out of the Red Hat office in Brisbane.

    I have not confirmed this visually though, since my last trip to Australia happened before he moved out there

    Leave a comment:

  • debianxfce
    Originally posted by srkelley5 View Post
    I'm planning to make the switch back to Linux (probably Ubuntu or Opensuse)
    Debian is much better that its derivates, lighter, faster and stable. You want the original, not cake over cake versions. In opensuse you need to update all packages, in Debian testing you can update what you want and when ever you want. Amdgpu works for your both machines so it is better get used to that when it is the future driver from Amd.
    Last edited by debianxfce; 04-24-2016, 10:09 AM.

    Leave a comment:

  • srkelley5
    I came here to try to learn more about the differences between the drivers (I used to understand it, but have recently let a giant brain fart cause permanent damage).

    I'm mostly trying to understand which drivers would be the best for gaming for my desktop and for my laptop. My desktop uses a R9 270 (original, no X). It actually has two, but I disable the second one since I only have 2/3 games that can marginally benefit from it.

    The other is an A8-6410 ( I'm not expecting to play anything demanding on it, but if I could play Civ V on low settings, and stable, I would consider that mission accomplished. I'm planning to make the switch back to Linux (probably Ubuntu or Opensuse) at the end of this month or the middle of May. I just have a ton of files on both that I need to finish organizing then back-up. Anything that can help make picking the best driver for gaming on each machine would be greatly appreciated.

    Leave a comment:

  • Aisyk
    Thanks for your response !

    I have a X1250 (RS690M) on a Notebook (MSI U210). I have some artefact when i connect a second screen (need to have only one screen), and with Cinnamon on my Linux Mint 17.3 (only black rectangles on windows decorations). For now, i have the defaults drivers, but i'm interesting in change for a better thing...

    Leave a comment:

  • bridgman
    Originally posted by Aisyk View Post
    We have :
    Radeon SI
    Gallium3D (directx 9 ?)
    Radeon Xorg driver
    Mesa ? (not just for intel ?)

    I'm a little lost between theses drivers, someone can explain me which are the best, active or inactive (most or less), or future ?
    The answer depends a lot on your hardware - which GPU do you have, or are you thinking about newest HW ?

    In general though...

    * amdgpu can refer to four different things:

    - the backend (code generator) in the LLVM compiler that generates code for AMD GPUs
    - a Linux kernel driver written for GCN hardware and up, currently enabled by default upstream for VI only
    - an all-open driver stack including the kernel driver, libdrm, OpenGL / OpenCL / video via Mesa (radeonsi), and amdgpu (or modesetting ?) X driver
    - a hybrid driver stack including the kernel driver, libdrm, amdgpu X driver, video via Mesa(radeonsi) and OpenGL/OpenCL/Vulkan via Catalyst closed drivers

    * radeonsi is one of the Gallium3D pipe drivers in Mesa, supporting GCN hardware and up, used by other Mesa code for OpenGL, OpenCL and video

    * Gallium3D is a HW driver framework used by a number of different driver stacks, including radeon/amdgpu, nouveau and others, supporting three major components:

    - state tracker (implements a specific API, eg OpenGL)
    - pipe driver (includes most of the HW-specific code, used by state trackers)
    - winsys driver (includes the OS-specific code and typically some HW-specific as well, used by pipe driver to talk to kernel driver)

    * Nine (from your directx9 reference) is a Gallium3D state tracker which helps to implement the DX9 API

    * Radeon Xorg driver - one of three X drivers commonly used with AMD hardware (currently for CI and back), others being amdgpu and modesetting

    * Vulkan is a recently released new Khronos API, evolved from the "GL Next" initiative but lower level than OpenGL, more like Mantle or DX12

    * Mesa started as a software implementation of OpenGL but evolved into the main project for open source GPU acceleration, including support for multiple HW vendors (via pipe drivers), multiple APIs (via state trackers) and multiple OSes (via winsys drivers)

    Mesa includes a few different generations of HW driver frameworks - Gallium3D is one, "classic Mesa" is another - I believe Intel uses a heavily upgraded "classic" driver framework while code for most other vendors uses Gallium3D. The relative merits of the two are discussed annually at XDC and monthly here, along with the ever-popular "LLVM or something else for shader compiler ?" topic

    Leave a comment:

  • debianxfce
    Originally posted by mibo View Post
    If this first page gets updated...
    I would like to learn, what this "NINE" og "Gallium NINE" that is sometimes used in the forum means.
    Wikipedia tells me about a Gallium driver for DX9 - so probably only used by wine for playing Windows games, right?
    Which drivers support NINE (radeonSI, AMDGPU, fglrx)? Does it require a special wine or a special driver setting?
    The Czech web page that my search engine found is empty:

    You can find the nine sources from git and I did try to compile wine gallium nine version without luck, you need to also compile xorg and use radeon kernel driver. many packages you need to install before compilation. For ubuntu there is also ppa. Much easier is to use wine-staging max version 1.9.5 (1.9.6 has dropped csmt multithread support and has 50% slower fps). Wine-staging works with all 3 drivers at the same frame rate in my pc.
    Last edited by debianxfce; 03-28-2016, 02:24 AM.

    Leave a comment:

  • mibo
    If this first page gets updated...
    I would like to learn, what this "NINE" og "Gallium NINE" that is sometimes used in the forum means.
    Wikipedia tells me about a Gallium driver for DX9 - so probably only used by wine for playing Windows games, right?
    Which drivers support NINE (radeonSI, AMDGPU, fglrx)? Does it require a special wine or a special driver setting?
    The Czech web page that my search engine found is empty:


    Leave a comment:

  • b15hop
    Originally posted by bridgman View Post
    We went kinda global -- Michel and Christian are in Europe, Alex and Tom are in North America.
    ~crickets noises~

    Here from Australia.

    Leave a comment: