R600 Open-Source Driver WIth GLSL, OpenGL 2.0

[Zhick]

For 3xx-5xx there was already a Gallium3D driver and developer focus had already shifted to the Gallium3D driver. Since the Gallium3D driver for 3xx-5xx already *had* GLSL and GL2.1 enabled [...]

Are you sure about this?
It's been a few weeks since I tried r300g but iirc it didn't have GLSL/GL2.1 yet. Afaik it's supposedly being implemented by nhaehnle in his r300g-glsl branch, but that has not seen any commits since more than two months so I didn't even bother giving it a try.
But I'll give r300g a try again tomorrow.

[bridgman]

No, I advise you stop feeling put-out because you thought GLSL work was moving much faster on 6xx than it was on 3xx-5xx

GLSL is not ready for general use on either of the open drivers yet, but it is making progress on both.

[bridgman]

Are you sure about this?
It's been a few weeks since I tried r300g but iirc it didn't have GLSL/GL2.1 yet. Afaik it's supposedly being implemented by nhaehnle in his r300g-glsl branch, but that has not seen any commits since more than two months so I didn't even bother giving it a try.
But I'll give r300g a try again tomorrow.

I haven't had a chance to try any of the new code myself, but someone asked about the status on #radeon a week or so ago and eosie replied that GLSL and GL 2.1 were already enabled :

http://people.freedesktop.org/~cbril...ate=2009-11-21

Note that "enabled" is a bit arbitrary, in the sense that you can report lots of functionality without implementing it, you're just "raising the bug count". Michael's article said that Richard had enabled the reporting of GLSL and GL 2.0 in the 6xx-7xx driver; it's important to understand that the 300g driver has *already* reached that point.

I believe the r600 shader compiler is further ahead than the r300g compiler with respect to the instructions required for "full" GLSL, but it appears that a lot of apps require GLSL but then use essentially the same functions supported by arb_vp and arb_fp. Mesa compiles GLSL and ARB_*P down to the same IL and only passes IL to the driver, so having GLSL enabled and starting to test apps is useful without waiting for all of the new IL functions to be implemented.

The following snippet is a pretty good summary of r300g status :

02:33 #radeon: < EruditeHermit> eosie, does it report GL2.0 yet?
02:33 #radeon: < eosie> EruditeHermit: yes, except NPOTs
02:34 #radeon: < EruditeHermit> so glxinfo reports 2.0?
02:34 #radeon: < eosie> 2.1 actually
02:34 #radeon: < EruditeHermit> nice
02:34 #radeon: < EruditeHermit> so what doesn't work then?
02:34 #radeon: < eosie> lots of things

With respect to GLSL and GL2.x, that's pretty much the same as 6xx-7xx. Neither is ready for general use but both have progressed to the point where it's worth enabling these features so that app testing can begin. Most of the testing so far has been on unit tests rather than full-blown applications.

My understanding was that Nicolai was adding the missing Mesa IL instructions which would be required to *fully* implement GLSL on 3xx-5xx, which is (slightly) orthogonal to enabling GLSL itself for all of the IL functions which are already implemented.

Anyways, the key point here is that r300g and r600 are following different paths to the same goal, so they are not going to pass milestones in exactly the same order.

[madman2k]

thanks for the info bridgman. I just updated to r300g, so I can have GLSL, which I need as a programmer.
My experience so far: compiz works, World Of Goo works, Qt GLSL demo works. Openarena 15fps, chromium-bsu crashes, insane CPU usage. But it fits my needs
Will maybe buy an Evergreen GPU, once I figured out what I can use it for

[monraaf]

I believe the r600 shader compiler is further ahead than the r300g compiler with respect to the instructions required for "full" GLSL, but it appears that a lot of apps require GLSL but then use essentially the same functions supported by arb_vp and arb_fp.

Wine claims that it needs GLSL to implement some of DirectX shaders opcodes. I don't know exactly which ones though, but I think they are already implemented. But yet Half-Life 2 -> ARB vp/fp sort of works in DirectX 8 mode, but Half-Life 2 -> GLSL doesn't.


http://wiki.winehq.org/DirectX-Shaders

[Louise]

It is fun to think a year back, when all the talk was about getting the infrastructure right (staging and such) and get the specs out.

Now we see a new feature every month.

[Louise]

AFAIK the VMWare folks are primarily working on (a) the Gallium3D driver for their emulated SVGA hardware, and (b) the non-driver portions of the Gallium3D framework (ie Mesa, Xorg, GL, VG, CL etc... state trackers along with refining the internal APIs).

Corbin (MostAwesomeDude) mentioned that he was starting on a Gallium3D driver for 6xx-8xx but that's all I have heard. Richard is looking forward to working on Gallium3D as well; best guess is that will happen after (a) some testing / fixing on 6xx-7xx GLSL, and (b) getting inital 3D engine support working on Evergreen.

So VMware is taking a gamble that it will get done when they are ready

[Wielkie G]

I hope that the work done with r600 GLSL will be used in future r600g Gallium driver. As far as I know current Gallium drivers use a lot of features (files) from classic mesa drivers. Am I right? If so, does it mean that with correct r300g and r600 drivers it will be far simplier to create r600g driver?
I hope it's true I've been a programmer for several years, but I've never worked on such a large code-base. If I knew what to do I would help with this probably

And most important: Good Work!

[iznogood]

Recently i installed ubuntu on an old amilo laptop with an r300 chip. I was impressed. Everything looked much more "integrated", from the initial modesetting, to compiz, even some small things like window resizing which was pretty smooth (unlike nvidia). So i would really like to move my hardware to ATI as soon as possible (from nvidia), possibly with an r700-r800 chipset, but before i do that i would really like someone to explain when we can expect to have most of the missing pieces completed. From what i read it is not only a driver issue but a lot of other things that need work on the rest of the stack.

Maybe someone to clarify what these things are (and with a timeframe please ?)

[deanjo]

thats probably, why it says "mostly"...
most of the work is done, but it still doesn't do anything
but i did see some nice furmark screenshots.

Just a note,but it is probably not a great idea to run Furmark in wine on a ATI 4850/4870 card where the drivers do not have VRM protection like they do in the windows drivers. Without that protection present, furmark has been proven to kill those cards.