Radeon Driver Picks Up VBOs, OQ Support

[chelobaka]

Good news. Looking forward for test results from Michael.

[madman2k]

also a compliment on the article to michael. afaik its the first time he provided useful links to the technical details

[osiris]

Depends on your viewpoint, I guess. Personally, I consider anything less than OpenGL 2.1 + FBOs a "toy" - we are talking about 6 year old features here!

(Not bashing the open-source drivers here, just saying I'd *really* love GLSL support so I Can finally drop the damned fixed-function codepath from my applications).

R300 cards owners won't benefit (performance wise) from GLSL support actually, because R300 chips don't support loops and branches. While branches can be rewritten, if an app will try to use loops in GLSL programs the driver will just fallback to software. The best the R300 can do is ARB_vertex/fragment_program.

[osiris]

Good news. Looking forward for test results from Michael.

Don't expect much. Only apps that feed GPU with much vertex data will benefit from vbo_clean branch merge, and as for occlusion queries on low end GPUs people may actually see performance drop (because app may have software and hardware OQ backends, and the SW-based one can be faster for slower GPUs - that's the case with sauerbraten game).

[BlackStar]

R300 cards owners won't benefit (performance wise) from GLSL support actually, because R300 chips don't support loops and branches. While branches can be rewritten, if an app will try to use loops in GLSL programs the driver will just fallback to software. The best the R300 can do is ARB_vertex/fragment_program.

Loops are not necessary for a surprising number of algorithms: per-pixel lighting, shadow maps, parallax can all be implemented without loops. These represent a huge jump in quality over fixed function OpenGL, so they are certainly worth it (true, you *could* implement shadow maps and dot3 lighting without on fixed function hardware, but the implementation is not even funny).

Other than that, I refuse to touch ARB_vertex/fragment programs (adding *yet* another codepath to my applications for obsolete hardware? No thanks!) If a GPU doesn't support GLSL I force it down the fixed-function pipeline and forget about it (which includes every Intel GPU currently in existence.)

My point is that across-the-board GLSL support allows you to provide a unified and relatively clean rendering engine. Supporting the fixed function pipeline makes things much, *much* uglier.

Edit: regarding VBOs, they are much easier to handle than client-side vertex arrays for a number of applications (esp. if you are using a GC). They also allow you to use a single codepath for basic geometry uploads, which is always a good thing.

Speed will probably increase as the code matures.

[SavageX]

Just to put things into perspective: Nexuiz heavily uses GLSL, but not a single loop in GLSL.

[pvtcupcakes]

If a GPU doesn't support GLSL I force it down the fixed-function pipeline and forget about it (which includes every Intel GPU currently in existence.)

Intel GPUs don't support GLSL?
I have an X4500HD, and according to glxinfo it has OpenGL 2.1. I don't know a whole lot about OpenGL, but I do know that I am getting hardware acceleration on my Intel chip because it can run Urban Terror.
Is it software based GLSL or something?

[pvtcupcakes]

And another quick question.
When they refer to r300, does that include r400 and r500 like r600 can refer to rv770?

[agd5f]

And another quick question.
When they refer to r300, does that include r400 and r500 like r600 can refer to rv770?

The r300 3D driver supports r3xx, r4xx, and r5xx chips. However, the r5xx hardware supports more advanced shader instructions like loops. So when GLSL support is added, r5xx chips will be able to do more things in hardware than r3xx/r4xx chips.

[marek]

R300 cards owners won't benefit (performance wise) from GLSL support actually, because R300 chips don't support loops and branches. While branches can be rewritten, if an app will try to use loops in GLSL programs the driver will just fallback to software. The best the R300 can do is ARB_vertex/fragment_program.

Not true. Loops with a constant number of iterations can be unrolled and so do branches. Let's have a branch if(c){x=a;}else{x=b;}. This can be rewritten in GLSL as x=a*c+b*!c or simply x=mix(b,a,c). In other words, both code blocks should be evaluated and irrelevant results discarded if branching is not supported. This will still be much faster than software fallback. This is how proprietary drivers work and it's a must.