82 replies to this topic

[~Dannyboy~]

This is probably a silly question, but... Are you suggesting that if we have to draw 500 poly's it would be faster to batch them with another 500 invisible poly's to stop the GPU getting bored? Or is it more just about drawing 1 lot of 1000 poly's rather than 2 lots of 500?

EDIT: I understand that the second point is obviously true. My main question is the first one, that is, is it faster to draw 1000 poly's than 500?

Edited by ~Dannyboy~, 04 May 2011 - 08:32 AM.

[Phantom107]

This is probably a silly question, but... Are you suggesting that if we have to draw 500 poly's it would be faster to batch them with another 500 invisible poly's to stop the GPU getting bored? Or is it more just about drawing 1 lot of 1000 poly's rather than 2 lots of 500?

Modern GPUs are optimized to draw thousands of polygons in as few draw calls possible.

It's faster to draw 10000 triangles in 1 draw call than 2 draw calls of 5000 triangles each.

[~Dannyboy~]

Thank you for that clarification.

[Phantom107]

So Mike, are you going to provide GM8.1 with a system that can disable certain batches over distance? Making a ton of distance checks in GML can really hurt performance.

[Smarty]

Anything else.....?

Not entirely related, but I was wondering if these same kinds of awesome performance improvements are also going to be reflected in the iPod, Android and PSP engines in the future, or is 3D still a no-go area there?

Nope... you'll have to do that in GML. That would require a proper model format, and we're not adding that here. sorry. There is a new distance in 3D GML command though, I'm sure that'll help

Would it make sense that as a next best thing, we'd have a command that can concatenate models into a single model? I can hardly imagine it, but could this still be faster than drawing separate models? Concatenated models would allow us to combine models on the fly without having to define vertices and basic shapes independently, nor draw models independently. Preferably this uses transformation commands in between adding models to have them scaled, moved and rotated according to our needs, for example,

model=d3d_model_create();d3d_model_add(model,othermodel1);d3d_model_add_translation(xt,yt,zt);d3d_model_add(model,othermodel2);d3d_model_add_rotation(xr,yr,zr);d3d_model_add(model,othermodel3);...d3d_model_draw(model,x,y,z,texid)

(Transformations with respect to the drawing position)

Edited by Smarty, 04 May 2011 - 11:52 AM.

[Phantom107]

I can hardly imagine it, but could this still be faster than drawing separate models?

It should improve performance a lot.

Take a look at the modern graphics pipeline: (image copyright nVidia Corporation)



As you can see, primitive assembly is required and eats away precious performance. By merging models as you suggested you're effectively making the amount of primitives a lot lower. That will result in less work for the graphics pipeline and thus increasing performance.

[Smarty]

It should improve performance a lot.

Take a look at the modern graphics pipeline: (image copyright nVidia Corporation)



As you can see, primitive assembly is required and eats away precious performance. By merging models as you suggested you're effectively making the amount of primitives a lot lower. That will result in less work for the graphics pipeline and thus increasing performance.

But in turn, more time is spent at the CPU which needs to merge the models together first (including transformations, to make things more useful). Note that this is a process one would intend to perform regularly, likely just before every time I wish to actually draw the model.

I really don't know if the performance boost at the GPU end makes up for the performance penalty at the CPU end, in that case.

EDIT: In spite of the demonstrations, I am also unsure if the execution of model drawing in parallel to game code execution is useful. Typically, drawing happens at the end of a step rather than in the middle, which means most of the logic pertaining to the game has already been taken care of. That is, unless it's still drawing while the engine is busy milling through the next step. How is that synced to the screen?

Edited by Smarty, 04 May 2011 - 01:31 PM.

[Phantom107]

I really don't know if the performance boost at the GPU end makes up for the performance penalty at the CPU end, in that case.

Merging should not be used on the fly, but only in the create event. There is no need to merge models that are supposed to move (such as the player and items), because you'd be doing the same work that the graphics pipeline is optimized for. It would just be a waste of resources.

However, where it should be used, and where it will provide a great boost, is with static objects. Think of houses, trees and rocks. By merging those up you invest a tiny bit of processing time in the create event, but you will benefit every single frame. Without any extra CPU processing. Think of it as merging objects into areas of 1000x1000x1000, where areas are hidden depending on their distance to the camera.

[NakedPaulToast]

Any chance the runner can provide some basic gpu information and features to the games?

[Smarty]

