• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
xlope01

Why discard pixel take a noticeable performance hit?

8 posts in this topic

something as simple as that

if(textureColor.a < 0.5f)
	discard;

take around 25% hit in frame rate (assuming all the objects on your scene use that)

0

Share this post


Link to post
Share on other sites

Normally, GPUs can do depth testing and writing before running a fragment shader. When there's a possibility that a fragment might be discarded, then the GPU has to do the depth test/depth write after running the fragment shader (else it risks writing pixels to the z-buffer that might end up discarded). This means that simple addition can cause a lot of extra work to be done.

 

Also, GPUs have various optimisations for depth buffers such as hierarchical depth and depth buffer compression going on under the hood, it's possible that these are also being bypassed by the possibility of a discard.

 

That's just a simple explanation. For more detail this article is great: http://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ (parts 7, 8 and 9 look relevant)

0

Share this post


Link to post
Share on other sites

For a discarded pixel you've already paid the cost of its fragment shader even though it doesn't writa anything. Further, you'll have to at least run the fragment shader for the visible geometry behind it, so that's an added cost. This really adds up if there's lots of overlapping discarded pixels - lots of fragment shader computation performed, with the results thrown away.

0

Share this post


Link to post
Share on other sites

Things that you may try in this case:

 

- use discard / clip only with objects absolutely needing it, so fully opaque objects should use a pixel shader without discard / clip in it

- optimize meshes - works best with particles maybe, but optimizing the mesh size / form in respect of the texture may reduce the pixel shader invocations 

 

Cheers!

2

Share this post


Link to post
Share on other sites

Some other tips:

  • If you can replace the discard call with an alpha blending function you'll be able to remove it entirely.  You'll pay some overhead for blending of course, but it should balance out in your favour.  Look at the step function for one way of handling "< 0.5" cases.  For your example, something like "output.a *= step (0.5, textureColor.a)" with an alpha blending mode would be appropriate.
  • If you have a GS active, and if you can move the comparison you're making the discard on to the GS, you could have that output a zero-area triangle instead of discarding in the pixel shader.  You'll pay some overhead for the GS branching here, but the triangle won't even get rasterized, so again you should win.
  • If you're always comparing texture alpha to a fixed value then you could just hack the texture alpha values at load time - if they're less than 0.5 slam them to 0 there.
1

Share this post


Link to post
Share on other sites

One reason to do what the op does is that it can give smooth edges on magnified textures, and it can be easily used regardless of rendering order. The reasons for the slowdown seems outlined by others, and I just wanted to point out that I have seen the opposite behavior, where adding discard for alpha < 0.5 increases performance for alpha-blended triangles that have large areas with alpha = 0. However, when alpha-blended geometry is drawn back to front as it was in my case, there is no need for depth writes so there were no conditional depth writes.

Using the technique only on triangles that need it (and if the reason for it is not rendering order, possibly combined with drawing affected geometry last) should limit the performance impact.

1

Share this post


Link to post
Share on other sites

 

  • If you can replace the discard call with an alpha blending function you'll be able to remove it entirely.  You'll pay some overhead for blending of course, but it should balance out in your favour.  Look at the step function for one way of handling "< 0.5" cases.  For your example, something like "output.a *= step (0.5, textureColor.a)" with an alpha blending mode would be appropriate.

 

 

I'm not sure if I agree with this device. The main issue with switching to alpha blending isn't the blending itself, but the fact that you can no longer write to your depth buffer when using it. This can result in overdraw which increases your shader costs, and also poses problems for deferred techniques or post-processing stages that rely on the depth buffer.

0

Share this post


Link to post
Share on other sites

 

 

  • If you can replace the discard call with an alpha blending function you'll be able to remove it entirely.  You'll pay some overhead for blending of course, but it should balance out in your favour.  Look at the step function for one way of handling "< 0.5" cases.  For your example, something like "output.a *= step (0.5, textureColor.a)" with an alpha blending mode would be appropriate.

 

 

I'm not sure if I agree with this device. The main issue with switching to alpha blending isn't the blending itself, but the fact that you can no longer write to your depth buffer when using it. This can result in overdraw which increases your shader costs, and also poses problems for deferred techniques or post-processing stages that rely on the depth buffer.

 

 

That depends on exactly what the OP is trying to achieve.  It would be useful to actually have that info as right now I'm feeling that we've jumped into the middle of a problem-solving exercise and are trying to assist with the OP's chosen solution, without knowing what the original objective that prompted it was.  There may be other completely different approaches.

0

Share this post


Link to post
Share on other sites

I need to discard the pixels so the alpha part of the texture will not be visible, that i use for the foliage. I can minimize the performance hit by using "discard" only on the parts that i need, however doing this I have to break down the objects creating more objects meaning more cpu load.(example a building have some foliage on it and it is one object all together, now will became two object).

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0