ATI R300 Gallium3D DRI Support Is "Done"

[MostAwesomeDude]

python is a Python binding that directly glues to a state tracker. I don't like it much; I'm sorely tempted to write my own.

wgl and egl are other windowing system trackers similar to dri; wgl is for Windows and egl is an implementation of the EGL standard.

g3dvl is the old video decoder Younes wrote for GSoC a few years ago. The Gallium API's changed and it's rotted a bit so there's ongoing work to refactor it into the rest of the codebase.

[pedepy]

sorry if it's a stupid question, but does that include R500 chips ? i have a mobility radeon x1600 (which is rv530 or something like that if i'm not mistaken) and i get worried whenever i see 'r300' this and 'r300' that in the logs ... i'm worried i'm not getting all of my card's worth, you know ?

not that i never see r500 mentioned anywhere, so i guess perhaps the driver does utilize some capacities not present in r300 cards.


maybe someone can shed a little light on this ?, as in, why do r500 cards always seem to be 'bundled up' with r300 in open source drivers while r600 and above seem to have their own thing going

[Adarion]

Cheers!

And damn. I'm "stuck" with 2 R600 chips. Well, but at least this will come next now. Still have to wait some time (or use fglrx).

To pedepy:
AFAIR the article says yes, R500 is also included in this "just R300 named" driver. R100, 200 had afaik more differences with the R300-R500 hardware while R300...500 are similar. R600 and up then have again more differences.

Here see the feature matrix:

http://www.x.org/wiki/GalliumStatus?action=show

r300 (ATI R300/R400/R500)
while
r600 is (ATI R600/R700/R800)

[bridgman]

The 3xx, 4xx and 5xx GPUs, along with the RS4xx and RS6xx IGPs, have the same basic 3D engine architecture so they're all handled by the same 3D hardware driver (r300 / r300g). The hardware implementation changed significantly from one generation to the next but the programming model didn't change much.

Same with 6xx, 7xx and Evergreen (r600 / r600g) - the hardware implementation changed significantly but the programming model stayed more or less constant.

One question I didn't see answered is "where is the state tracker for regular OpenGL". The answer is that the upper level mesa code acts as the OpenGL state tracker - it can either use "classic mesa" hardware drivers or Gallium3D drivers for hardware acceleration, determined at build time. The cool thing about Gallium3D is that the API allows the same hardware drivers that accelerate 3D to also be used for other things like video or 2D acceleration.

[V!NCENT]

One question I didn't see answered is "where is the state tracker for regular OpenGL". The answer is that the upper level mesa code acts as the OpenGL state tracker - it can either use "classic mesa" hardware drivers or Gallium3D drivers for hardware acceleration, determined at build time.

Is mesa solely a FLOSS implementation of the OpenGL spec in state tracker mode, or does it do more than just being an OpenGL implementation?

[bridgman]

I think strictly speaking it is a FLOSS implementation of an API similar to OpenGL

[V!NCENT]

I think strictly speaking it is a FLOSS implementation of an API similar to OpenGL

Which obviously leads me to ask you: in what ways does mesa differ from OpenGL?

PS: And why?

[bridgman]

http://www.mesa3d.org/license.html

[V!NCENT]

http://www.mesa3d.org/license.html

So basically the flow of code may differ from the official implementation, but it is compatible. Although not licensed officially so they can't claim to be perfect and there is no warranty that it is indeed compatible with the OpenGL spec, but they are doing their best to do so and it is their only goal?

[bridgman]

It's not that they "can't claim to be perfect", more like they "can't claim to be OpenGL".