Despite having looked around online I haven't been able to figure out exactly what a draw call is and exactly what a render pass is.

I understand that a render pass is going to use a vertex shader and pixel shader to generate a final layer that is then may be composited with other layers to form the finished frame, but I don't understand where draw calls come in. As far as I can tell a render pass uses draw calls...

Can draw calls exist outside of a "render pass", and if it can what is an example? The termonalgy is used so loosly used it's hard for me to follow exactly what is being talked about sometimes. I think people mistake an entire render pass for a draw call and from my understanding they arn't the same thing.

If somone could clarify this for me It would be much aprieciated.

As I understand it, and I'm a little hazy:

A drawcall sends geometry and texture information to the GPU. There may be several drawcalls for a single model if it uses multiple textures, shaders and smoothing groups.

A rendering pass is where the engine draws the model on the screen, and it may need to calculate several passes - a pass for each light in the scene, a pass for a alpha, a pass for reflection etc.

essentially it comes down that both stand for issuing draw calls to the graphics card. a draw call here being the atomic operation of drawing.

rendering pass, is as rick put it, mostly to give the draw calls a name. Ie under what kind of purpose the draw calls are issued...
A rendering pass can be either for a single model, or for the full scene. Like "depth only pass" or "light pre pass" (so it can consist of multiple draw calls, while a draw call itself is atomic).

I'd love to update my ancient glossary. I also need to learn more about these terms, nothing like trying to define something to help convert the hazy bits into solid clarity.

Originally Posted by EricChadwick

nothing like trying to define something to help convert the hazy bits into solid clarity.

that was such a technical talk thing to say

Originally Posted by Rick Stirling

There may be several drawcalls for a single model if it uses multiple textures, shaders and smoothing groups.

.

the smoothing groups have no effect on the amount of draw calls just objects/materials

but they might BREAK you triangle strips and make your model perform less good because of that ;)

For UE3 at least, I believe it ends up being one draw call per light per shader. So if you have a character that uses two shaders being lit by 3 dynamic lights, that will amount to 6 draw calls. Thankfully static lighting gets collapsed to a single draw call.

However, in deferred lighting engines all lighting gets collapsed to a single draw call per shader. The main tradeoff there is that adding in more lights increases fillrate rather than the number of draw calls, but it's pretty sweet not having to separate your dynamic and static lighting.

