Your wishlist for DX12

But doesn't it feel even a little bit wrong also for a PC developer to have a whopping 2048 shader units (Tahiti) idling while you render your shadowmaps (bottlenecked by fixed function triangle setup or rops)? These 2048 shader units would surely be able to cruch a lot of triangle setup math. Or have 16 turbocharged geometry engines (Kepler) idling while you do deferred lighting and post processing?
The ALU's aren't idle. They are probably processing another draw call at the time.
Besides, idle ALUs are better than saturated power hungry ALUs that turn out to be slower.
I am not suggesting going fully sw route. Fixed function is fine for small repeated tasks. But I do not want to have more large scale fixed function units either. The goal must be more programmable/flexible pipeline in the future (not less).
Ah, then we are talking degrees. I am in favor of more programmable pipeline as well. I just want to see more kinds of ff hw than is out there today.
 
The ALU's aren't idle. They are probably processing another draw call at the time.
But that another draw call is using the same shader (kernel), and so it is bottlenecked by the same fixed function units. Console GPUs and many currently installed PC GPUs cannot run multiple kernels simultaneously (and the ability is very limited at best).

The ability to run multiple kernels in parallel was first introduced in Fermi GF-100 (http://www.anandtech.com/show/2849/5). It naturally requires that the kernels do not share (other than read only) resources (for example backbuffer), and it can only take draw calls (kernels) from the command list in the order they are submitted (*). This limits the usability a lot. Kepler's Hyper-Q improved this situation significantly. Kepler can fetch commands from up to 32 GPU command lists. This however doesn't help with graphics rendering, since current DX11 multithreading model is based on a single GPU command list (other threads just render to software command buffers that are submitted to one GPU command list, one after each other). This is one of the things that I hope is improved in DX12, since also AMDs heterogeneous system architecture (HSA) slides are also talking about running multiple contexts/kernels in parallel and feeding GPU by multiple command lists (GPU support will be there for both manufacturers). This is also a great way to reduce compute latency (user can set higher priority for command list that is used for submitting compute work).

(*) APIs do guarantee that your draw calls will be executed in the order they were submitted (result being identical to that order of execution). Since you usually have thousands of draw calls in your shadow map rendering, all tasks you can find to execute in parallel are using the same simple shader and are bottlenecked by same fixed function units.

In future DirectX versions you are likely able to submit alu heavy work to a separate command list and run it in parallel to shadow map rendering (GPU fetching from both comman lists, and doing context switching / shader unit allocation as it best determines). The easiest way to fill all the units all the time would be to process multiple frames simultaneously (added latency). For example you start a frame by rendering your shadow maps (vertex/rop/triangle heavy), and you are simultaneously doing deferred lighting and post processing for your previous frame (alu/tex/bw heavy). That would provide very good hardware utilization, but add half frame of extra latency. Or course if would also be more complex for the programmer to handle (manual load balancing between multiple shaders).

And it all depends also on how well the GPU can split it's resources. Some resources are tied to other resources. For example in Kepler, the geometry units are in the shader multiprocessors. If you need lots of shader multiprocessors for pixel crunching (lighting and post processing), you also occupy the geometry units, and thus they cannot be used simultaneously for another (geometry heavy) kernel.
 
http://forums.create.msdn.com/forums/t/106060.aspx

There's even a question mark over whether D3D11.1 will run on W7 (and Vista, presumably). What are the chances of those OSs running D3D12? If that doesn't happen maybe we can just forget about D3D12 entirely.

How's OpenGL shaping up?... Is it going to catch up? Sorry for another de-rail subject.
 
But that another draw call is using the same shader (kernel), and so it is bottlenecked by the same fixed function units. Console GPUs and many currently installed PC GPUs cannot run multiple kernels simultaneously (and the ability is very limited at best).

The ability to run multiple kernels in parallel was first introduced in Fermi GF-100 (http://www.anandtech.com/show/2849/5). It naturally requires that the kernels do not share (other than read only) resources (for example backbuffer), and it can only take draw calls (kernels) from the command list in the order they are submitted (*). This limits the usability a lot. Kepler's Hyper-Q improved this situation significantly. Kepler can fetch commands from up to 32 GPU command lists. This however doesn't help with graphics rendering, since current DX11 multithreading model is based on a single GPU command list (other threads just render to software command buffers that are submitted to one GPU command list, one after each other). This is one of the things that I hope is improved in DX12, since also AMDs heterogeneous system architecture (HSA) slides are also talking about running multiple contexts/kernels in parallel and feeding GPU by multiple command lists (GPU support will be there for both manufacturers). This is also a great way to reduce compute latency (user can set higher priority for command list that is used for submitting compute work).
I thought that single kernel limit was for compute only. Anyway, GCN/Cayman *look* like they have 2 separate command buffers. It's about time that we get multiple DX command queues though. This should definitely be in DX12.
 
http://forums.create.msdn.com/forums/t/106060.aspx

There's even a question mark over whether D3D11.1 will run on W7 (and Vista, presumably). What are the chances of those OSs running D3D12? If that doesn't happen maybe we can just forget about D3D12 entirely.

How's OpenGL shaping up?... Is it going to catch up? Sorry for another de-rail subject.

My expectation is that DX12 will come after xbox720. Not that it would differ much from DX11, considering the timelines. Win9 perhaps?
 
what about daughter cards for more memory ? I'd love to see a board that would connect to future video cards. DDR 3 is extremely cheap and is pretty fast. Connecting say 16 to 32 gigs of ddr 3 1866 . Each channel should give 15 gigs of bandwidth. So dual channel should be 30gigs and quad would be 60 gigs . That be a nice boost for games and with 16-32 gigs it would fit most games inside of it.

I don't know if this would have to be included in the dx specs .
 
AMD: There Won’t be DirectX 12!
According to AMD’s Roy Taylor in an interview with Heise Online, DirectX 11 won’t have a successor. Here is the google-translated version of the interview in german where Roy says that DirectX 12 won’t see the light of day:


We will put together future Game Bundles top games. We believe this is the right way. But also for the industry, it is an important sign. Because the computer industry has benefited for many years from a continuous renewal of the DirectX interface. A new DirectX has time and again refreshed the industry, new graphics cards need more processors and more RAM. But there is no DirectX come 12th That’s it. As far as we know there are no plans for DirectX 12 If this is not correct and someone wants to correct me – wonderful.
 
But no need to get sidetracked with it. Microsoft doesn't have the kind of clout they used to have with developers, that much is certain. AMD are usually first to move over to the latest DirectX, and if Taylor is saying it probably won't exist we can be pretty sure it doesn't exist right now. At best it's a long way off.

Why shouldn't Microsoft not have the clout they used to? When are you comparing it to?

From where I stand MS should have more influence over the core console market than they ever have. Nintendo's reign with Wii is over and XBox 360 is the best selling console, and most of the best selling console games are also ported to PC where they're usually targeting DirectX. It is possible that PS4 is winning more developer favor now, though.

Sure, there are now also a bunch of games selling for phones and tablets, but I have to ask how much they have diverted the attention of developers mainly targeting console games. Received the attention of, yes, but diverted?

However you may be right considering that these days individual games are more middleware oriented and don't even touch the API as much. So I guess the big question is how much influence MS holds over middleware developers, but given their relevance in the market it should still be sizable.

If there's really no DX12 coming any time soon it could be outright lack of demand for API progress in general, as things got more programmable and more low hanging fruit was plucked that was bound to be a side effect..
 
It is possible that PS4 is winning more developer favor now, though.

And even that isn't going to be a factor to potentially sway developers away from DirectX considering news that it'll be relatively easy to recompile Dx11 code for PS4. I expect almost all major multiplatform game developers (PS4 and Durango) to develop on PC, hence Dx11, as the primary target.

Regards,
SB
 
I'm aware that Taylor talks shit more often than not but I find it *extremely* hard to believe that he's just going to come out and say DX12 doesn't exist if it does. And if it does, it's ridiculous to believe that AMD wouldn't be amongst the first to know.
His comments, and even the use of the term "DX12" demonstrate to me a lack of connection/clue in this case. I wouldn't put much stock into anything he says on the topic...
 
Just to be clear, this is not a MS doom thread. It's a wishlist for Direct3D 12. Let's try this again...
 
Fine, I'm leaving this thread - I simply responded to earlier posts I saw anyway and it carried on from there. Far be it from me to lower the tone of this highly technical thread talking about a fantasy API that will never see fruition.
 
The only things I can really think of maybe are targeting compute better for DX12 development, improving the tessellator to make it more useful perhaps, improvements to support for APUs and perhaps some built in libraries ported from console development on Durango.
 
Just to be clear, this is not a MS doom thread. It's a wishlist for Direct3D 12. Let's try this again...

Just to be clear, this is not a wishlist for Direct3D 12 thread. It's a wishlist for DirectX 12. Let's try this again...

/Davros wants his hardware accelerated audio and real time holophonics
 
If the trend of GPUs becoming more programable, general purpose and less reliant on fixed function hw, continues to be fruitful, then there is no reason for DX to stop at 11, there are a lot of things to be changed to keep moving in that direction.
 
Back
Top