• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Semei

DX11
Batching and minimizing DIP's and state changes

14 posts in this topic

It have come to my attention that although general rendering performance guidelines suggest minimizing draw call count and render state changes, most big AAA tiles do only very minimal optimizations on this or no optimizations at all, for example i PIX'ed few popular games to see whats up:

Mass effect - ~1000 draw calls per frame, 20000(!) render state changes and ~1000 draw primitive UP calls per frame
Civilization V (DX11) - 3000+ draw calls, thousand or so set pixel/vertex shader, 500+ set texture, etc per frame on average

Whats up with this nonsense? Why none even bother to do some optimizations on this matter?
1

Share this post


Link to post
Share on other sites
Maybe they already optimized what they could...
Maybe they decided that performance was good enough and further optimizing was not worth the effort...
Maybe they were quickly approaching a deadline...
0

Share this post


Link to post
Share on other sites
You can only minimise so much before the work involved in doing so becomes overly onerous and you get into diminishing returns. Maybe these titles genuinely do have ~1000 unique object states per frame, and therefore can't go any lower? 1000 draw calls is really quite low for a large complex scene, so I certainly wouldn't call it "very minimal or no optimizations". "No optimizations" in a 1,000,000 triangle scene would be 1,000,000 draw calls, after all.
0

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1298305365' post='4777071']
You can only minimise so much before the work involved in doing so becomes overly onerous and you get into diminishing returns. Maybe these titles genuinely do have ~1000 unique object states per frame, and therefore can't go any lower? 1000 draw calls is really quite low for a large complex scene, so I certainly wouldn't call it "very minimal or no optimizations". "No optimizations" in a 1,000,000 triangle scene would be 1,000,000 draw calls, after all.
[/quote]

Not true.

Look at this(ignore the gray stuff): [url="http://img202.imageshack.us/img202/2112/greybar.jpg"]http://img202.images...112/greybar.jpg[/url]

Each yield icon (green/gold coins on map) gets a draw call(!), each hex grid overlay (white border around EACH hex) gets a draw call, ignoring the fact that you could do that with one draw call even without using instancing - and with simpler code! With all this i think in screen shot we are getting well over 10k+ dip's, and its NOT fast.

Im not a pro graphics engineer, but with a 10 minute of taught you could render all yield icons in two draw calls and one set texture (they are using DX11 FFS!), and whats even more obvious, you could overlay hex grid with one draw call or none at all if you just sample it when drawing terrain...

My taught is that they just do not give a damn... Same thing for my loved Blizzard - in WoW when drawing terrain chunks, instead of doing simple test "if (stage0Texture != textureToSet)" they just go what a heck and don't do nothing, ignoring the fact that wow is heavily cpu bound and targeted at wide range of hardware, low-mid end including (released in 2001!) - and i tested, i have build the same thing, and doing this simple optimization gave 11% performance gain, for about 20 lines of extremely simple code.


So my taught is - if you are indie developer making your game, don't event try to optimize this stuff, no one is doing it anyway and being fine - even when targeting low-mid end hardware. Doing this kind of optimization have proven to be useless and don't listen to 101 texts of saying batch batch batch, omg draw calls, etc - just write your game flexible and start worrying if you are reaching over 3k in average scene. ;P
0

Share this post


Link to post
Share on other sites
I don't think there are noobs working for the large companies. I'm pretty sure they know they could have done better, but when deadlines are approaching and the publisher keeps the pressure up and there are other tasks with higher priority AND you know that your game will sell shitloads either way..

I hope your advice to indies to not give a f*** was just sarcastic. :)
0

Share this post


Link to post
Share on other sites
[quote name='Semei' timestamp='1298476839' post='4777994']
Each yield icon (green/gold coins on map) gets a draw call(!), each hex grid overlay (white border around EACH hex) gets a draw call, ignoring the fact that you could do that with one draw call even without using instancing - and with simpler code! With all this i think in screen shot we are getting well over 10k+ dip's, and its NOT fast.
My taught is that they just do not give a damn... Same thing for my loved Blizzard - in WoW when drawing terrain chunks, instead of doing simple test "if (stage0Texture != textureToSet)" they just go what a heck and don't do nothing, ignoring the fact that wow is heavily cpu bound and targeted at wide range of hardware, low-mid end including (released in 2001!) - and i tested, i have build the same thing, and doing this simple optimization gave 11% performance gain, for about 20 lines of extremely simple code.[/quote]The simple explanation is that all those coins on the map were implemented by a gameplay programmer, not a graphics programmer. Furthermore, graphics programming was most likely outsourced to an engine developer like Emergent.
So -- designer asks gameplay to put coins on the map, gameplay uses the engine to do so. Performance is "ok", so no one delves deeper into the flaws of the engine. The engine's graphics programmer works in a different building and isn't directly exposed to the horrible abuse his modules are receiving from negligent gameplay code, so he doesn't improve his interfaces.