If a render pass is defined as the task of rendering a single asset to the screen (first time I've heard that phrase, to be honest), then that can be composed of several draw calls. Similar to the difference between tris and polys, you would want to measure performance by draw calls rather than render passes.

edit: Warby's right, smoothing groups only affect in-engine vertex counts, not draw calls.

Yeah, like I said, hazy

generally what seperates draw calls changes from engine to engine, but you always want less of them

man im so tech

sorry to bump this old thread with a noob question, but can anyone explain to me if/how atlas textures affect draw calls?

for example, if i had 2 seperate objects in a scene which both however use the same texture map/shader, what benefits do i actually get? wouldn't it still send seperate draw calls for each object?

Originally Posted by lefix

sorry to bump this old thread with a noob question, but can anyone explain to me if/how atlas textures affect draw calls?

for example, if i had 2 seperate objects in a scene which both however use the same texture map/shader, what benefits do i actually get? wouldn't it still send seperate draw calls for each object?

The benefit of a texture atlas is that you only have to bind 1 texture which means that it´s only one drawcall.
Imagine you have ~10 textures on 1 atlas. You only have one drawcall for it, but if they were separate textures you would have 10 draw calls.

you would sort to minimize shader,texture binds,... and then do multiple drawcalls under the same state (shader, textures...). Consecutive drawcalls under same state are cheaper than setting up the state and drawing individual pieces.

Whether you can get a single drawcall across objects is a bit more work (requires objects stored in same buffers...), but would give an additional speed benefit.

typical state changes in a "hot loop" (drawing your objects):
* raster state (blending,depthtest... that is typically rarely changing and you can think of a system that prefers to organize stuff as layers, e.g. one layer doing all blended stuff on top of a layer rendering all opaque)
* shader binds
* vertex/index buffer binds (your actual geometry is often stored on some gpu buffer)
* texture binds
* uniform binds/updates (typically stuff like control parameters in your shaders)

A drawcall just defines a subrange within your geometry buffers to be drawn under whatever state is currently active. (raster apis are state machines)

Now the more has changed between drawcalls, the more validation has to be done by the driver and additional commands sent to the gpu.

If you want to go through the gory details I recommend reading this

http://fgiesen.wordpress.com/2011/07...ne-2011-index/

So does virtual texturing gain an advantage here. seeing as everything is in a small number of large atlases?

In theory you can draw an entire scene in about 2 or 3 draw calls (or passes) with virtual texturing, because everything is a single shader (the other draw calls or passes are for atlas lookups and stuff). You probably wouldnt store the entire scene as one mesh though.

"because everything is a single shader" that's a bit optimistic, maybe you meant "when everything...".
virtual texturing only affects texturing, nothing else. If your game was using multiple material shaders, virtual texturing alone won't cut that down.

as for advantages, it kinda depends, virtual texturing is not "free" and brings in additional complexities. So if you can get around it, by just using texture arrays or old school atlas, that will be faster (as those two also allow you to raise batch efficiency).

I'd never heard of texture arrays. thats pretty neat.

I only heard of them when dx11 came out, we used texture2d arrays to stuff our textures for our terrain.

so your collecting tiles of the same dimension into arrays? this then allows you to avoid state changes?

yes, it's a dx10 generation feature, so it's out for a while.

Well with virtual texturing its likely almost everything only needs to have 1 or 2 shaders, and anything that requires a special shader would not use virtual textures. Rage seems to only have 1 surface type for all environments, although it would be much better if some surfaces had real specular and normal info instead of baking them completely.

So if I'm working on a game that will make use of modular pieces from which the player can build their own vehicles. Is it best to use a dynamic texture atlas or a texture array?

If I'm understanding this correctly, it's 1 draw call per shader(material) but if I have 3 modular pieces using the same material with 3 different 512x512 images for the textures I now have 4 draw calls total?

The sheer amount of assets required for this is going to make keeping track of what modular piece is in what texture sheet a nightmare if we do it by hand.
Not to mention naming conventions will get wonky.

Any suggestions?

@artquest: If all of those pieces are going to be used in the same part of the game (which makes sense if it's your player's vehicle), perhaps you could make a texture atlas of a whole bunch of pieces. Or have a texture that contains a bunch of generic bits and pieces, and assign the UVs of your modular bits accordingly. Depends on game/context I guess.

Like, if it's modular stuff for a player vehicle, then there should be a greater focus on planning anyway, so you should from the start have a pretty good idea of which things can share textures or share an atlas.

Originally Posted by Elyaradine

@artquest: If all of those pieces are going to be used in the same part of the game (which makes sense if it's your player's vehicle), perhaps you could make a texture atlas of a whole bunch of pieces. Or have a texture that contains a bunch of generic bits and pieces, and assign the UVs of your modular bits accordingly. Depends on game/context I guess.

Like, if it's modular stuff for a player vehicle, then there should be a greater focus on planning anyway, so you should from the start have a pretty good idea of which things can share textures or share an atlas.

Thing is you're going to be able to have a very large number of these things on screen at once. It's an overhead strategy game. You'll potentially be able to have a ton of your own custom ships/vechiles on screen at any given time.

So say I stack a bunch of small modular pieces all into one 2048x2048 texture sheet. And a player only uses one small piece on one of his many ships.. I've now loaded the entire sheet even though what I see on screen is relatively small.

Is this something to worry about? What's best to prioritize, draw calls or memory savings?

Texture atlases are almost always automatically generated. For instance in an mmorpg the player can choose a bunch of random customizations and then while the character is being loaded it can generate a texture atlas containing all the required textures for that character, and automatically combine the meshes and offset/scale uvs as needed.

@artquest: As with many things when it comes to optimization, it's often a balancing game. Depending on whether you're drawcall or memory bound, you'd pick one way of doing things or another. Doing either of them badly will kill your game.

Ideally you'd be able to predict which kinds of things would be seen together, and pack your atlases that way (automatically or offline). Sometimes that's not possible... and you just have to balance things as best you can, and scale down on stuff across the board if you're still not reaching your performance goals. :/