Jump to content

  • Log In with Google      Sign In   
  • Create Account


Shouldn't the depth-test stop occluded pixels from being shaded?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 mind in a box   Members   -  Reputation: 544

Like
0Likes
Like

Posted 10 December 2013 - 08:22 AM

Hi!

 

From what I know, the GPU shouldn't run a pixel shader for a pixel which already failed the depth-test, right?

 

We're developing a mobile game for WindowsPhone8 at the moment, using Direct3D11. To save some performance we created some geometry which we render behind the planes of our HUD, to not waste shading power to the pixels which will get occluded by our hud at the end anyways.

 

So what we are basically doing is the following:

  • Render HUD-Masks
  • Render World
  • Render HUD

When disabling the HUD we can see indeed that the pixels would not get into our backbuffer, but even when I let the Masks occlude the whole screen, we do not see any improvement of performance, which should be the case because reducing the resolution drastically improves it. So since we are pixelshader-bound like it seems, why isn't there any improvement? Did we maybe just miss some flag which disables depth-culling?

Or is this just unsupported on mobile GPUs?

 

Thanks in advance.



Sponsor:

#2 mhagain   Crossbones+   -  Reputation: 7328

Like
1Likes
Like

Posted 10 December 2013 - 12:07 PM

The most likely cause of this is that you don't have depth-writing enabled when drawing your HUD masks.  If that's the case, the depth buffer will still contain the clear value after drawing them, so the depth test for the scene will be as if they hadn't been drawn.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#3 Samith   Members   -  Reputation: 1876

Like
1Likes
Like

Posted 10 December 2013 - 12:36 PM

Alphatest and texkill/discard instructions in the pixel shader will disable early-z. Are you using either of those features?

#4 mind in a box   Members   -  Reputation: 544

Like
0Likes
Like

Posted 10 December 2013 - 01:39 PM

I think alphatest could be enabled when rendering those, I've seen something like this in my code but thought since the vaules are written into the depth-buffer the early-z test will be used anyways. I'll check that later :)



#5 MJP   Moderators   -  Reputation: 10033

Like
0Likes
Like

Posted 10 December 2013 - 03:40 PM

Early-Z optimizations are hardware-specific, and aren't actually part of the D3D pipeline. The spec basically says that the depth test only has to prevent the pixel values from being written to the current render target, not that the pixel shader shouldn't be run. The drivers will therefore only enable early-z optimizations for cases where using it would produce the same render target results as if the optimization weren't used. The conditions that allow the driver to enable early-z are dependent on the exact GPU being used, so you should consult vendor-specific programming guides to know for sure.

In your case you're running on mobile hardware, which typically uses some variant of TBDR. These GPU's will usually always have use early-z, unless you use alpha test or exporting depth from the pixel shader.



#6 mind in a box   Members   -  Reputation: 544

Like
0Likes
Like

Posted 10 December 2013 - 03:42 PM

I don't know, I disabled alphablending now, but it doesn't help. Maybe I'll just go with the stencil-buffer, even though I've never used it before, but I think this is what it is for?



#7 cgrant   Members   -  Reputation: 529

Like
0Likes
Like

Posted 11 December 2013 - 11:32 AM

I'm assuming you HUD is not fully opaque, if the HUD is being blended in as an overlay ( this indicates some for of transparency ), then there will be no pixels that are fully occluded. Depending on the blend mode, the actually framebuffer content at the currently fragment location will be needed for the blend operation. Unless the HUD is fully opaque, in which case setting the depth value of the HUD fragments to the near clip plane value and rendering the HUD first will cause the occluded fragments to fail the depth test. All this is nought if like several other posted above if hi-z or early-z is disabled for whatever reason.



#8 mind in a box   Members   -  Reputation: 544

Like
0Likes
Like

Posted 11 December 2013 - 01:19 PM

We created some meshes which roughly cover the area of our HUD-Elements (Because they have a small fade at the sides) which we are rendering instead of the actual HUD-Elements.

These are the first Objects to render in the whole frame, so what could disable my early-z in such a case?






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS