Jump to content
  • Advertisement
Sign in to follow this  
smitty1276

OpenGL Fragment Shader problems

This topic is 4489 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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...
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;
    }
}    	

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.)

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :-)

Share this post


Link to post
Share on other sites
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.


Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
"With Pixel Shader 3.0 that instruction count has been increased to 65,535 and in the GeForce 6800Ultra the instruction count is unlimited."

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!