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

d3d12 Features?

20 posts in this topic

I haven't found any announcement for d3d12, but I am wondering what new features might come. I'm guessing a version of d3d12 will be used on the next xbox, just like a version of d3d9 is used on the current xbox. What new hardware features would you like to see in d3d12 capable hardware?
0

Share this post


Link to post
Share on other sites
I haven't heard any info either, but I would personally like to see a programmable rasterizer stage. It may be a little far fetched, but it would be cool to be able to programmatically control how a primitive is rasterized, which would open the door for special rendering modes that can be used for hardware based irregular shadow mapping, paraboloid projections, etc... It would be fun to play with, but I doubt that it would be practical due to the parallelization of the current rasterizer.

The other obvious wishes are to have unordered access views accessible to the complete set of programmable stages. I can't think of a use off the top of my head, but it would make a pretty flexible pipeline if you had scatter write access from the complete pipeline.

What are the features that you are looking for?
0

Share this post


Link to post
Share on other sites
I was going to mention wants along the lines of more flexible/general write access and use of buffers but after trying to specify I realised I'm not sure enough of the current limitations to do so. However I can state one specific:

InterlockedAdd() to float types as well as uint and int types.

Also:

HLSL recursion.

HLSL classes, with methods. You gave us programmable shaders. Thank you. Now let us program them properly please.
0

Share this post


Link to post
Share on other sites
[quote name='MJP' timestamp='1306528626' post='4816563']
I'm pretty strongly against the idea of shader languages trying to become more like C++. IMO HLSL and Cg are perfect for their intended use, which is intensely-optimized kernels with lots of heavy math and zero side effects. Once you start throwing in OOP abstractions and start supporting C++ features like operators and constructors you really start to deviate that, and performance can suffer.It's because of this that I have negative opinion of Cuda, which can waste tons of performance just copying data from register to register so that it enforce proper C++ semantics. You can avoid it of course by carefully writing your code, but I would much rather prefer that the language and compiler are tailored towards optimal performance for common GPU workloads.

Recursion is a bit of a similar problem, because it requires GPU shader units to support a legit stack which can cause all kinds of problems with the way GPU's schedule threads and handle divergence.
[/quote]
I can second this opinion - it only takes a moment to remember the drastically different assembly outputs from a minor change to a dynamic loop in SM3.0 and to realize that shaders still need too much fine tuning for high level abstractions. I think eventually it will become feasible, but I don't see it happening any time soon.
0

Share this post


Link to post
Share on other sites
[quote name='phantom' timestamp='1306524533' post='4816544']classes with methods eh? You mean [url="http://msdn.microsoft.com/en-us/library/ff471421%28v=VS.85%29.aspx"]like this[/url]?[/quote]

Right. My bad, I could have sworn I read somewhere, only today before making that post, that there was no such thing in HLSL. :/ Must've been an out of date page, which I can't find now O.o . Thanks for the heads up. (I will need to try some of that stuff out though to understand how it works. For example talking about interfaces and classes on the same page and about how one has to initialize interfaces CPU side confuses me.)

[quote]Also, "program them properly"? What on earth does that mean? Frankly classes are a very poor method to describe shaders which are, at their heart, functional operations.[/quote]

Not being facetious but, what it usually means? If for example you wanted to code a shader that was a lot more involved than what can be adequately described with a few user implemented functions and structures you might wish you could use OOP. Some highly parallelisable physics simulations are a good example of that. One of my shaders right now has, at the moment, though these numbers will increase by a lot as the shader develops, 7 defines, 6 structs, 2 cbuffers, 5 buffers, 1 static array, and 10 functions. I don't know if you think that's a lot for a shader or not, but imo its messy, will get messier, and OOP would help.

Imagine if you were to code something similar in C++ for example and made all of these things globals. Sure it could work, and sure it could be fast, but from what I've seen most developers would strongly recommend OOP, even if only for good practice. This is essentially what I feel I've had to do in my shader due to (I think) not using OOP (but perhaps its only due to inexperience with HLSL?). It basically feels like "spaghetti code".

[quote]So much so that classes ... are recommended to be avoided if you want decent performance.[/quote]

