Direct3D feature levels discussion

As far I know for AMD cards every GXF IP iteration represent changes in the ISA (small and big). Graphics IP v9 should be related to Polaris 1x (GCN Gen 4) since IP v8 are Fiji/Tonga/Carrizo etc. If Vega will come with other improvements (like rasterizer improvements), is would be named IP v10 following this logic.
 
Alessio1989 said:
As far I know for AMD cards every GXF IP iteration represent changes in the ISA (small and big). Graphics IP v9 should be related to Polaris 1x (GCN Gen 4) since IP v8 are Fiji/Tonga/Carrizo etc. If Vega will come with other improvements (like rasterizer improvements), is would be named IP v10 following this logic.
Click to expand...
It's not that simple, Polaris was mentioned in old'ish leak already as "GFX IP 8.x" just like Tonga and Fiji, for example. Just because it's "x gen GCN" doesn't mean it's major GFX IP level above "x-1 gen GCN"
 
Kaotik said:
It's not that simple, Polaris was mentioned in old'ish leak already as "GFX IP 8.x" just like Tonga and Fiji, for example. Just because it's "x gen GCN" doesn't mean it's major GFX IP level above "x-1 gen GCN"
Click to expand...
And just to add to that, AMD told me that the ISA for Polaris "did not change" from GCN 3, so it should be identical.
 
Ryan Smith said:
And just to add to that, AMD told me that the ISA for Polaris "did not change" from GCN 3, so it should be identical.
Click to expand...
So GCN Gen 4 its all about backend implementation optimizations and no ISA changes? If it is true, this opens to new possibilities for Vega GPUs. But I would be cautious in hoping for a new rasterizer soon: last time (just before Polaris launch) we asked (as a website) details to AMD about ISA changes and fornt-end rasterizer they didn't answer us at all :(
 
MDolenc said:
Shader Model 6.0
Click to expand...
Thank you. Now the question: how much of this feature could be not really supported by FL 11_1 and FL 11_0 hardware. MSDN states that SM 6.0 support is required now for FL 12_0 conformance, so reading it looks like that older hardware can still support those features.
I also expect more features coming, like better FP16 support and new geometry intrinsics like barycentrics. But there is still time 'till end of 2016 and the public preview :p
 
Last edited:
Great additions. My wish list got significantly shorter. Reduction and prefix-sum intrinsics make it much easier to write optimal code (without the need to micro-optimize for each architecture). Also the code readability is now much better.

I am glad to see ordered atomics:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt733231(v=vs.85).aspx

Now writing any algorithm that requires a global prefix-sum (or stable append) is so much easier.

DX12 is finally catching up with OpenCL 2.0 and CUDA. Now the biggest remaining missing feature is dispatch from compute shader (dynamic parallelism). Hopefully we get it soon.
 
With SM 6.0 and other Direct3D 11.4 / DXGI 1.5 improvements, the Windows 10 anniversary update looks like a full Direct3D 12.1 release, even though it's not marketed as such!

DxCapsView tools from Windows 10 SDK 10.0.14393.33 has not been updated though, so I will make changes to my command-line tool to display the new features; I just need to repair my VC++ 2015 installation first and hopefully it wouldn't require me to wipe the entire Windows 10 partition again....
 
D3D 11.4 was included in a preview SDK update... However, DXGI 1.5 introduce support for HDR presentation as well official unleashed refresh rate for UWP apps (before you have to add some couple of lines manually in your code). D3D12 has also been updated to support SM 6.0.

I still hope SM 6.0 will bring more features, like barycentrics. Do Intel and NVIDIA hardware support barycentrics like AMD GCN? Also the unordered rasterization extension would be sweet seeing supported officially by D3D and by a more wide range of hardware..

EDIT: I saw only now D3D 11.4 has been updated to support HDR too. Sweet.
 
Last edited:
Alessio1989 said:
I still hope SM 6.0 will bring more features, like barycentrics. Do Intel and NVIDIA hardware support barycentrics like AMD GCN?
Click to expand...
+1 for SV_Barycentrics pixel shader input.

On AMD SV_Barycentrics is trivial to implement, as the pixel shader always gets barycentrics as input. Vertex attributes (from LDS) are manually interpolated by pixel shader instructions + barycentrics. IIRC Intel and Nvidia still have fixed function interpolation hardware (AMD also had before GCN), so there is no need to pass barycentrics to pixel shader. I would assume that we'd already got barycentrics support if all DX12 compatible GPUs supported it.
 
Last edited:
BTW: Has the SM 6.0 actually been released yet? I have 14393 update and 14393 SDK. Yet both FXC and compile shader functions in code fail to recognize SM 6.0 targets.
 
MDolenc said:
BTW: Has the SM 6.0 actually been released yet? I have 14393 update and 14393 SDK. Yet both FXC and compile shader functions in code fail to recognize SM 6.0 targets.
Click to expand...

Shader Model 6.0 requires a new compiler which is not yet public. SM6 rest on DXIL (while FXC produce DXBC code) which is based on LLVM IR v3.7. You can ask Microsoft to enter the private beta if you are really interested in the new compiler development: http://forums.directxtech.com/index.php?topic=5717.0
 
Ok so not really public yet. Got it.
Don't have enough time this days for this hobby of mine to actually contribute anything to the beta. :(
 
sebbbi said:
IIRC Intel and Nvidia still have fixed function interpolation hardware (AMD also had before GCN), so there is no need to pass barycentrics to pixel shader. I would assume that we'd already got barycentrics support if all DX12 compatible GPUs supported it.
Click to expand...
Not really, we can easily provide barycentrics (the plane equation is also evaluated in the shader - see 'pln' in Intel spec docs) and I imagine NVIDIA can too. The problem is specifying them in a way that is consistent across implementations even in the presence of different triangle slopes (AMD's flip around as the triangle changes orientation and I imagine that's true for everyone, but inconsistently) and clipping (big barrel of fun!).

If you're only doing something that is symmetric across all three edges (ex. computing distance to edge or similar) it's not a problem. If you're trying to do something like deferred interpolation you at least need a swizzle mask in addition the barycentric values as well. If you're doing anything more complicated it probably won't work consistently.

I'm only guessing that this is the real crux of standardization - I severely doubt there are any hardware issues at this point.

sebbbi said:
I am glad to see ordered atomics:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt733231(v=vs.85).aspx
Click to expand...
Word of warning - these docs probably got posted by accident and are certainly not finalized. Ordered atomics (they are really more fences) as in GCN in particular are something I doubt we can support efficiently, and I certainly haven't heard that NVIDIA can either although I have no firm info on that one.
 
MS claims Redstone will improve a lil D3D12 runtime overhead, though I doubt alone it will impact a lot most of games performance:

Faster D3D12 runtime
  • Draw and Dispatch APIs are up to ~10% faster on CPU. Developers will see this performance gain without any code change.
Click to expand...

Also, this is interesting, but I am not aware about which architectures will benefit most (I only know AMD arch benefits of fast clear filling with 0s or 1s):

Faster memory recycling on certain hardware
  • To initialize a render target or depth buffer, developers can call ID3D12GraphicsCommandList: DiscardResource instead of (sometimes expensive) Clear when developers know that resource will be totally overwritten with draws
Click to expand...

Source: http://forums.directxtech.com/index.php?topic=5734.0
 
You must log in or register to reply here.
Back
Top