codedivine
Regular
Just pasting what Max wrote on that forum for easy reference.
Max said:
DirectX 12 API Preview
- Thread starter PeterAce
- Start date
no NDA required for the event; I guess that means they are ready to share the details? Or the event is just going to be more of what we already know.
Interesting regardless, love that the tickets are free. Sweden
ugg, I would consider going if it was held in Toronto , this lands on the same day as WWDC. Pretty intense June 2.Cool stuff Dave. You should live stream it too
codedivine
Regular
Wondering if the slides for the event were posted anywhere?
codedivine
Regular
To answer my own question, slides are now available on AMD's website:
http://developer.amd.com/resources/documentation-articles/conference-presentations/
http://developer.amd.com/resources/documentation-articles/conference-presentations/
That particle system... is almost like a carbon copy of my own design, except that their tiles are quite big (32x32 pixels = 1024 pixels). Small particles suffer with this big tiles. Smaller tiles of course increase the binning cost, but conservative rasterization might be the perfect solution for that problem.
I also like that "vertex shader tricks" presentation... for obvious reasons (until we get multidraw on all rendering APIs).
Last edited by a moderator:
Is your system for screen-aligned rects/billboards as well? Certainly that's a chunk of the overdraw in a scene but there's usually a bunch of effects stuff in most games that use actual geometry as well. Conservative rasterization should help there too, although sorting and interpolation becomes an issue there too of course.
Conservative rasterization allows stretched particles (etc) without hassle. You can even support triangles (store index to triangle buffer). Triangle buffer contains transform to barycentrics that you use for UV interpolation and inside triangle test. 8x8 tile = 64 pixels = single AMD wave.
For conservative rasterization storage you can for example use bucket lists or perfect hash + linear probing. Normal (32 bit) atomic is enough for both, no need for UAV ordering. With UAV ordering you can do of course more complex stuff.
... Cuckoo hashing is also quite good on GPU (especially query, since it's quaranteed O(1) branchless). Inserts are harder, since 32 bit atomics make kicking items out of buckets awkward if payload + hash is larger than 32 bits. I would be happy to get 64 bit atomics (unfortunately most current hardware do not support it, so wide support isn't possible).
Another thing I would like very much is transactional memory for GPU (TSX style). Even a single cache line transaction support would be huge. Lock the cache line in shader (other waves stall for memory operation if they try to access the locked line, GPU latency hiding of course handles this case and runs other waves instead of stalled ones). Commit frees the line. GPU programming model/scheduling should support this with minor changes. To avoid the deadlock case, the shader code shouldn't be allowed to write/read to other cache lines inside the transaction.
Another thing I would like very much is transactional memory for GPU (TSX style). Even a single cache line transaction support would be huge. Lock the cache line in shader (other waves stall for memory operation if they try to access the locked line, GPU latency hiding of course handles this case and runs other waves instead of stalled ones). Commit frees the line. GPU programming model/scheduling should support this with minor changes. To avoid the deadlock case, the shader code shouldn't be allowed to write/read to other cache lines inside the transaction.
D
Deleted member 2197
Guest
Similarly Guru3d also mentions the same Intel demo with Microsoft's DX12.
http://www.guru3d.com/news-story/directx-12-cuts-power-consumption-in-half-and-boosts-fps.html
http://www.guru3d.com/news-story/directx-12-cuts-power-consumption-in-half-and-boosts-fps.html
Andy,
According to the TechReport article on this, you did the presentation at Siggraph. (Congratulations!)
From what little you know about Mantle, can you make a comparison between the two, at least in terms of efficiency improvement? Are there major differences in terms of what an engine developer needs to do or are they at the core pretty similar?
Thanks!
According to the TechReport article on this, you did the presentation at Siggraph. (Congratulations!)
From what little you know about Mantle, can you make a comparison between the two, at least in terms of efficiency improvement? Are there major differences in terms of what an engine developer needs to do or are they at the core pretty similar?
Thanks!
I'm sure this has been covered before but what exactly does it mean when an IHV claims DX12 support with "feature level 11". Does it mean their driver supports the new CPU side APIs and optimizations but hardware supports only DX11 goodies? And how is it different from old school cap bits?
DirectX 11.2 already has some features not supported by DirectX 11.0 hardware (such as tiled resources, min/max blending, etc). I expect these features be supported in the future API as well. Also Microsoft's publicly available slides have mentioned new features such as conservative rasterization, uav ordering and multidraw. It might be that some DirectX 11.0 hardware lacks support for some of these (or some other yet unannounced) new features. It's hard to speculate yet, because the full feature set hasn't been announced.
Actually it's not quite that simple, while GeForces are limited to feature level 11_0, at least Keplers support tiled resources from 11.2 (is there even feature level 11_2? or is 11_1 still the max?)
I think they support a particular level of that? I might be wrong though. Can't say I'm thrilled with the revival of the whole caps bits stuff (in new clothes of course), but I can see why this is happening (unfortunately).
Yes, the "first tier" apparently, while GCN (1.1 only?) should support the "second tier".
It's quite a mess at the moment, when you can support DX11.2 without supporting DX11.1 Feature Level 11_1