Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


d3d12 Features?


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.

  • This topic is locked This topic is locked
20 replies to this topic

#1 Quat   Members   -  Reputation: 413

Like
0Likes
Like

Posted 27 May 2011 - 09:15 AM

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

Sponsor:

#2 Jason Z   Crossbones+   -  Reputation: 5147

Like
0Likes
Like

Posted 27 May 2011 - 10:48 AM

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?

#3 forsandifs   Members   -  Reputation: 154

Like
0Likes
Like

Posted 27 May 2011 - 11:33 AM

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.

#4 phantom   Moderators   -  Reputation: 7388

Like
6Likes
Like

Posted 27 May 2011 - 01:28 PM

classes with methods eh? You mean like this?

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.

So much so that classes and interfaces are recommended to be avoided if you want decent performance.

#5 MJP   Moderators   -  Reputation: 11567

Like
10Likes
Like

Posted 27 May 2011 - 02:37 PM

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.

#6 Jason Z   Crossbones+   -  Reputation: 5147

Like
0Likes
Like

Posted 27 May 2011 - 03:31 PM

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.

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.

#7 forsandifs   Members   -  Reputation: 154

Like
0Likes
Like

Posted 27 May 2011 - 03:44 PM

classes with methods eh? You mean like this?


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.)

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.


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".

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


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.

#8 phantom   Moderators   -  Reputation: 7388

Like
3Likes
Like

Posted 27 May 2011 - 04:10 PM

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.


Not being facetious but, what it usually means?


Properly implies 'correct', so what you are saying is that OOP = correct programming. Which frankly is wrong and a very bad mindset to get into.
(Also, OOP has nothing todo with "class"es either, it's a paradigm is all.)

It's perfectly possible to write clean code without using OOP, you just have to write... clean code.

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".


While they might appear to be globals the 'global' data is more like 'pre thread references' to global data and is nothing more than supplying a thread with a bunch of pointers in C++ and saying "and don't do it wrong." (and this only applies to UAVs you can write).

If your code is spaghetti then that is your doing :)

But it does puzzle me. No one says that OOP necessarily hurts CPU performance, in fact OOP and performance are usually cited as orthogonal?


No, OOP can certainly hurt performance; often the performance loss is acceptable due to the increase of speed of programming. Amusingly graphics programming is one area where a lack of OOP due to an increase in processing and performance is becoming more common.

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

#9 Asesh   Members   -  Reputation: 268

Like
0Likes
Like

Posted 27 May 2011 - 09:07 PM

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

#10 freeworld   Members   -  Reputation: 325

Like
0Likes
Like

Posted 27 May 2011 - 09:14 PM

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


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.
[ dev journal ]
[ current projects' videos ]
[ Zolo Project ]
I'm not mean, I just like to get to the point.

#11 Ibasa   Members   -  Reputation: 183

Like
0Likes
Like

Posted 27 May 2011 - 10:42 PM

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.


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


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.

#12 Jason Z   Crossbones+   -  Reputation: 5147

Like
0Likes
Like

Posted 28 May 2011 - 01:21 AM


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


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.


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 :)

#13 dblack   Members   -  Reputation: 150

Like
0Likes
Like

Posted 28 May 2011 - 01:06 PM

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?



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.

#14 wil_   Members   -  Reputation: 310

Like
-1Likes
Like

Posted 19 September 2014 - 02:26 AM

Here is a recent presentation about D3D12's new rendering features:

 

http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-20-72/8463.Direct3D-12-_2D00_-New-Rendering-Features.pptx



#15 Alessio1989   Members   -  Reputation: 2055

Like
0Likes
Like

Posted 19 September 2014 - 10:10 AM

 

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, 19 September 2014 - 10:13 AM.

"Software does not run in a magical fairy aether powered by the fevered dreams of CS PhDs"


#16 iedoc   Members   -  Reputation: 1040

Like
0Likes
Like

Posted 19 September 2014 - 11:20 AM

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~


Braynzar Soft - DirectX Lessons & Game Programming Resources!

#17 Alessio1989   Members   -  Reputation: 2055

Like
0Likes
Like

Posted 19 September 2014 - 11:45 AM

A new feature level probably will be added since D3D11.3 and D3D12 add some new rendering features...


"Software does not run in a magical fairy aether powered by the fevered dreams of CS PhDs"


#18 DvDmanDT   GDNet+   -  Reputation: 924

Like
0Likes
Like

Posted 19 September 2014 - 11:55 AM

This thread is from 2011. I thought it wasn't even possible to necro threads anymore?



#19 iedoc   Members   -  Reputation: 1040

Like
0Likes
Like

Posted 19 September 2014 - 12:46 PM

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, 19 September 2014 - 12:48 PM.

Braynzar Soft - DirectX Lessons & Game Programming Resources!

#20 Alessio1989   Members   -  Reputation: 2055

Like
1Likes
Like

Posted 19 September 2014 - 03:47 PM

I didn't notice it too ç__ç

 

It's all wil_'s fault! laugh.png


"Software does not run in a magical fairy aether powered by the fevered dreams of CS PhDs"





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