ATI R300 Gallium3D DRI Support Is "Done"

[phoronix]

Phoronix: ATI R300 Gallium3D DRI Support Is "Done"

A month ago we shared that the Gallium3D driver for the ATI R300/400/500 graphics cards (up through the Radeon X1000 series) was mostly done. Now today, the key author of the R300 Gallium3D driver, Corbin Simpson, has updated the status wiki to reflect the latest changes...

http://www.phoronix.com/vr.php?view=NzY4Ng

[monraaf]

Congrats, AMD should hire this guy to work full time on the R600 driver.

Now for the questions, sorry for my lack of knowledge on the subject but what exactly is the difference between the DRI and mesa state trackers, and which one is the one we are waiting for to get GLSL support?

And on a side note, I noticed that the tungstengraphics.com domain has expired, whats up with that? There are now a lot of dead links to info on Gallium3D...

[krazy]

Thanks Corbin, MostAwesome! :D

[kersurk]

That is good news.


Though I'm not sure how will it really affect me as end user.

[Louise]

Looking at the Gallium3D features I see:

* mesa
* vega
* exa
* g3dvl
* python
* dri
* xorg
* egl
* wgl

Which deprecates which of the classic?:

* DDX (X server) Modesetting
* Kernel Modesetting
* DRI2
* ShadowFB
* Old 2D Acceleration (XAA)
* 2D Acceleration (EXA)
* Overlay Xv
* Textured Xv
* XvMC
* Primitives
* Textures
* Hardware TCL
* Vertex Shaders
* Fragment (Pixel) Shaders
* GLSL
* OpenGL Compliance (Driver/Hardware)

[smitty3268]

For the most part, I don't think any of that is being deprecated. It's more like Gallium is an architecture-independent layer on top of those existing technologies, rather than having each driver fully implement them from scratch.

(With the exception of DDX modesetting and XAA, which have already been deprecated)

Also, apparently GLSL is completely separate from Gallium3D, unlike what everyone thinks. So you could have a fully complete gallium driver without GLSL support. Or at least that's what I was told.

[MostAwesomeDude]

Congrats, AMD should hire this guy to work full time on the R600 driver.

Now for the questions, sorry for my lack of knowledge on the subject but what exactly is the difference between the DRI and mesa state trackers, and which one is the one we are waiting for to get GLSL support?

And on a side note, I noticed that the tungstengraphics.com domain has expired, whats up with that? There are now a lot of dead links to info on Gallium3D...

The dri test is basically, "does glxinfo report sane numbers?" And it does. The mesa test is piglit, a very exhaustive GL test suite. We're nowhere near passing.

In more layman terms, glxgears works, openarena is getting there, compiz is nearly there, and I haven't really tested much else.

TG's site kind of vanished because VMWare didn't renew it for some reason. Don't worry; all the important info already got migrated to X.org and DRI wikis.

That is good news.


Though I'm not sure how will it really affect me as end user.

That's really up to your distro; I'm not sure which distros will pick up Gallium drivers. i915g has been shipping with Mesa 7.6, but I don't think any distros that carry 7.6 are actually building the Gallium drivers.

Looking at the Gallium3D features I see:

* mesa
* vega
* exa
* g3dvl
* python
* dri
* xorg
* egl
* wgl

Which deprecates which of the classic?:

* DDX (X server) Modesetting
* Kernel Modesetting
* DRI2
* ShadowFB
* Old 2D Acceleration (XAA)
* 2D Acceleration (EXA)
* Overlay Xv
* Textured Xv
* XvMC
* Primitives
* Textures
* Hardware TCL
* Vertex Shaders
* Fragment (Pixel) Shaders
* GLSL
* OpenGL Compliance (Driver/Hardware)

KMS is required for Gallium. xorg + exa can replace a DDX and provide Xv. dri + mesa can provide a GL driver, which does all of the regular GL features including GLSL.

That list looks suspiciously like RadeonFeature from X.org's wiki. :3 I intentionally didn't add very many features to that list, because at the end of the day, what people use Gallium drivers for is very independent of what a traditional DDX does. You could say that KMS + Gallium can replace a classic DRM + DRI + DDX stack, but that's only one possibility. Other things, like Wayland + EGL + Cairo, are also possible.

[Louise]

KMS is required for Gallium. xorg + exa can replace a DDX and provide Xv. dri + mesa can provide a GL driver, which does all of the regular GL features including GLSL.


So they replace each other in groups?


Gallium Classic MESA
------------------------
xorg+exa DDX+Xv
dri+mesa GL+GLSL
dri DRI2 (???)


What about vega, g3dvl, egl, wgl? Do they have equivalent classic mesa counter parts?


That list looks suspiciously like RadeonFeature from X.org's wiki. :3

:D


I intentionally didn't add very many features to that list, because at the end of the day, what people use Gallium drivers for is very independent of what a traditional DDX does. You could say that KMS + Gallium can replace a classic DRM + DRI + DDX stack, but that's only one possibility. Other things, like Wayland + EGL + Cairo, are also possible.

Cool. Are there other possible combinations?

What does vega, g3dvl, egl, wgl stand for?

[Xheyther]

And also what does the python state tracker means ?

[fiete]

The dri test is basically, "does glxinfo report sane numbers?" And it does. The mesa test is piglit, a very exhaustive GL test suite. We're nowhere near passing.

In more layman terms, glxgears works, openarena is getting there, compiz is nearly there, and I haven't really tested much else.


I am confused. To my understanding there is no OpenGL (except OpenGL ES) state tracker yet. How is it possible to run glxgears, openarena and compiz then?

[Pfanne]

this sound great!
good job corbin!

[pedrodh]

What does this driver bring of new that the opensource one present now, let's say, in Ubuntu 9.10 doesn't have? I can't fully understand what is this Gallium driver, I've never used it on my system, but this interests me since I've a laptop with an ATI X600.

I've visited wikipedia, but that didn't help much, I hope you guys can explain it to a noob like me :P

[panda84]

I am confused. To my understanding there is no OpenGL (except OpenGL ES) state tracker yet. How is it possible to run glxgears, openarena and compiz then?

I think the OpenGL 3.x is still missing, but the fixed function OpenGL should be in place:
http://wiki.freedesktop.org/wiki/Software/gallium
Traditional fixed-function OpenGL components (such as lighting and texture combining) are implemented with shaders. OpenGL commands such as glDrawPixels are translated into textured quadrilateral rendering. Basically, any rendering operation that isn't directly supported by modern graphics hardware is translated into a hardware-friendly form.

Future state trackers will be created for OpenGL 3.0 and OpenGL-ES 2.x.

[panda84]

What does this driver bring of new that the opensource one present now, let's say, in Ubuntu 9.10 doesn't have? I can't fully understand what is this Gallium driver, I've never used it on my system, but this interests me since I've a laptop with an ATI X600.

I've visited wikipedia, but that didn't help much, I hope you guys can explain it to a noob like me :P

From a user point of view Gallium is pretty useless at the moment, it still needs time (1 year or more) to mature.
Long term advantages are:

better performances (the architecture is similar to modern proprietary graphic drivers)
once you implement the core driver you automatically have support for a lot of tecnologies (OpenGL, EXA, and maybe in the future video acceleration)

These are things that cannot be achieved rapidly by the current driver architecture.

[Louise]

And also what does the python state tracker means ?

I am guessing here, but I would think it is a python binding, so you can access OpenGL from Python.

This I do know, that the plan is to make a Python binding to OpenCL, so you can off load calculations to the GPU from Python instead of only C and C++.

[Xheyther]

As a pythoner I think it would be wonderfull !!

Thank anyway.

[BlackStar]

I am guessing here, but I would think it is a python binding, so you can access OpenGL from Python.

This I do know, that the plan is to make a Python binding to OpenCL, so you can off load calculations to the GPU from Python instead of only C and C++.

Python already has bindings to OpenCL, as does Mono/.Net, Java and several other languages. Google is your friend!

[V!NCENT]

Google is your friend!
That is, if you know what to search for...

[Louise]

Python already has bindings to OpenCL, as does Mono/.Net, Java and several other languages. Google is your friend!

