Jump to content
  • Advertisement
Sign in to follow this  
Skiller

OpenGL Early stencil culling/Early ZCulling

This topic is 4095 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 deferred renderer and want to try out early culling using a stencil test in the lighting pass but I've been reading that some cards don't do a stencil test till after the fragment program runs eliminating most of the potential speed increase. Can anyone tell me which series of cards do support an early stencil test? Also is there an OpenGL extension I need to use to enable it or is it automatic? Thanks [Edited by - Skiller on September 18, 2007 8:10:42 PM]

Share this post


Link to post
Share on other sites
Advertisement

I believe that on most ATI chips, depth, scissor, and stencil testing all happen at the same time. This could be before or after the shader, depending on what the shader does ( texkill instructions and depth output can cause it to happen after the shader ).

Share this post


Link to post
Share on other sites
Quote:
Original post by jbarcz1

I believe that on most ATI chips, depth, scissor, and stencil testing all happen at the same time. This could be before or after the shader, depending on what the shader does ( texkill instructions and depth output can cause it to happen after the shader ).


Fortunately the shaders that will run with the test wont be changing anything like stencil or depth so they should be able to take advantage of the early cull if it's available :)

Share this post


Link to post
Share on other sites
on NVIDIA hardware you can utilize stencil culling. This is located close to the rasterizer, while the test is located after the pixel shader.

Share this post


Link to post
Share on other sites
Quote:
Original post by wolf
on NVIDIA hardware you can utilize stencil culling. This is located close to the rasterizer, while the test is located after the pixel shader.


So there's no early stencil test to prevent the pixel shader running on that pixel?

Share this post


Link to post
Share on other sites
on ATI hardware it is on NVIDIA hardware it is not ... but stencil culling is quite cool so :-)

Share this post


Link to post
Share on other sites
Looks like I'll need to create a tempory Z-Buffer and fill that in so it performs an early z cull instead :(. Any idea of what the best way to do that would be? I'm thinking a pixel shader that alters the depths might cost more than any speed gain as it would need to be 2 passes over the whole area of the light, is there a more efficient way to write specific values to the Z-Buffer?

Share this post


Link to post
Share on other sites
Why don't you just directly shade while rendering the light volumes (using vpos)? Saves the stencil hassle (I never did get it to work quite properly, i.e. a speed gain on either vendor's hardware) and should have pretty much the same effect, assuming that's what you're doing.

If you do decide to go down the early-stencil route, I've heard that renaming your app to "Doom3.exe" may help ;) Seriously though, it is a case of "exactly what Doom3 does will probably be accelerated well, but otherwise it's up in the air".

Share this post


Link to post
Share on other sites
Quote:
Original post by AndyTX
Why don't you just directly shade while rendering the light volumes (using vpos)? Saves the stencil hassle (I never did get it to work quite properly, i.e. a speed gain on either vendor's hardware) and should have pretty much the same effect, assuming that's what you're doing.

If you do decide to go down the early-stencil route, I've heard that renaming your app to "Doom3.exe" may help ;) Seriously though, it is a case of "exactly what Doom3 does will probably be accelerated well, but otherwise it's up in the air".


Directly shade while rendering the light volumes? What exactly do you mean?

It won't be like Doom3 as I'm trying to do the cull for the lighting pass not the geometry pass. I'm trying to use volumes representing the lights to determine the exact pixels to run the light shader on as usually it's only needed on 10%-50% of the pixels the light area covers (theoretical 2-10 times speed increase, ingoring time to set up the cull). I'd thaught about doing another early Z pass for the geometry but since I'm making a top down action rpg (diablo style) the overdraw in the geometry pass is minimal anyway and it would probably slow things down more than speed them up.

Share this post


Link to post
Share on other sites
Quote:
Original post by Skiller
Quote:
Original post by AndyTX
Why don't you just directly shade while rendering the light volumes (using vpos)? Saves the stencil hassle (I never did get it to work quite properly, i.e. a speed gain on either vendor's hardware) and should have pretty much the same effect, assuming that's what you're doing.

If you do decide to go down the early-stencil route, I've heard that renaming your app to "Doom3.exe" may help ;) Seriously though, it is a case of "exactly what Doom3 does will probably be accelerated well, but otherwise it's up in the air".


Directly shade while rendering the light volumes? What exactly do you mean?


I won't presume to speak for AndyTX, but I believe he's advising evaluating the illumination function while the light volume is being rendered--since your fragment program will only be run for the relevant (to your view) fragments anyway. You can easily compute the correct G-Buffer coordinates from the clip-space light volume vertices.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!