New GLSL demo

[Humus]

This demo does portal rendering through occlusion queries. It helps bump the rendering speed by culling invisible parts of the scene.

This demo uses GLSL for its lighting, so you'll need the new Cat 3.10 drivers.

Demo here:
http://esprit.campus.luth.se/~humus/

Drivers here:
http://www.ati.com/home/online/CatalystXPdriver.html

 

[Ante P]

Very nice work my fellow Swede.

Ahh, didn't realize there were many rooms at first.

 

[vrecan]

awsome humus!!!@

 

[nobie]

nice!

 

[Brent]

pretty sweet Humus!

 

[jvd]

can someone bring me up on glsl


Btw its very nice and runs well on the 9500pro , 9600pro , 9700 pro and a 9800xt

 

[akira888]

can someone bring me up on glsl

Tersely put OpenGL Shading Language (or GLSLang) is the OGL equivalent of the DirectX HLSL. While the functionality is more or less the same there are some key differences. First, the API lacks hard caps on resources (instruction slots, free writable registers, and constants). IMO Good and Bad. Secondly, it compiles on your machine not from a pseudo-asm but from the high level code! This should allow for much better hardware-specific optimization* in theory although it will be more challenging for the IHV compiler authors. There are some minor syntactical differences (float3 for a 3 component floating point vector is now vec3 - go figure).

In short there are some differences although due to the fact they are (to me it looks like this at least) both based on the 80's-era Renderman scene description language they are mostly similiar.

* By optimization I mean real optimization.

Btw its very nice and runs well on the 9500pro , 9600pro , 9700 pro and a 9800xt

You're several years younger than me yet you always have better crap. But it's my fault for entering grad school I guess.

 

[bloodbob]

Nice work humus the first GLSLANG demo I've seen.

Have you tried the noise functions yet? on my R300 I get 0 fps if its in a fragment shader and vertex shaders fail to compile :/.

Oh better yet no loops lol.

Does anyone know if F-buffer works if I had a R350 I would test but yeah R300 just hangs if there are to many fragment ops.

 

[MazyNoc]

I havent checked the noice in the 3.10 driver yet, but i tried it in the 3.9hotfix, and for fragmentshaders that works, but in software emulation mode..
http://mazy.annat.nu/images/hlsl.jpg

 

[Rambler]

Looks cool as usually, but Humus, are you sure the occlusion culling is working? In first room i get 42fps(~22 in the "flame"), but once i move from 1st room, i get constant 21 fps everywhere.
Also i didn't notice any difference when toggling the occlusion queries in menu.
Cat 3.10, 12x10, r9800, p4 2.4GHz

Edit: erm, yes there is a difference, but still there's the fps drop when leaving 1st room.

 

[Humus]

* By optimization I mean real optimization.

You know the world order is really screwed up when you have to explain what optimisations means in the current context.
&

 

[Humus]

Have you tried the noise functions yet? on my R300 I get 0 fps if its in a fragment shader and vertex shaders fail to compile :/.

Oh better yet no loops lol.

Haven't tried noise yet. Most certainly not going to be supported ever in hardware on this generation. Static loops probably will however, but not yet. That's one of the big TODOs for the driver. Otherwise, I'm very pleased with the quality.

 

[Humus]

Looks cool as usually, but Humus, are you sure the occlusion culling is working? In first room i get 42fps(~22 in the "flame"), but once i move from 1st room, i get constant 21 fps everywhere.
Also i didn't notice any difference when toggling the occlusion queries in menu.
Cat 3.10, 12x10, r9800, p4 2.4GHz

Edit: erm, yes there is a difference, but still there's the fps drop when leaving 1st room.

Yup, it's most certainly working. First room, 100fps enabled, 69fps disabled. The drop in fps is when the second room becomes visible, so that it needs to draw two rooms. If you're running in very high resolution, 1600x1200 or so, which I suspect you do given your fps, then the performance difference is smaller since the particle system overhead and state changes becomes less important. Using portals have the other good property that it more or less automatically does a coarse front-to-back sort since the room you're into is drawn first and then recursively to the closest rooms. So that helps hierarchical-Z quite a bit, so that even when occlusion culling is disabled the hierarchical-Z can quickly cull a lot too.

 

[nelg]

Does this mean that you had the Cat 3.10's before everyone else?

 

[Humus]

Sort of. Not sure if the driver I had was the exact same as Cat 3.10, but yes I had a beta GLSL driver. I'm glad the GLSL support has gone public now, both because now I have practical use for it (demos I can release), and because I can finally disprove all the nay-sayers expecting GLSL to take eternal time to complete. It's painful to know you're right, but can't prove it due to NDA.

 

[Simon F]

because I can finally disprove all the nay-sayers expecting GLSL to take eternal time to complete.

Did you, by chance, have anyone in particular in mind?

 

[rwolf]

Say Humus, you should put your different demos together into a benchmark.

I can see it now "Humusmark 2004".

 

[Rodéric]

I could do it too if I had a card supporting GLSlang

I'm just a jealous guy, oooh yeah...
-John Lennon, "Jealous Guy"

 

[Humus]

Say Humus, you should put your different demos together into a benchmark.

I can see it now "Humusmark 2004".

I'll get around to add benchmark mode in the new framework too, likely at some point during the holidays.

 

[bloodbob]

Have you tried the noise functions yet? on my R300 I get 0 fps if its in a fragment shader and vertex shaders fail to compile :/.

Oh better yet no loops lol.

Haven't tried noise yet. Most certainly not going to be supported ever in hardware on this generation. Static loops probably will however, but not yet. That's one of the big TODOs for the driver. Otherwise, I'm very pleased with the quality.

No noise no GLSLANG support as it is a required compoment even if it is hell slow but noise isn't going to be a major factor for a little while so its a moot point. Noise implementation can vary the requires are some what subjective as they don't use any values other than average ( ignoring range ). The older GLSLANG documents effectively said that implementation should really really be a perlin noise unless you got something else just as good.

I still think static loops should have been introduced before ati started saying they actually supported GLSLANG :/

Two questions remain in my mind about the new GLSlang support.

1. As asked before can anyone tell me if it actually support F-Buffer?
2. How does the preformance compare M$ HLSL considering that the optimisation can be done at the source language rather then the byte code?