Jump to content
  • Advertisement
Sign in to follow this  
Oogst

Performance difference between scissor and viewport?

This topic is 1011 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 would like to make certain objects only render at certain parts of the screen. Basically exactly what the scissorRect can do. However, the exact same thing can also be achieved by setting the viewport to a smaller region and compensating the matrices for the offset. Does this give better performance? If I understand the documentation correctly the scissorTest is done per fragment while the viewport is done per vertex. This suggests that using the viewport instead of the scissorRect would potentially save significant amounts of fillrate. Is this true or am I misunderstanding this? ScissorRect is a lot easier to implement so I only want to use the viewport for this if I am actually gaining something that way.

 

(Note that this is for our 2D game, in which fillrate is currently the main performance bottleneck. The fragment shaders are extremely simple, so basically most performance goes into large amounts of overdraw of partially transparent objects.)

Share this post


Link to post
Share on other sites
Advertisement
Scissors would probably be better. Scissors prevents the render from filling anything out of bounds.

I think view port still fills.

Share this post


Link to post
Share on other sites

Okay, I'll just happily use scissors then. Thanks! :)

 

Scissors would probably be better. Scissors prevents the render from filling anything out of bounds.

I think view port still fills.

 

From how I understand it the viewport might sometimes fill outside its bounds, for example when doing a wireframe render with a thick wire, because viewports operate on the vertex level. Viewports don't just fill all pixels of the object outside the viewport bounds: that only happens in those rare edge cases like that wireframe edge.

Share this post


Link to post
Share on other sites


(Note that this is for our 2D game, in which fillrate is currently the main performance bottleneck. The fragment shaders are extremely simple, so basically most performance goes into large amounts of overdraw of partially transparent objects.)

Have you tried screen space tiling such that all Frame Buffer reads and writes result in a FB/DB cache hit?

Share this post


Link to post
Share on other sites

What is "screen space tiling"? If I Google for this I get hits for tile based renderers but as far as I know that is a type of graphics hardware, so I suppose you mean something else?

Share this post


Link to post
Share on other sites

Sorry I might be using my own terminology, not sure.  The basic idea is for 2d is:

 

1. figure out how big a tile can fit in the GPU ROP caches (i think this is the proper term)

2. divide the screen into above sized or less tiles.  Create a bin per tile.

3. for all your alpha-blended let say quads find out which tiles are affected and add to bins.

4. set scissor rect for tile.  Draw all geometry for tile from bin.

5. repeat for all tiles.

Share this post


Link to post
Share on other sites

That explodes the number of rendercalls, unless the GPU ROP caches are quite big. Is this actually a good idea when rendering 500 objects per frame?

Share this post


Link to post
Share on other sites


That explodes the number of rendercalls, unless the GPU ROP caches are quite big. Is this actually a good idea when rendering 500 objects per frame?

Yes it increases the number of draw calls but depending on what type of 2d game you are making this might not be an issue.  Then of course there is always instancing with texture atlas's or indirect draw calls with texture atlas's.  ROP caches vary depending on hardware, but you can disable the technique depending on detected hardware, a benchmark or forced with a user option.  I hear DX11 can hit 10,000 calls a frame normally... but like I said there always instancing or indirect draw calls.  How's your performance looking now? on what hardware?

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!