Jump to content

  • Log In with Google      Sign In   
  • Create Account


Yet another batching thread


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
13 replies to this topic

#1 Ubik   Members   -  Reputation: 579

Like
0Likes
Like

Posted 24 August 2004 - 07:38 AM

I came up with an idea to use with batching, so as short as i can write: First you give all resource types a numerical value where more "important" resource types have larger value e.g.

Vertex buffers: 1
Textures: 10
Shaders: 100

When a resource of some type is created, it is given a value that is simply the number of objects of that type at the creation time. (Simply: 1, 2, 3 etc. Damn my limited expression abilites.) The values are scaled after loading, so that the lastly created objects value is the weight of its resource type. The highest scaled texture id would be 10.

You propably have guessed that this approach assumes floating point numbers, but i think that this is more flexible as you can insert new resources between the old ones, without going over the highest value.

When a rendering call is finally made it gets a value that is sum of the resources scaled-id's. The batching can now be made with this single value which should be correct, or at least correct enough. I admit that i havent done any deep analysis of the idea (i got it yesterday), but it seems to work. The troubles that i can think of could be solved with giving larger difference to the resource weights.

*sigh* A long post again, i hope that i didnt take away any (if any) of your replying-willingnes. [I should put a smiley here]

Sponsor:

#2 CoffeeMug   Members   -  Reputation: 852

Like
0Likes
Like

Posted 24 August 2004 - 07:41 AM

What problem do you intend to solve with this approach?

#3 Ubik   Members   -  Reputation: 579

Like
0Likes
Like

Posted 24 August 2004 - 08:24 AM

Quote:
Original post by CoffeeMug
What problem do you intend to solve with this approach?


Well, generally batching drawing calls, to make rendering more efficient. (If that can be defined as a problem.) It is more of a question. I got to admit that the original post did not contain the question itself, at least not directly.

Anyway, the question is: Can it be assumed that this kind of batching would actually work? Is there a flaw in the concept that i completely missed, while being so excited about it.

#4 CoffeeMug   Members   -  Reputation: 852

Like
0Likes
Like

Posted 24 August 2004 - 09:20 AM

Can you explain your method in more detail? Perhaps a step by step explanation? I don't seem to understand what it does.

#5 mohamed adel   Members   -  Reputation: 174

Like
0Likes
Like

Posted 24 August 2004 - 01:34 PM

Batching is decreasing the number of drawprimitive calls as far as possible to save time needed by the processor to submit the drawprimitive() calls while the GPU is idle. as far as I understand your algorithm, you are not saving the number of drawprimitive calls.
Also you are giving the resources a periority number based on the number of objects of that type at the creation time. this is not true. the most important resource is the one used very much. For example, in a shoting game, your most important resources are the textures and vertex buffers used to render your main character (the game hero) as this character will be rendered in all the game frames regardless of any thing, but the monsters you are shotting, are not rendered every frame. They are only renderend when they come to your sight.
The most important resources should be created first because this makes the driver give them a higher periority in memory allocation and access.

#6 Etnu   GDNet+   -  Reputation: 880

Like
0Likes
Like

Posted 24 August 2004 - 01:57 PM

Why do you need to scale values, though? Seems pointless. Unless transparency is involved, it probably doesn't make a difference which texture you set first.


#7 Ubik   Members   -  Reputation: 579

Like
0Likes
Like

Posted 24 August 2004 - 07:40 PM

Maybe this example makes it a bit clearer:
There is, let say three objects of each resource types with following values

Shaders: first shader 0.0, second shader 50.0, third shader 100.0

The other resources follow the pattern, but in different scale:

Textures: 0.0, 5.0, 10.0
VB's: 0.0, 0.5, 1.0

When making a drawing call, sum of the values is given to the call:
Call with shader 2, texture 2, VB 3 would get sum 50+5+1=56
Call with shader 3, texture 1, VB 1 would get sum 100+0+0=100
Call with shader 1, texture 2, VB 3 would get sum 0+50+1=51