Its very easy to imagine how perfectly optimised code [i]doesn't[/i] get produced in the real world, where time and money are quite limited.[quote name='Semei' timestamp='1298476839' post='4777994']
So my taught is - if you are indie developer making your game, don't event try to optimize this stuff, no one is doing it anyway and being fine - even when targeting low-mid end hardware. Doing this kind of optimization have proven to be useless and don't listen to 101 texts of saying batch batch batch, omg draw calls, etc - just write your game flexible and start worrying if you are reaching over 3k in average scene. ;P[/quote]Yeah.... nah.
I'm working on a console game atm where half the CPU time is consumed by rendering tasks. I would love to perform the optimisations you're on about (we could probably reduce draw calls by 10x), [b]but frankly the schedule doesn't allow time for it[/b]. On the sequel I'll definitely be doing some of this optimising so that we can do more stuff with our CPU, other than waste it on GPU command buffer generation.
1

Share this post


Link to post
Share on other sites
Thanks Hodgman!

This indeed is also issue when you don't have strict time limit, but are creating and planning to release indie game in timely fashion - and maybe this is even worse, because you get impression that your schedule is OK, throughout you are wasting tons of time on least important details, and not focusing on right parts of code - this and some other aspects of indie game design are the main reason why so many games get abandoned unfinished.

I have seen articles talking about general guidelines for finishing your hobby game in timely fashion and finishing it at all, but they seem to lack relation of real code to fashion and priorities of coding, have not seen a text saying : you probably better skip dip/state change optimizations, as it provides a huge time sink and will delay your project without giving much in return, as instead, there are a lot of information how dips are root of evil and such :D Also primary focus for most people when concerning code is - FAST! and not fast in sense of development time, but in terms of milliseconds.

Someone really should construct some guidelines for this matter, that are down to earth and based on practical, real world examples and experience. Basically how to write code "fast(development time) and fast(code execution time)", and whats good balance in REAL situations.One way of doing this is to produce some sort of performance impact index, based on some sort of reference processor and gpu, saying - "System to minimize dips/state changes - general guide - Avoid", "Easy to use art-game pipeline - general guide - High Focus" etc
0

Share this post


Link to post
Share on other sites
[quote name='Semei' timestamp='1298638363' post='4778894']
(I) have not seen a text saying : you probably better skip dip/state change optimizations, as it provides a huge time sink and will delay your project without giving much in return.
[/quote]

That's probably because it isn't really true. If you are working on a game as an indie developer and you factor in a system from the start to handle this, it isn't a particularly massive time sink at all. My scene manager took about an hour to code up right at the start of my project and I've barely touched it in the last two years.

As Hodgman says, when working in a large team and when using a third party library for rendering, the task does then become far more complex. Maybe it was cheaper to buy a binaries-only licence for the rendering engine so such optimisations aren't possible? Maybe several developers have argued passionately at meetings to be allowed to perform this optimising but have been vetoed by project managers more concerned about features in time for deadlines? Maybe the business model is based on X percent sales to above and beyond a certain target hardware, making the optimisation useless [i]in this specific business context[/i]?

We simply don't know, but to assume that the developers either 1) didn't know about this or 2) didn't care is unfounded based on the evidence we have.

[quote name='Semei' timestamp='1298638363' post='4778894']
Also primary focus for most people when concerning code is - FAST! and not fast in sense of development time, but in terms of milliseconds.
[/quote]

Disagree. Primary focus is 1) does it work acceptably to return investment and 2) will it be finished in time. Optimising for speed of execution is only necessary, and indeed worthwhile, if either of the two above factors are compromised.
0

Share this post


Link to post
Share on other sites
[quote name='Aardvajk' timestamp='1298640981' post='4778903']
Disagree. Primary focus is 1) does it work acceptably to return investment and 2) will it be finished in time. Optimizing for speed of execution is only necessary, and indeed worthwhile, if either of the two above factors are compromised.
[/quote]

Well, not in indie game development, i don't think that greediness is of primal concern ;D Seems like project managers and publishers are the real root of evil, and yeah, why not, their concern is greed, not game, that's why most games now-days are crap code and fails at gameplay...

