Texture and Shader handling in rendering pipeline

[Sawtan]

Hi folks!

New to the forum, but looking forward to share and consume knowledge and info with you all!

I have a question that has bothered me since I started writing shader based gl code, how to optimize the rendering pipeline in the best way. I've read a ton of GL books and gone through countless tutorials on the subject, but each one just touch on the basics on how to get things working. Not on how to actually set up a optimized and clean rendering pipeline for a working graphics engine.

The parts that stand out in my case is how to handle textures and shader programs in a good way, and what standard I should go after when it comes to handling of these precious resources.

The basic question is, how many times in a single render cycle should I be allowed to change 1: Shader program, 2: Texture.

To take a real life example on a game that I'm working on at the moment, I first do my general rendering that uses 2 textures, one for sprites and one for font sprite, the textures I use is quite big, 2048^2 as I'm working on a HD version of a game. Here I'm pondering on perhaps using a 4096^2 texture as well, looks like most devices can handle these sizes, and I can cram in pretty much all the gfx assets I need onto one of those babies. But is it good practice? Do I win anything when it comes to rendering speeds, and is the win big enough to handle large complex sprite maps like that? Or can I have 50-100 different texture images that I can pick from during a single cycle?

The second parameter is the Shader program, same goes here really, I have a shader for general sprite handling, and a shader for the font renderer, but I also have a special shader for post fx that I use for a FBO that will be the final scene in the pipeline. I think there will be more programs involved here, and I might need to switch between them during a rendering cycle. Is it to much to switch shader programs 10-20 times in a single cycle, or is it within acceptable limits?

The engine setup that I have today works quite well and I can't really find any problems with rendering speeds, but I want to push this a bit, I'm working on a particle engine that I want to use, and that will bring an additional shader into the equation, and probably additional sprite maps that needs loading.

What I really want to know is if there's some kind of standard to comply with, would be great to have some frames to work within when it comes to the rendering pipeline.

Looking forward to hear your input on these questions!

[Emerge!Lord]

On 10.4.2016 at 10:59 AM, Sawtan said:

The basic question is, how many times in a single render cycle should I be allowed to change 1: Shader program, 2: Texture.

To take a real life example on a game that I'm working on at the moment, I first do my general rendering that uses 2 textures, one for sprites and one for font sprite, the textures I use is quite big, 2048^2 as I'm working on a HD version of a game. Here I'm pondering on perhaps using a 4096^2 texture as well, looks like most devices can handle these sizes, and I can cram in pretty much all the gfx assets I need onto one of those babies. But is it good practice? Do I win anything when it comes to rendering speeds, and is the win big enough to handle large complex sprite maps like that? Or can I have 50-100 different texture images that I can pick from during a single cycle?

The impact on rendering speed in terms of game-loop iterations is highly dependent on how many times you will make calls from your client to your GPU, the more often you have to transfer data back and forth, the more costly work has to be done and therefore the slower the rendering get's. Bigger textures (vs many small ones) mean the tradeoff memory vs. computational speed. There is a little more work on the GPU to be done when using a lot of small ones (switching texture units e.g.), so this means more computational costs per render pass. On the other hand you may want to keep some of your sprite maps separated by concerns, not because of technical issues, but because of a cleaner view on your datamodel and your assets. As you can see it's difficult to determine a best practice, there are engines which use large sprite maps , but afaik most are separating their sprite maps at least on a per gameobject base.

In terms of engine architecture you should also consider that each texture transfer has roundtrip costs, by wich I mean the overhead transfering the data to your client and not only to the GPU. Either way you choose you should use a profiler and measure the actual costs and compare them to each other by yourself.