I didn't knew that was already implemented in the closed source version.

But you definitely can't do that in the open source version =)

[pingufunkybeat]

Let me see if I get this correctly...

Once the r300-specific driver is written (which is essentially finished now), it can plug into all the other hardware-independent modules of Galium and make use of them?

Am I understanding correctly that the remaining Mesa/OpenGL-related work is not dependent on the r300g driver, but is done once for all the drivers? So we are waiting for the same thing that all the other drivers are waiting for?

[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 :D

[V!NCENT]

I think strictly speaking it is a FLOSS implementation of an API similar to OpenGL :D
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".

[pingufunkybeat]

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?
They are an implementation of OpenGL, but they are not allowed to say that :)

[Louise]

They are an implementation of OpenGL, but they are not allowed to say that :)

MESA is almost but not quite unlike OpenGL :D

[piete]

Hi! I'm also an end user that would just like his HP NC8430 laptop with ATI Radeon Mobility X1600 running cool and quiet. That's why I have decided to stick with Debian Lenny whose fglrx still supports my card and keeps the fan at the same running level (55%) as Windows XP. Newer distributions with new radeon drivers can get the fan only at their best at 70% (with correspondingly higher temperatures) and my unfortunate adventure with Fedora 11's KMS kept the fan running at 80% (noticeably loud).

If I only could flash the bios and set the default power state (core/memory clocks plus supposedly something else) I wouldn't have these problems, but ATI (or HP) in its all wisdom decided that the "medium" power state is a good compromise (that it is not in my opinion for a laptop that is supposed to run cool and consume little power). And searching for bios flashing guides made it seem that no-one has ever flashed their Mobility X1600 (I didn't find any evidence if it's even possible, at least not with the "standard" flashing tools but I would guess HP's bios updates also used to update the video bios).

Since I found Phoronix I guess I'll just keep coming back to see when the power management (probably in kernel) is implemented well enough to make the move to open drivers worthwhile. Until then I'm (practically forced to be) happy with my stable and cool Lenny (having low bandwidth makes constant updating of distributions like Arch also tiresome so this decision was anyway the right after having played with the likes of Arch Linux and sidux).

Sorry if this message is too much off topic but I just wanted to share this with you (again).

[WhiteRabbit]

Hi! I'm also an end user that would just like his HP NC8430 laptop with ATI Radeon Mobility X1600 running cool and quiet. That's why I have decided to stick with Debian Lenny whose fglrx still supports my card and keeps the fan at the same running level (55%) as Windows XP. Newer distributions with new radeon drivers can get the fan only at their best at 70% (with correspondingly higher temperatures) and my unfortunate adventure with Fedora 11's KMS kept the fan running at 80% (noticeably loud).

If I only could flash the bios and set the default power state (core/memory clocks plus supposedly something else) I wouldn't have these problems, but ATI (or HP) in its all wisdom decided that the "medium" power state is a good compromise (that it is not in my opinion for a laptop that is supposed to run cool and consume little power). And searching for bios flashing guides made it seem that no-one has ever flashed their Mobility X1600 (I didn't find any evidence if it's even possible, at least not with the "standard" flashing tools but I would guess HP's bios updates also used to update the video bios).

Since I found Phoronix I guess I'll just keep coming back to see when the power management (probably in kernel) is implemented well enough to make the move to open drivers worthwhile. Until then I'm (practically forced to be) happy with my stable and cool Lenny (having low bandwidth makes constant updating of distributions like Arch also tiresome so this decision was anyway the right after having played with the likes of Arch Linux and sidux).

Sorry if this message is too much off topic but I just wanted to share this with you (again).

Google the site techpowerup! If you have a windows disk or windows dual boot that site has all the info and programs you need to change the fan/core clock/mem clock/ just about anything and then flash the bios... then again this is all windows based... so you need windows to do it... or maybe somebody *hint hint* could program some thing of the like for linux

[nanonyme]