[quote name='Aardvajk' timestamp='1298640981' post='4778903']
If you are working on a game as an indie developer and you factor in a system from the start to handle this, it isn't a particularly massive time sink at all. My scene manager took about an hour to code up right at the start of my project and I've barely touched it in the last two years.
[/quote]

This is bull. If that were true for real game projects, then developer would have made it without even asking, hey, its 1 hour, but as you can see - they DIDNT.
Civ5, as far as i know was not outsourced on graphics, and i think that you missed mentioned hex grid drawing system - its implementation is both time consuming and more depending on hardware, so its either pure stupidity, or code management issue, where one developer is given a certain task and hes used to make it as generic as possible and have no clue how game works as a whole. Point to mention that Civ5 developers were kind of bragging about cool features of using DX11 to take advantage of threading to improve performance, so it WAS concern or they pretended it was, to sound more techy and lure some gamers being fanatic about hi-end graphics. I vote for second.
0

Share this post


Link to post
Share on other sites
[quote name='Semei' timestamp='1298644496' post='4778921']
Seems like project managers and publishers are the real root of evil, and yeah, why not, their concern is greed, not game, that's why most games now-days are crap code and fails at gameplay...
[/quote]

Project managers and publishers are the reason that game developers can earn a living, feed their families and keep a roof over their heads while creating the successful games you are criticising.

[quote name='Semei' timestamp='1298644496' post='4778921']
This is bull. If that were true for real game projects, then developer would have made it without even asking, hey, its 1 hour, but as you can see - they DIDNT.
[/quote]

You are missing my point - it was trivial for me because I am a solo developer working without a third party graphics engine and without deadlines. In a larger team with competing priorities, decision about where to invest time is not based on performance but based on shipping a finished product that works [i]well enough[/i].

I don't really understand where you are coming from - all the example games you criticise are commercially successful. They therefore work sufficiently well within their own parameters, so any further optimisation would be worthless.
0

Share this post


Link to post
Share on other sites
[quote name='Aardvajk' timestamp='1298646903' post='4778937']
I don't really understand where you are coming from - all the example games you criticise are commercially successful. They therefore work sufficiently well within their own parameters, so any further optimisation would be worthless.
[/quote]

The whole point of this thread. The misdirected guidance about minimizing state changes and dips, seen everywhere, also lots of developers reading and working their asses off to build it, while the real situation suggests to leave it alone as a general rule. [b]No:[/b] "[i]Batch, batch, batch[/i]". [b]Yes:[/b] "Whatever.", that's the real rule of thumb. Its not [i]good[/i], it [i]works[/i].

I'm primary concerned here of people learning to do stuff and making their way of creating games, and i think that this is mayor aspect, that is taught very wrong and far from reality, so if you are indie/student/hobbyist - this might come to use, as weird as this kind of suggestion might sound.
0

Share this post


Link to post
Share on other sites
[quote name='Semei' timestamp='1298648325' post='4778949']
The whole point of this thread. The misdirected guidance about minimizing state changes and dips, seen everywhere, also lots of developers reading and working their asses off to build it, while the real situation suggests to leave it alone as a general rule. [b]No:[/b] "[i]Batch, batch, batch[/i]". [b]Yes:[/b] "Whatever.", that's the real rule of thumb. Its not [i]good[/i], it [i]works[/i].

I'm primary concerned here of people learning to do stuff and making their way of creating games, and i think that this is mayor aspect, that is taught very wrong and far from reality, so if you are indie/student/hobbyist - this might come to use, as weird as this kind of suggestion might sound.
[/quote]

Sorry, yes, I do see where you are coming from in that case. Certainly far too much emphasis is put on optimisation in a lot of online resources and the phrase "Premature optimisation is the root of all evil" is very common on these forums.

My apologies if I misunderstood you.
0

Share this post


Link to post
Share on other sites
[quote name='Semei' timestamp='1298648325' post='4778949']
The whole point of this thread. The misdirected guidance about minimizing state changes and dips, seen everywhere, also lots of developers reading and working their asses off to build it, while the real situation suggests to leave it alone as a general rule. [b]No:[/b] "[i]Batch, batch, batch[/i]". [b]Yes:[/b] "Whatever.", that's the real rule of thumb. Its not [i]good[/i], it [i]works[/i].

