Page 1 of 10 123 ... LastLast
Results 1 to 10 of 100

Thread: What Is AtomBIOS & These Different Drivers?

  1. #1
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,571

    Default

    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 x86 (or whatever) code 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)
    - source code in xorg/driver/xf86-video-ati, xorg/driver/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
    - 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

    Gallium vs Mesa

    Gallium 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.
    Last edited by bridgman; 12-19-2008 at 11:05 AM.

  2. #2
    Join Date
    Oct 2007
    Location
    Roanoke, VA
    Posts
    228

    Default

    Excellent info, bridgman... thanks.
    Last edited by Porter; 02-19-2008 at 06:41 PM.

  3. #3
    Join Date
    Mar 2007
    Location
    West Australia
    Posts
    376

    Default

    I haven't tried the radeon driver. The radeonhd driver works well. fglrx driver isn't working anymore. Not sure why but I'm happy on radeonhd. The x1600 pro is pretty happy on that machine.

    I had a feeling it would take at least 6 months before the radeonhd drivers kicked into gear.

    By looks of things the NDA looked like a huge stall on development time. Especially since the person has all that talent sitting there. :/ In the long run I guess it was for the better though.

    I always wondered what this AtomBIOS was. Glad someone could clarify in user terms. Now if only sound cards implemented such intelligent features.
    Last edited by b15hop; 06-13-2008 at 02:33 PM.

  4. #4
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,571

    Default

    NDA ?

    EDIT - oh, Dave's NDA. Yes, that took a while to clear up because we had to find a way to formally and legally document common sense. That is never easy
    Last edited by bridgman; 06-13-2008 at 10:51 PM.

  5. #5
    Join Date
    Sep 2008
    Posts
    21

    Default

    do you meen to tell me that Phoronix.com is largely responsible for open source video drivers development ?

  6. #6
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,806

    Default

    Quote Originally Posted by monohouse View Post
    do you meen to tell me that Phoronix.com is largely responsible for open source video drivers development ?
    I strongly suspect he made that comment as a representative of AMD. (Very likely not as the company's official statement though but as a personal point of view )

  7. #7
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by bridgman View Post
    OK, let's see. Let me do the AtomBIOS part first, it's shorter.
    Heh... Not by much, though... Thanks on the summary, it's perhaps the best capsule summary of all of what's going on right at the moment in the space.

  8. #8
    Join Date
    Jun 2008
    Posts
    61

    Default

    Well.. It made me confused even more...

    You said DDX driver "handles display/modesetting, 2D and video acceleration, memory management", and 3D -- is under Mesa's responsibility..

    Also, it's said, that both radeon and radeonhd can do basic tasks, like modesetting.

    Why 3D is not available with radeonhd, used as DDX driver; when the same card(with the same Mesa) can do 3D, if DDX driver is radeon?...

  9. #9
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,806

    Default

    Quote Originally Posted by mityukov View Post
    Well.. It made me confused even more...

    You said DDX driver "handles display/modesetting, 2D and video acceleration, memory management", and 3D -- is under Mesa's responsibility..

    Also, it's said, that both radeon and radeonhd can do basic tasks, like modesetting.

    Why 3D is not available with radeonhd, used as DDX driver; when the same card(with the same Mesa) can do 3D, if DDX driver is radeon?...
    I don't think he said it can do it for every chipset. If you have r600 or newer, nothing released opensource can do it yet afaik. Just having 3D acceleration doesn't mean you have it for every single chipset.

  10. #10
    Join Date
    Jun 2008
    Posts
    61

    Default

    I mean.. Does radeonhd has comparable 3D facilities for R500 (which is commonly supported by both drivers)?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •