Ray r;
vec4 result = vec4(0.0,0.0,0.0,0);
for (int i = 0; i < 10; i++)
{
for (int j = 0; j < 10; j++)
{
r.o = fragPosition;
//calc the direction of ray as function of i and j...
r.d = ...calc...
r = traceThroughLensStack(r);
// Trace ray from surface of outer lens into scene
vec4 col = traceIntoScene(r);
// If the ray makes it through the lens system,
// add some contribution to this fragment
result = result + r.d;
}
}
Fragment Shader problems
Author
I'm working on a project which involves implementing a simple raytracer in a fragment shader. If I am just casting 1 ray per fragment things are great. When I start trying to uniformly sample an area though, I have problems.
Basically, for each fragment I'm trying to uniformly sample the surface of a lens with 100 rays. The code looks roughly like this...
This seems simple... I cast a hundred rays, but I reuse tons of variables. GLSL doesn't like this though, and it complains about using "too many temporaries"... and that's after quite a while of working at it, assuming it doesn't lock up my machine entirely. Does anyone know why it does this? Is is possible at all to avoid this? This works fine if I remove the for-loops and use only one ray.
(Unfortunately, the $60 OpenGL shading language book doesn't seem to address the ramifications of loops, or lots of other things, and focuses instead on basic syntax, and examples that can be found in a zillion places already.)
try removing your vec4 declaration from the loop and declaring at the top? prolly won't make much difference
Author
Welll, that vec4 actually is needed to accumluate the radiant power reaching the fragment for each pass. Its a situation like...
result += traceRay(r)
...so it shouldn't matter too much. I thinking that the compiler "unrolled" the entire program for each iteration, and created new variables for the entire program for each pass. If that's the case, I'm somewhat annoyed.
result += traceRay(r)
...so it shouldn't matter too much. I thinking that the compiler "unrolled" the entire program for each iteration, and created new variables for the entire program for each pass. If that's the case, I'm somewhat annoyed.
that does seem rather bizzare, maybe you should look into writing this shader in ASM? it will give you more control over when and where variables are created, it does seems rather slack if the compiler created a ton of variables when it unrolled the loop.
Which hardware are you targeting, and which version of the drivers?
Unless you're targeting SM 3.0 hardware (Radeon X1600+, NVIDIA 6600+), long fragment shader loops won't work.
I would still declare 'col' at the top -- not to mention, you don't actually do anything with it in the code you've posted :-)
Unless you're targeting SM 3.0 hardware (Radeon X1600+, NVIDIA 6600+), long fragment shader loops won't work.
I would still declare 'col' at the top -- not to mention, you don't actually do anything with it in the code you've posted :-)
Author
hplus, the code I posted was simply something to reference to get the gist of it. That said, the example should read "result += col;", and you're right, I could try to stick that outside of the loop.
That hardware I'm developing this on is GeForce 6600GT. I was planning on giving it a run on a 7800 at work, though. I wish I had time to do it in ASM, but it is a fairly long program, and I don't really know the asm well enough to do it in the time available.
So, am I correct then in thinking that it *shouldn't* use any more temp registers than running the loop once? I'm also going to try to run it on an ATI card at work, so I'll see if that makes a difference.
Thanks for the input guys.
That hardware I'm developing this on is GeForce 6600GT. I was planning on giving it a run on a 7800 at work, though. I wish I had time to do it in ASM, but it is a fairly long program, and I don't really know the asm well enough to do it in the time available.
So, am I correct then in thinking that it *shouldn't* use any more temp registers than running the loop once? I'm also going to try to run it on an ATI card at work, so I'll see if that makes a difference.
Thanks for the input guys.
the shader compilers are pretty good optimizing compilers, i can't see why it would do something retarded like create tons of copies of the same variables
Author
Well, I'm able to do up to 4 loops. Any more than that and it craps out on me.
I have a new problem now, though. I added one new small function, and now the compiler tells me that there is an error, "Too many instructions".
I was led to believe that there was virtually no limit on program length in pixel shader model 3.0. Is this wrong and is GF6600GT not sufficient for that?
I have a new problem now, though. I added one new small function, and now the compiler tells me that there is an error, "Too many instructions".
I was led to believe that there was virtually no limit on program length in pixel shader model 3.0. Is this wrong and is GF6600GT not sufficient for that?
"With Pixel Shader 3.0 that instruction count has been increased to 65,535 and in the GeForce 6800Ultra the instruction count is unlimited."
Author
Hmmm... well it seems to complain about "too many instructions" at only several thousand. It must be unrolling the loop (which I thought new models would NOT do) and it must be using an older profile.
Is there a way to tell GLSL to compile to the most current shader version?
Is there a way to tell GLSL to compile to the most current shader version?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
