Your wishlist for DX12

nVidia supports max of 4, not 6.

 

thats why I said up to

 

Well it's used atleast. Much more than can be said for GS (as geometry amplifier) or xbox360.

 

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.

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.

 

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.

 

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.

 

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!

 

And shortly after MS says "Yes there will" http://www.hardwarecanucks.com/news/amd-roy-taylor-directx12/

 

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

 

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

 

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.

 

For all those keen on pursuing the death-of-Microsoft line, there is now a thread dedicated to it: http://forum.beyond3d.com/showthread.php?t=63391. Apologies for the delay in extracting it.

 

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