Calls can now be sorted by this single value. The purpose of scaling should be visible by now: The shader change will now always overrun the other state changes, and this works with textures and VB's too. If i wanted to apply lightmap textures in this scheme i could make their weigth 100, and give the shaders weight of 1000, thus making the system flexible.

Etnu: I know that the order does not matter, but giving some absolute values simplifies things. And of course, the fixed values allow precalculating for most of the meshes as they most of the time use exactly same drawing calls or actually, the same resources.

#8 Ubik   Members   -  Reputation: 579

Like
0Likes
Like

Posted 24 August 2004 - 07:56 PM

Hmm, the examples were not the best ones. Drawing calls with same shader and different texture and VB would be better:
Shader 2, texture 1, VB 1: 50+0+0=50
Shader 1, texture 2, VB 1: 0+5+0=5
Shader 1, texture 2, VB 2: 0+5+0.5=5.5
Shader 1, texture 2, VB 3: 0+5+1=6

#9 mohamed adel   Members   -  Reputation: 174

Like
0Likes
Like

Posted 24 August 2004 - 08:17 PM

Quote:
Original post by Ubik
Calls can now be sorted by this single value.

and this sorting represents what? The periority of the call or the load of the call on the processor?
Quote:
Original post by Ubik
Etnu: I know that the order does not matter, but giving some absolute values simplifies things.

What things? how did you improve batching now?how could this algorithm decrease the number of calls to DrawPrimitive()?

#10 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 24 August 2004 - 08:36 PM

Obviously the point here is that shader one is rendered with texture 2 and VB1 first, then, without needing to load a new shader or change textures, you can process VB2 and VB 3. Thus you save overhead on changing the texture or shader state.

Essentially he's setting out a mathematical value that represents a tree, with highest priority (presumably the most expensive things to change) nodes closer towards the root node.
Of course this approach requires recalculation of some or all weights when a new resource is loaded, or an unused one is released.

#11 Ubik   Members   -  Reputation: 579

Like
0Likes
Like

Posted 24 August 2004 - 08:49 PM

It is true that it does not decrease the number of drawprimitive calls, but it helps with keeping the number state changes low, as the similar calls have values near each other.

I think that lowering the number drawprimitive calls is more of a preprocessing step (done either when creating the geometry or at load time). That would include things like merging vertexbuffers and maybe textures of a mesh to render a mesh in optimally one call (or even multiple objects in one call).

I should make clear that the sum value of rendering call (including the state changes with drawprimitive()) is simply used to get a position in rendering queue. It does not represent any kind of frequency or anything like that. It's just a artificial value to get a index in the rendering queue.

The "importancy" in the first message means mostly the cost of state change of that resource type.

#12 mohamed adel   Members   -  Reputation: 174

Like
0Likes
Like

Posted 25 August 2004 - 12:03 PM

But sorting resources according to usage should be done each frame because the objects you rendering are changing each frame.

#13 mohamed adel   Members   -  Reputation: 174

Like
0Likes
Like

Posted 25 August 2004 - 12:05 PM

also you forgot front to back rendering which is a must for complicated pixel shaders.you can take one rendering pass to fill the z buffer before rendering to solve this.

#14 Ubik   Members   -  Reputation: 579

Like
0Likes
Like

Posted 25 August 2004 - 07:05 PM

Quote:
Essentially he's setting out a mathematical value that represents a tree, with highest priority (presumably the most expensive things to change) nodes closer towards the root node.


Exactly. This system is like inverse version of radix sorting. It is a bit unfortunate that it makes loading resources after the actual loading sequence a bit harder, but fortunately not impossible.

Quote:
But sorting resources according to usage should be done each frame because the objects you rendering are changing each frame.


Yes. The actual sorting must be done each frame, but calculating those values can be done beforehand.

Quote:
also you forgot front to back rendering which is a must for complicated pixel shaders.you can take one rendering pass to fill the z buffer before rendering to solve this.


Maybe depth could be added as an "weight" too? The system should allow sorting by anything that can be represented numerically. Of course, precision becomes an issue at some point, but i doubt that there is need to sort by more than, lets say five states. At least doubles should be enough!




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS