The future of AMD/ATI drivers

[bridgman]

Sadly, in all of that very well written and informative post, not a single peep about video codec acceleration. Are there really more people using computers out there who care about 3D games than there are just trying to watch a movie on their "HD-compatible" machines?

Good point. I added 4b. above...

[dptkby]

Does that help, or did I make things worse ? I guess this would have been a great blog post TWO YEARS AGO

Sure it helps! I've been reading your replies and your "What is AtomBIOS... "-post, eventually things will fall into place, though I admit I'm not quite there yet .

Some questions, or thoughts, crop up:

So; today 2D acceleration is in X driver and either accesses hardware directly or through drm if you need it to play nicely with 3D acceleration (is this "direct rendering mode"?). What role does DRI play here?

Also, the "What is AtomBIOS..."-post states that in direct rendering mode "interface lib calls Mesa directly". What is the "interface lib" in this case? And does the radeonhd/radeon drivers provide hardware-specific code for Mesa as well (or why do *they* have to support 3D acceleration, as they do for some chipsets, according to their websites?).

Now, these are probably questions I'll figure out the answers to myself, sooner or later, but I appreciate your (or anyone elses) explanations very much!

[bridgman]

The term DRI is over-used IMO - strictly speaking it means one of two things :

- the entire set of components (direct rendering driver, kernel driver, X driver, libraries etc..) which work together to support direct rendering
- a specific X server extension (API) used by other DRI components

See http://dri.sourceforge.net/doc/DRIintro.html for an overview of DRI. The actual DRI extension is in section 5.5.

If you are only accelerating X server functions (eg XAA, EXA, Xv) through drm then you aren't really "using DRI", however the code which "initializes DRI" also initializes the drm driver in the kernel. As a result, you will usually be told to "enable DRI" to get 2D acceleration even though it's only the drm you are using and not the actual DRI protocol.

Note that for 5xx and up the 3D engine is only used through drm. It should be possible to use the 5xx 3D engine without drm but we don't bother. For 6xx and up the logic which allowed the 3D engine to be used without a ring buffer (typically managed by drm) was removed.

"Direct Rendering" means "not sending your drawing commands through the X wire protocol and having the X server call the driver", so the current 2D acceleration protocols are always "indirect" since XAA, EXA and Xv always go through the X server. It is possible to write a 2D acceleration API which *does* use direct rendering and does *not* go through the X server, but I haven't seen one yet -- so far all of the "2D via direct rendering" implementations have used the 3D driver to perform the 2D operations.

The "interface lib" is libGL : see http://dri.freedesktop.org/wiki/libGL. It either calls the 3D driver directly ("direct rendering") or uses the GLX extension (GL over X) to send commands to the X server, so that the X server can call the 3D driver ("indirect rendering").

Regarding radeon/radeonhd "supporting 3D acceleration", the drivers need to do three things to "support 3D" :

1. initialize the drm and use it for all acceleration commands (so that drm can coordinate hardware accesses between X and mesa drivers)

2. support the DRI protocol (so that direct rendering drivers know where their windows are, among other things)

3. know the proper name of the 3D driver

In the case of radeonhd, the initial 2D acceleration on 5xx/690 did not use drm, so it was not possible to use 2D and 3D acceleration at the same time (without drm, hardware accesses from 2D and 3D would not be coordinated).