Static for loops on Cat 4.7 don't work?

I’m trying to compute the lighting in a vertex shader.

//More or less the code I have
void ComputeLighting(int lightNumber)
{
....
//Using gl_LightSource[lightNumber]
//
}

void main()
{
int i;
for(i=0; i<3; i++)
{
ComputeLighting(i);
}
}

The problem is, it runs in software. Ah fudge!
The second problem is, the software implementation has undefined behavior. Sometimes it works, sometimes nothing renders, sometimes it’s all black.
The third problem is, I need loops else it will exceed the instruction limit.
I don’t want to expand the loop manually.

I’m strictly talking about vertex shader!

Anyone had any luck?

I would guess that it runs in software because it exceeds the instruction limit. I don’t know if our compiler support real loops in the vertex shader yet. It seems that it just expands the constant loop and thus causes it to overflow the instruction count.

I did expand myself which run in hardware.

Actually, this may not be a for loop problem cause if I do the following code, it runs in software.

 

void ComputeLighting(int lightNumber)
{
....
//Using gl_LightSource[lightNumber]
//
}

void main()
{
int i;
ComputeLighting(i);
}
 

Just indexing gl_LightSource with a immediate number works in hardware.

I will try indexing my own uniform and see if that works later.

Loops in Catalyst 4.7 doesnt seem to work for me either. I am using the latest version of Shader Designer (v. 1.5.5, just released and downloaded today). Does anybody have any answers to this problem?
In case u were wondering i am doing my own version of a real time 2/3/4d perlin shader (just to get used to GLSL). all of the algorithms r complete but it cant run on hardware. :confused:

Any help would be greatly appreciated :slight_smile:

Loops are supported and works fine for me. But it depends on how you’re using it. Static loops are supported and work well as long as it doesn’t exceed the instruction count limit.

What kind of loops are you using?

This is a vertex shader; any and all kinds of loops should work for R300 or greater hardware.

Well, any loop that can map to the static branching hardware should run. We can’t support loops that depends on dynamic data though, but this seems not to be the case here.

In any case, if you guys have any sample code with loops that doesn’t work that you think should work on our hardware, feel free to send it to me at epersson (at) ati.com and I’ll take a look at it.

To confirm, yes, I think static loops are expanded both on vs and fs.

If I exceed 256 instructions in vs, which I think is the max native limit on R300, it runs in software.

I will get back about the indexing issue the next day.

PS: for those who wat to try 4.8 and 4.9 non-official drivers at
http://www.station-drivers.com/page/atidriv.htm

For those who are curious, I have been working on this
http://www.geocities.com/vmelkon/glsl_raytracing.html

it’s been kind of though after encountering bug after bug. It would really be nice to have a bugless REF implementation.

More fun stuff, same link!

I will create a runnable version maybe this weekend

Nice. So how advanced rendering can you do with that ray-tracer? Only spheres and planes?

… and we argued about needing some kind of speciallized chip that does hardwired raytracing.

What I have currently only does spheres and planes. I can try something more complex later. It’s possible to use NURBS surfaces to represent “organic” shapes so it should be possible to raytrace say… a teapot.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.