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.)

I've been told the scissor rect doesn't eat fill.

read this short thread: http://www.gamedev.net/topic/669714-update-a-specific-region-of-the-render-target/

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.

(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?

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?

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.

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?

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?