Google the site techpowerup! If you have a windows disk or windows dual boot that site has all the info and programs you need to change the fan/core clock/mem clock/ just about anything and then flash the bios... then again this is all windows based... so you need windows to do it... or maybe somebody *hint hint* could program some thing of the like for linuxUnless I've understood wrong, card BIOS is just for the vendor defaults. Things should improve with KMS power management.

[piete]

Google the site techpowerup! If you have a windows disk or windows dual boot that site has all the info and programs you need to change the fan/core clock/mem clock/ just about anything and then flash the bios... then again this is all windows based... so you need windows to do it... or maybe somebody *hint hint* could program some thing of the like for linux

I did read Techpowerup's guide to bios flashing and Radeon Bios Editor manuals, among other things. RBE doesn't work with my card so while the guides were interesting read, I haven't been able to put them in practice. But the last time I checked was in May, when I have time, I'll have another look.

Nanonyme, I didn't understand what you meant with vendor defaults. Couldn't they be changed? I would be more than happy if the default core/memory frequencies were the lowest possible, then I wouldn't need KMS power management (though I'm sure it is good to have when it's ready to increase performance when needed). Anyway, KMS would still be just for linux. When I want to play with FreeDOS, for example, or just use anything that defaults to "no power management" like fresh windows installation, the computer gets really hot until I install the ATI drivers.

[agd5f]

Flashing your video bios is a bad idea for a number of reasons. The video bios stores information specific to that particular card. Things like:
- connector tables (what connectors does your card have an how are they wired up)
- laptop panel mode timings
- board specific memory setup (not all oems use the same type, brand and speed vram; different vram chips require different setup)
- board specific power management information (max supported clocks, safe temperature ranges, board-specific thermal and fan control chip information)
- board specific voltage settings
- board specific asic init routines
- reference clocks and pll limits

The drivers use the information in the video bios information to set up the board dependent parts of the chip. You can see the potential problems with using the wrong bios.

[BlackStar]

Flashing your video bios is a bad idea for a number of reasons. The video bios stores information specific to that particular card. Things like:
- connector tables (what connectors does your card have an how are they wired up)
- laptop panel mode timings
- board specific memory setup (not all oems use the same type, brand and speed vram; different vram chips require different setup)
- board specific power management information (max supported clocks, safe temperature ranges, board-specific thermal and fan control chip information)
- board specific voltage settings
- board specific asic init routines
- reference clocks and pll limits

The drivers use the information in the video bios information to set up the board dependent parts of the chip. You can see the potential problems with using the wrong bios.

That's why you backup and edit your own bios directly (instead of flashing a third party download).

Of course, there's a real possibility that you'll screw up and brick your system and that's not fun. At least on a desktop you can boot with a PCI card and restore a backup. On a laptop you'll have to do this blind (and pray that it works).