Merging should not be used on the fly, but only in the create event. There is no need to merge models that are supposed to move (such as the player and items), because you'd be doing the same work that the graphics pipeline is optimized for. It would just be a waste of resources.

Actually this was the whole point of my question. I honestly can't tell which of the two - the CPU or the GPU would be faster performing, essentially, different tasks with similar outcome. The entire question was there to focus on investigating which would or could be the faster implementation of the two.

However, where it should be used, and where it will provide a great boost, is with static objects. Think of houses, trees and rocks. By merging those up you invest a tiny bit of processing time in the create event, but you will benefit every single frame. Without any extra CPU processing. Think of it as merging objects into areas of 1000x1000x1000, where areas are hidden depending on their distance to the camera.

The reason to want it to happen on the fly is to be able to provide for a mechanism to animate models, without introducing a proper model format. Since there already are other ways of building complex models, having a merger command mostly for convenience isn't really that interesting...

[kburkhart84]

General rules.

Draw as much as you can in a single draw call. This means put as much into a GM model as you can.

If you draw <1000 polys (more on larger systems), the CPU will get in the way, and the GPU will get bored and have an affair with your HardDisk and thereby slowing your game down even more.

The more you can draw, the more time your CPU will have to execute other game code. The CPU and GPU work in parallel with large models.

Skin your models - even buildings and terrain. This allows large sections of a world to be rendered in one go, rather than a brick at a time.

Never, ever, draw QUADS if you can possibly avoid it. Your graphics card WILL hate you.


Anything else.....?

So basically, the way GM is now drawing models is similar to the way we would learn to do it if creating our own 3d engine, and therefore the same way modern 3d engines do it(except for the fancy stuff of course). Therefore, the way to optimize is the same as with any other 3d engine. I'm not going to repeat your post, but rather clarify that if someone needs optimization here, they can now apply public knowledge as far as 3d engines go, instead of only GM specific knowledge.

I'm glad 3d in GM is getting these improvements. But, it won't really be useful to me until we get some sort of animation, either bone or keyframe, of course bone being the much better option. But this is a great first step.

[FredFredrickson]

The reason to want it to happen on the fly is to be able to provide for a mechanism to animate models, without introducing a proper model format. Since there already are other ways of building complex models, having a merger command mostly for convenience isn't really that interesting...

I could see tremendous value in a slower-to-execute but quicker-to-draw function that merged many models into one chunk. You can do this currently to some extent, but you can't draw models with multiple textures in one larger model, so it's only useful for many objects that share the same texture, and often, those objects are not always going to be placed close enough together to take advantage of being grouped into a single model.

[Smarty]

I could see tremendous value in a slower-to-execute but quicker-to-draw function that merged many models into one chunk.

I'm not saying there is no value. I'm only saying it isn't as interesting.

You can do this currently to some extent, but you can't draw models with multiple textures in one larger model, so it's only useful for many objects that share the same texture, and often, those objects are not always going to be placed close enough together to take advantage of being grouped into a single model.

That's not true - the purpose of being able to combine multiple models into one and be able to add translations and transformations on the fly to the added models is to provide an alternate mechanism of an animated model - a vehicle or a character, for example. And having a single texture for those is mostly exactly what you'd want.

Edit: I already said that.

Edited by Smarty, 04 May 2011 - 04:15 PM.

[Desert Dog]

I guess I'm going to play the role of the ignorant guy.

Never, ever, draw QUADS if you can possibly avoid it. Your graphics card WILL hate you.

What are QUADS?

If you draw <1000 polys (more on larger systems), the CPU will get in the way, and the GPU will get bored and have an affair with your HardDisk and thereby slowing your game down even more.

Also,

I read on your blog how we now (or will have) static models, and dynamic models, rather than just dynamic.

You say you want calls to be big as possible, is this just for static models?

If I was to draw simple block, would it be 'best' if I use d3d_draw_block for what I understand would be a dynamic model, rather than creating a relatively tiny block model, which would be static, and the constant small drawing calls may get the cpu/gpu tangled up?

What I have in mind is a 3d breakout game type set up, where you have 100+ odd simple blocks(or other relatively low-poly models). Because these things are being destroyed, you cannot make them one big model.

How would you program this? Would using d3d_draw_block stop the cpu&gpu getting in each others way, and make a faster game, or is it 'business as usual' like we did before.. just turn them into models, and draw that, and even though the cpu/gpu are messing up, and slowing things down, it's still a lot faster.

[Manuel777]

Simple rules i used to follow anyway, GM's 3d was always quicker when drawing a single model rather than many.