Your wishlist for DX12

Discussion in 'Rendering Technology and APIs' started by Infinisearch, Jul 15, 2012.

  1. Kaotik

    Kaotik Drunk Member
    Legend

    Joined:
    Apr 16, 2003
    Messages:
    8,874
    Likes Received:
    2,809
    Location:
    Finland
    nVidia supports max of 4, not 6.
     
  2. Davros

    Legend

    Joined:
    Jun 7, 2004
    Messages:
    15,720
    Likes Received:
    2,859
    thats why I said up to ;)
     
  3. rpg.314

    Veteran

    Joined:
    Jul 21, 2008
    Messages:
    4,298
    Likes Received:
    0
    Location:
    /
    Well it's used atleast. Much more than can be said for GS (as geometry amplifier) or xbox360.
     
  4. rpg.314

    Veteran

    Joined:
    Jul 21, 2008
    Messages:
    4,298
    Likes Received:
    0
    Location:
    /
    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.
     
  5. sebbbi

    Veteran

    Joined:
    Nov 14, 2007
    Messages:
    2,924
    Likes Received:
    5,293
    Location:
    Helsinki, Finland
    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.
     
  6. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    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.
     
  7. rpg.314

    Veteran

    Joined:
    Jul 21, 2008
    Messages:
    4,298
    Likes Received:
    0
    Location:
    /
    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.
     
  8. rpg.314

    Veteran

    Joined:
    Jul 21, 2008
    Messages:
    4,298
    Likes Received:
    0
    Location:
    /
    My expectation is that DX12 will come after xbox720. Not that it would differ much from DX11, considering the timelines. Win9 perhaps?
     
  9. eastmen

    Legend Subscriber

    Joined:
    Mar 17, 2008
    Messages:
    10,341
    Likes Received:
    1,758
    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 .
     
  10. fellix

    fellix Hey, You!
    Veteran

    Joined:
    Dec 4, 2004
    Messages:
    3,505
    Likes Received:
    424
    Location:
    Varna, Bulgaria
    AMD: There Won’t be DirectX 12!
     
  11. Kaotik

    Kaotik Drunk Member
    Legend

    Joined:
    Apr 16, 2003
    Messages:
    8,874
    Likes Received:
    2,809
    Location:
    Finland
  12. Exophase

    Veteran

    Joined:
    Mar 25, 2010
    Messages:
    2,406
    Likes Received:
    430
    Location:
    Cleveland, OH
    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..
     
  13. Silent_Buddha

    Legend

    Joined:
    Mar 13, 2007
    Messages:
    16,987
    Likes Received:
    6,237
    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
     
  14. Andrew Lauritzen

    Moderator Veteran

    Joined:
    May 21, 2004
    Messages:
    2,526
    Likes Received:
    454
    Location:
    British Columbia, Canada
    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...
     
  15. willardjuice

    willardjuice super willyjuice
    Moderator Veteran Alpha

    Joined:
    May 14, 2005
    Messages:
    1,385
    Likes Received:
    299
    Location:
    NY
    Just to be clear, this is not a MS doom thread. It's a wishlist for Direct3D 12. Let's try this again...
     
  16. jimbo75

    Veteran

    Joined:
    Jan 17, 2010
    Messages:
    1,211
    Likes Received:
    0
    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.
     
  17. AlexV

    AlexV Heteroscedasticitate
    Moderator Veteran

    Joined:
    Mar 15, 2005
    Messages:
    2,528
    Likes Received:
    107
  18. Squilliam

    Squilliam Beyond3d isn't defined yet
    Veteran

    Joined:
    Jan 11, 2008
    Messages:
    3,495
    Likes Received:
    114
    Location:
    New Zealand
    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.
     
  19. Davros

    Legend

    Joined:
    Jun 7, 2004
    Messages:
    15,720
    Likes Received:
    2,859
    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
     
  20. milk

    milk Like Verified
    Veteran Regular

    Joined:
    Jun 6, 2012
    Messages:
    3,354
    Likes Received:
    3,161
    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.
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...