Moreover, I'd recommend exploring the capabilities of the GPU *thoroughly* with a modding tool before burning any permanent settings into the bios. Stuff like the lowest stable core/mem speeds for the resolutions you are using (don't forget to test multi-monitor setups, which have much higher requirements!) verified with something like furmark (yes, running furmark on the lowest power state will quickly reveal if you'll have stability problems later on). Also, don't forget to test whether dynamic switching from low->high power states work (and vice versa). Too high a jump in clockspeed will likely cause corruption.

I've successfully modded a X1950Pro and an HD4850 to lower the default clock and fan speed settings. My main concern was fan noise and the bios mod worked wonders for this.

Just note that this can and will brick your system if you are not careful (and sometimes even if you *are* careful), so you'll have to judge for yourself if you are willing to take the risk. If you have any concerns about bricking your system, my advice would be to avoid this. Better safe than sorry!

[piete]

That's why you backup and edit your own bios directly (instead of flashing a third party download).


I've successfully modded a X1950Pro and an HD4850 to lower the default clock and fan speed settings. My main concern was fan noise and the bios mod worked wonders for this.



Hi BlackStar! That's exactly what I want to do with my X1600 Mobility! What tools did you use? All the tools I have found say that they can't edit my card's bios.

I'm fully aware of agd5f's concerns but I'm willing to take the risk, after all, my card has 3 official power states and all I want is to have PS1 as default (instead of PS2).

[zhark]

In Windows I have used http://www.techpowerup.com/rbe/, you need gpu-z for reading bios and winflash (or other) to flash modified bios to card. Read documentation. At your own risk.

[Nille]

In Windows I have used http://www.techpowerup.com/rbe/, you need gpu-z for reading bios and winflash (or other) to flash modified bios to card. Read documentation. At your own risk.

With atiwinflash i have killed 2 times my bios :/ but with atiflash ( the DOS/FreeDOS tool ) it work like a charm.

[BlackStar]

Hi BlackStar! That's exactly what I want to do with my X1600 Mobility! What tools did you use? All the tools I have found say that they can't edit my card's bios.

I'm fully aware of agd5f's concerns but I'm willing to take the risk, after all, my card has 3 official power states and all I want is to have PS1 as default (instead of PS2).

Just a word of warning, modifying the bios of a mobile card is more risky than what I did. If something goes wrong, you'll have to restore the bios blind (so make sure you make a thorough list of steps and keyboard commands that restore the original bios *before* you try anything risky).

What I did was create a freedos bootdisk (I used an old 128MB usb stick I had lying around). On the stick, I loaded a dos program that can backup/flash the bios of your graphics card (unfortunately, I don't recall the name - but it's pretty well known).

Once I had the usb stick working, I booted from it and backed up my bios.

I then booted to windows (used a VM running in VirtualBox, actually) and used RBE (Radeon Bios Editor) to modify my bios settings. What I did was lower the clocks of the idle power state - you may have to modify the clocks for the second power state instead.

Finally, I saved my modified bios to the usb stick, booted from it and flashed my card.

My advice is to take your time and make sure you know the capabilities of your card before flashing them permanently. Test thoroughly first (if necessary, install windows and use an over-/underclocking tool like ati tray tools to discover the limits of your card). M oreover, don't use the absolute limits for your card but rather try to leave some headroom (I clocked my HD4850 100MHz higher than the absolute lowest core clock, for example).

That's it more or less. Disclaimer: there is a very real chance that this process will brick your computer, without any way to recover. If you cannot afford to buy a new laptop, don't do this. That's all :)

[piete]

Just a word of warning, modifying the bios of a mobile card is more risky than what I did. If something goes wrong, you'll have to restore the bios blind (so make sure you make a thorough list of steps and keyboard commands that restore the original bios *before* you try anything risky).

What I did was create a freedos bootdisk (I used an old 128MB usb stick I had lying around). On the stick, I loaded a dos program that can backup/flash the bios of your graphics card (unfortunately, I don't recall the name - but it's pretty well known).

Once I had the usb stick working, I booted from it and backed up my bios.

I then booted to windows (used a VM running in VirtualBox, actually) and used RBE (Radeon Bios Editor) to modify my bios settings. What I did was lower the clocks of the idle power state - you may have to modify the clocks for the second power state instead.

Finally, I saved my modified bios to the usb stick, booted from it and flashed my card.

My advice is to take your time and make sure you know the capabilities of your card before flashing them permanently. Test thoroughly first (if necessary, install windows and use an over-/underclocking tool like ati tray tools to discover the limits of your card). M oreover, don't use the absolute limits for your card but rather try to leave some headroom (I clocked my HD4850 100MHz higher than the absolute lowest core clock, for example).

That's it more or less. Disclaimer: there is a very real chance that this process will brick your computer, without any way to recover. If you cannot afford to buy a new laptop, don't do this. That's all :)

Bumping a bit old thread but I was travelling and hope that the knowledgeable people have subscribed the thread...

1. RBE cannot read Mobility X1600's bios (it says this particular card's bios reading is not supported)

2. I'm stuck before I find another utility that can since although I have two laptops I'm not that crazy that I would edit the bios blindly

3. I'd like to know if there is someone who has already done this with the exact same card (since already X1950Pro seems to be a different story...)

4. I do have a multiboot with Windows XP (which is still my main OS but I'm moving on to Debian Lenny whose fglrx has a working power management for my card, I just need to get some studying stuff done before having more time to install the programs I need) so I could use all tools regardless the OS they work with

5. I can't be the only X1600 owner wanting to do this! ;)