Can the depth test be moved up the pipeline, before the textures are applied? Since the depth test is related to the geometry its unnecessary to do the texture application if a fragment is going to fail. What prevents this?
I think it will be nice if instead of killing a fragment when it doesnt pass a test it is rendered into a different buffer( a secondary buffer). If we want to kill the fragment then we can set the secodary buffer as 0 or something to that effect.
This way we need not pass the whole geometry twice for some effects.
Is switching buffers for rendering on a per fragment basis costly?
Performing Z testing prior to texturing is an optimization most HW vendors perform these days. There are challenges where transparency comes into the mix. I think you can imagine the cases. As for switching buffers on a fragment basis, that is probably not feasible with the complicated memory caching schemes in use today.
Originally posted by bfliflet: Performing Z testing prior to texturing is an optimization most HW vendors perform these days. There are challenges where transparency comes into the mix.
Sorry for my terminology, I was referring to OpenGL’s pipeline.In the new OpenGL specification cant we have the depth test before texturing?
About switching buffers on a per fragment basis… I dont see what overhead could be there. Since its just another location of memory, I cant see how writing to different locations of a buffer is diferent from rendering to different buffers.
What am I missing?
About switching buffers on a per fragment basis… I dont see what overhead could be there. Since its just another location of memory, I cant see how writing to different locations of a buffer is diferent from rendering to different buffers.
First, if the buffers aren’t the exact same size/format, then there are problems just knowing where to put the pixel. It may have to re-rasterize the whole polygon to get that information.
Second, even then there will be a memory-performance problem. Let’s recall that in a typicall 4-pixel-pipeline setup (the standard one that your card uses), 4 pixels are being written at once. The hardware would have to mask out which pixels are being written to which location depending on the outputs of the fragment program. To make this happen, the hardware has to always do a read-modify-write to all of the possible locations for each pixel-quad.
The buffers should be of the same size and format.I dont see any use if they arent so.
What is a 4-pixel-pipeline setup? Does it have four parallel pixel pipelines? If so, are the 4 pixels adjacent or close together?
If this is the case then for 4-pixel-pipelines the hardware will have read-modify-write for both the buffers while masking out the appropriate buffer/location. So it will be slower. But it will be much faster than rendering a scene to a buffer, switching to another buffer inverting the fragment test and passing the whole scene again.
Also if we have a single pixel pipeline there should’nt be any overhead of the kind you described. Right?