I'm primary concerned here of people learning to do stuff and making their way of creating games, and i think that this is mayor aspect, that is taught very wrong and far from reality, so if you are indie/student/hobbyist - this might come to use, as weird as this kind of suggestion might sound.
[/quote]

The problem is you CANT compare AAA development with hobbiest development.

Yes, you can ignore "batch, batch, batch" IFF you can afford to. Most hobby developments probably can, however if you are planning from the ground up and really plan to push thing then you can't.

So, yes, those games you cited probably could get away with that level of drawing, it was considered 'fast enough' and if anything was probably a victim of game play coders, artist and designers.

In our AAA game we have worked very hard to reduce our draw calls and genereally batch things together because due to design and art issue our scene complexity shot up massively in a short period of time and while our level of batching before was fine for the game one this change kicked in we had to work very hard to reduce them (while swearing at art and design and trying to explain that they can't have the framerate they wanted while pushing that many objects into the world).

So, yes 'batch batch batch' is very important if you need, or indeed want, to push the hardware as best you can.

It's not 'bad' advice, it's just advice which you need to be pragmatic about, much like any advice given.
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By lonewolff
      Hi Guys,
      I am revisiting an old DX11 framework I was creating a while back and am scratching my head with a small issue.
      I am trying to set the pixel shader resources and am getting the following error on every loop.
      As you can see in the below code, I am clearing out the shader resources as per the documentation. (Even going overboard and doing it both sides of the main PSSet call). But I just can't get rid of the error. Which results in the render target not being drawn.
      ID3D11ShaderResourceView* srv = { 0 }; d3dContext->PSSetShaderResources(0, 1, &srv); for (std::vector<RenderTarget>::iterator it = rtVector.begin(); it != rtVector.end(); ++it) { if (it->szName == name) { //std::cout << it->srv <<"\r\n"; d3dContext->PSSetShaderResources(0, 1, &it->srv); break; } } d3dContext->PSSetShaderResources(0, 1, &srv);  
      I am storing the RT's in a vector and setting them by name. I have tested the it->srv and am retrieving a valid pointer.
      At this stage I am out of ideas.
      Any help would be greatly appreciated
       
    • By bowerbirdcn
      hi, guys, how to understand the math used in CDXUTDirectionWidget ::UpdateLightDir 
      the  following code snippet is taken from MS DXTU source code
       
        D3DXMATRIX mInvView;
          D3DXMatrixInverse( &mInvView, NULL, &m_mView );
          mInvView._41 = mInvView._42 = mInvView._43 = 0;
          D3DXMATRIX mLastRotInv;
          D3DXMatrixInverse( &mLastRotInv, NULL, &m_mRotSnapshot );
          D3DXMATRIX mRot = *m_ArcBall.GetRotationMatrix();
          m_mRotSnapshot = mRot;
          // Accumulate the delta of the arcball's rotation in view space.
          // Note that per-frame delta rotations could be problematic over long periods of time.
          m_mRot *= m_mView * mLastRotInv * mRot * mInvView;
          // Since we're accumulating delta rotations, we need to orthonormalize 
          // the matrix to prevent eventual matrix skew
          D3DXVECTOR3* pXBasis = ( D3DXVECTOR3* )&m_mRot._11;
          D3DXVECTOR3* pYBasis = ( D3DXVECTOR3* )&m_mRot._21;
          D3DXVECTOR3* pZBasis = ( D3DXVECTOR3* )&m_mRot._31;
          D3DXVec3Normalize( pXBasis, pXBasis );
          D3DXVec3Cross( pYBasis, pZBasis, pXBasis );
          D3DXVec3Normalize( pYBasis, pYBasis );
          D3DXVec3Cross( pZBasis, pXBasis, pYBasis );
       
       
      https://github.com/Microsoft/DXUT/blob/master/Optional/DXUTcamera.cpp
    • By YixunLiu
      Hi,
      I have a surface mesh and I want to use a cone to cut a hole on the surface mesh.
      Anybody know a fast method to calculate the intersected boundary of these two geometries?
       
      Thanks.
       
      YL
       
    • By hiya83
      Hi, I tried searching for this but either I failed or couldn't find anything. I know there's D11/D12 interop and there are extensions for GL/D11 (though not very efficient). I was wondering if there's any Vulkan/D11 or Vulkan/D12 interop?
      Thanks!
    • By lonewolff
      Hi Guys,
      I am just wondering if it is possible to acquire the address of the backbuffer if an API (based on DX11) only exposes the 'device' and 'context' pointers?
      Any advice would be greatly appreciated
  • Popular Now