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
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).
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.
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.
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?
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?