• 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
lipsryme

Setting the same texture multiple times - overhead ?

11 posts in this topic

I was thinking...if I were to draw 6 objects in a row.

 

And all those 6 objects use the same diffuse texture.

Would I be wasting performance setting the same texture 6 times, or can the API tell that the exact texture is already set and just ignores it ?

Edited by lipsryme
0

Share this post


Link to post
Share on other sites

It is highly likely that the driver will detect this and no actual sampler binding will take place; in fact this is so basic that re-binding a texture will likely cost close to nothing.

 

The surest way to know this, though, is to profile it.

0

Share this post


Link to post
Share on other sites

It is highly likely that the driver will detect this and no actual sampler binding will take place; in fact this is so basic that re-binding a texture will likely cost close to nothing.

It might not cost you GPU time but it WILL cost you CPU time; due to a lack of redundant state checking on texture bindings for a while on our last game (which was targeting 60fps...) we were losing a lot of CPU time each frame due to repeatedly setting the same texture and taking a trip into the driver.
(We, of course, fixed this... and by 'we' I mean 'me'... ;))

Doing redundant work and hoping the driver will 'sort it out' isn't a good plan at all.
2

Share this post


Link to post
Share on other sites

A debug device should warn you that you're making redundant API calls. It does this by keeping track of the API state and checking if each new state-change is the same or different - but this is just debug behaviour.

 

In non-debug mode, the device has no need to do any kind of redundancy checking, because it's better to assume that the app/game is already filtering out redundant commands.

I don't recall seeing anything like this in D3D11 - is there a specific way to enable these warnings?

0

Share this post


Link to post
Share on other sites
I have never seen this behavior either on a debug device. The only way I have to see the redundant state setting is using PIX which I think is an overlooked resource.

I removed 40 additional states via pix and stepping thru a single frame.

I would love to know how to enable that via the API though
0

Share this post


Link to post
Share on other sites

I don't recall seeing anything like this in D3D11 - is there a specific way to enable these warnings?

In D3D9 you'd use the DirectX control panel to enable the debug device and also turn up the debug output level to max. In GL you'd use gdebugger wink.png

In the D3D10/11 section of that control panel, it allows you to mute warnings regarding "state setting", which might encompass redundant states, but I'm not sure. The message ID list doesn't seem to contain any entries for redundant calls, unless they're reported using the 'info' ID...

Maybe D3D10/11 do filter redundant states internally, or maybe they don't even filter them in debug mode?

1

Share this post


Link to post
Share on other sites

I suspect there is no redundant state monitoring by the D3D11 debug layer - I haven't ever masked out any messages, and I haven't seen any such messages coming through.  With the big emphasis on reducing the overhead of the API, it would be logical if they removed this and left it to PIX/Graphics Debugger functionality to find and eliminate redundant state calls.

 

In addition, even if they did it internally, it still costs some cycles to do the API call since you have to transition from user mode to kernel mode - so it is much better to monitor the state on your application side than it is to leave it to the driver and runtime.

0

Share this post


Link to post
Share on other sites

Some D3D11 functions like CreateBlendState explicitly mention in the documentation that they do detect redundant states for you.

That may be true for an object creation method, especially since the states themselves have a fixed number of permutations that can be created.  But if you try to set the same state 100 times, you still are effectively costing runtime every time you make the call with the same state interface pointer.  So the key to the performance questions are the Set*** calls rather than the Create*** calls.

0

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