Well that's part of what I would like to see change then. I make no claims to know how that would be done or if its even possible. This topic asked for what we would like to see from future version of DirectX, I don't think it asked only for expert opinions. But it does puzzle me. No one says that OOP necessarily hurts CPU performance, in fact OOP and performance are usually cited as orthogonal? I think I've been told before that its due to different architecture of the CPU and GPU, probably even in this thread, but understanding that is a bit beyond me at the moment.
0

Share this post


Link to post
Share on other sites
The next XBox will use Direct3D 12? I was guessing it will use Direct3D 11. Any info guys?
0

Share this post


Link to post
Share on other sites
[quote name='Asesh' timestamp='1306552038' post='4816654']
The next XBox will use Direct3D 12? I was guessing it will use Direct3D 11. Any info guys?
[/quote]

considering the current consoles still are expected to be the norm for five more years... I don't see why d3d12 or 13 couldn't be possible, other than the fact that nintendo and sony have already announced that they are developing the new consoles already, meaning they are going to be using hardware from now, and not future hardware.
0

Share this post


Link to post
Share on other sites
[quote]Also, "program them properly"? What on earth does that mean? Frankly classes are a very poor method to describe shaders which are, at their heart, functional operations.[/quote]

[quote]
So, in short;
- OOP is not 'correct programming'
- OOP is not right for all situations and shouldn't be applied as such.
[/quote]

Yes on so many levels, OOP has it's uses and you should know but it's not the best way to program everything. For something like shaders functional programming (as a paradigm) is a much better fit.
I highly highly suggest everybody learns a functional language (Haskel, F#, OCaml) it adds a whole new arsenal of tools to your programming mindset even if you never use that actual language again.
0

Share this post


Link to post
Share on other sites
[quote name='freeworld' timestamp='1306552462' post='4816655']
[quote name='Asesh' timestamp='1306552038' post='4816654']
The next XBox will use Direct3D 12? I was guessing it will use Direct3D 11. Any info guys?
[/quote]

considering the current consoles still are expected to be the norm for five more years... I don't see why d3d12 or 13 couldn't be possible, other than the fact that nintendo and sony have already announced that they are developing the new consoles already, meaning they are going to be using hardware from now, and not future hardware.
[/quote]

That's not necessarily true - consoles typically use advanced hardware during development, so there isn't any reason that the next console would use one version over the other. As I mentioned above, there is no information on the topic but I would assume that the PC/XBox similarities (i.e. using Direct3D) will remain in the next generation as well. Of course this only applies to XBox, since I am fairly sure Sony and Nintendo won't be using the Microsoft specific rendering API :)
0

Share this post


Link to post
Share on other sites
[quote name='Quat' timestamp='1306509331' post='4816453']
I haven't found any announcement for d3d12, but I am wondering what new features might come. I'm guessing a version of d3d12 will be used on the next xbox, just like a version of d3d9 is used on the current xbox. What new hardware features would you like to see in d3d12 capable hardware?
[/quote]


Three things I would like to see available in dx12 are:

1) The ability to launch threads from within a shader. This would allow custom rasterization methods, multi level data structure processing etc

2) Proper resource arrays, for example the ability to index into arrays of samplers and textures. (currently texture arrays are limited to groups of identical textures which are allocated in one go, eg I want a texture array with many textures of varying dimensions allocated at different times).

3) The ability to dynamically allocate memory within a shader, even if this is a slow operation(perhaps implimented with an interupt passed to the driver) it would enable dynamically sized data structures. I am under the impression that this is already exposed in CUDA 4 but not D3D.
0

Share this post


Link to post
Share on other sites

 

wait, when they published it??? huh.png

 

volumetric tiled resources Q____Q this give me insane thoughts about how force IHVs to release 384-512 GPUs only laugh.png

Edited by Alessio1989
0

Share this post


Link to post
Share on other sites

The next XBox will use Direct3D 12? I was guessing it will use Direct3D 11. Any info guys?

 

actually, direct3d 12 doesn't need any new hardware from direct3d 11, so as long as the xbox now can support direct3d 11, it can support direct3d 12~

0

Share this post


Link to post
Share on other sites

oh wow! i did not even notice that, haha. i was wondering why someone made a new thread when theres a pretty popular one about pretty much the same thing a couple threads down

Edited by iedoc
0

Share this post


Link to post
Share on other sites

Yeah, I'm gonna lock this since it's 3 years old. Feel free to make a new thread if you'd like to discuss the new features.

0

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0