Direct3D feature levels discussion

ARK: Survival Evolved hoping for DX12 support this summer ...

http://steamcommunity.com/app/346110/discussions/0/613957600545694189/

 

Little OT: https://i.imgflip.com/mmqub.jpg

 

Thank you, so basically tier 1 and 2(maybe - forgot) doesn't support "true" bindless and is emulated by the driver.

 

It's not emulated, tier1 and tier2 limitations must be manually managed by the application.

 

That's not true. Particularly stuff like resource binding (and bindless) is only exposed in D3D12 and has no equivalent in 11.3.

There have actually been optional capabilities in every version of DX, but I agree they swung back in that direction a bit with 11.1.

The alternative isn't any more manageable - you need the latest OS *and* the latest hardware to use a new API. Then developers would just ignore the new APIs until 5+ years after they ship, like they do with CPU ISAs. DX already takes flak about not having extensions for the bleeding edge stuff, so I doubt this would be acceptable to anyone.

Partially the system was "simple" before because everything always starts simple. It's fairly unavoidable that when you actually build up a few years of legacy hardware and software it's going to get somewhat more complex. I don't see a clearly better way for it to be handled than what DX is doing, although it would be much nicer if feature levels just had unrelated names.

"Emulate" and "true" bindless are the wrong ways to think about it. On any DX12 compatible hardware you can dynamically index portions of the descriptor heap. On lower resource binding tiers these ranges are fairly small (~128 resources) so you still need to move around descriptor tables. On higher resource tiers you can dynamically index the entire heap (~1 million resources) so you no longer need multiple descriptor tables - you can just have a single one that has a view of the entire heap. This is generally good for driver efficiency but more importantly it is required for global scene access (deferred texturing, ray tracing, etc) as you don't know up front which textures you may need to access.

 

So in plain english and for sillies as myself.

DX11, use a lot of trains with one engine and one car.
DX12 tiers 1 and 2, use much less trains, with one engine and some or some more cars.
And DX12 tier 3 use one train with one engine and as many cars as needed.

 

I don't agree. We can aim a little higher than the status quo.

I think your idea about separating feature level names and DirectX is a good start. I know this makes marketing (stickers on a box) harder, but I think each version of DirectX (e.g. 11, 11.1, 11.2, 11.3, 12, etc.) should have their own set of feature levels (e.g. feature level 1, 2, 3, etc.). While this may create many duplicate feature levels (it would be possible that feature level 1 in DX11 is the same as DX11.1), it would make the question "Does this gpu support DirectX 12" a simple yes or no question (no ambiguity with feature levels). It would make clear to users that they really want to be asking two questions: "Does this gpu support DirectX 12 (the software end) and if so what feature level (the hardware end)".

It would also allow you to more or less retroactively add, make optional, or remove features in a straight forward matter. Maybe you decided feature level 2 in DX11.1 had silly requirements that you could correct in DX11.2. Can you imagine the confusion if MS decided Kepler was a feature level 11_1 gpu in DX11.2 but not DX11.1/11.0? With this system they could make those changes without vast confusion. You could change how gpus are grouped together whenever and however you wanted.

Finally this may be the most controversial aspect but I think each version of DirectX should be set in stone. Want to add optional features or new feature levels? Create a new version of DirectX. I'm aware I haven't really thought this through, but I think part of the current problem is DirectX feels like it's a moving target. Having set apis would keep things crystal clear at any point in the life cycle (and on any platform). While I appreciate MS's effort to back port as much of DirectX as they can, I think ultimately ideas like the platform update for Windows 7 were mistakes (caused great confusion). I don't like how there's various optional features depending on what operating system (or worse Windows update) a user has installed. It's much easier checking if a whole api exists or not. And since we're setting the api in stone, I also think each api should contain a "maxed out" feature level (all optional features, formats, and tiers are supported at the highest level). That will allow developers to "future proof" their renderers more easily while also putting pressure on IHVs to adopt new features faster (who doesn't want a DirectX 12 feature level 5 card!?!). I don't think currently there's much pressure on IHVs to support some of these higher tiers that aren't feature level requirements.

Hopefully this system eliminates more confusion than it adds.

 

I'll review my DX12 resource binding "stuff" and see if I can see why you say its the wrong way to think about it. If not I'll be back with more questions. Thanks.

 

Also 11.3 is lacking ExecuteIndirect, async copy and async compute. I would assume it is also lacking GPU buffer predicates (skip commands based on a GPU buffer value).

Unfortunately DirectX had to introduce descriptor heaps. On a pure bindless hardware such as GCN, resource descriptors can be stored and loaded from anywhere (by a standard memory load/store). You could even create a resource descriptor by shader code (by scalar unit integer bit operations to a SGPR). DirectX and OpenGL bindless resources are a bit less powerful, as these APIs are designed to meet the hardware limitations of GPUs that are not pure bindless.

Deferred texturing can be achieved by tiled resources (or with software virtual texturing). I would say that these alternatives are better for deferred texturing, but my reasoning is based on the current GPU implementations of bindless in cases where threads inside a single wave/warp access more than one resource (resource descriptor is not wave/warp invariant).

 

I would assume that you're talking about what is possible on consoles, and probably exposed by Mantle as well. But what about Vulkan?

 

I like how UAV-only rendering is a "gaming" feature, but UAV's for all shader stages is somehow a "non-gaming" feature.

 

I also wonder, why Microsoft didn't add a cap-bit to expose 64 slots and UAV for all sahders for what that was like... 50% of the GPU market?

Two logical possibilities:

1) Fermi and Kepler fails to manage the UAV "revision" introduced with D3D 11.1
2) Microsoft was just evil or the very rich AMD bribed their monkey dancing CEO

What's that?

 

A wireframe rendering mode dedicated to Minecraft, perhaps?

 

Yes and I'm surprised they didn't go this route in Mantle, but I would actually disagree with the notion that this represents the clear trend in hardware design. If you want to pass the full descriptor data to samplers then you need very wide SIMD to amortize the cost. GCN obviously has wide SIMD, but that's a fundamental architecture tradeoff that has as many negatives as positives, and I believe GCN is the only architecture that works that way.

Fundamentally the data-paths between the execution units and samplers do have to handle a lot of bandwidth already and "compression" of the data passed between these two is highly desirable. In this case, the compression takes the form of passing an offset/index instead of the full descriptor data (usually ~128-256 bit) or even a 64-bit pointer. While it's convenient from a programming standpoint to have "just data" and "just pointers", I don't necessarily buy the argument that in this particular case it's functionally important enough to scatter descriptors around memory that it's worth constraining hardware designs or hampering performance for.

Like I said, it's clearly useful to index a large set of descriptors and most hardware can support that without too much overhead. The cost/benefit ratio of putting descriptor data in non-continuous memory is far less clear.

It's almost always better to pack things into atlases/texture arrays where possible, and indeed this is precisely for the reasons I outlined above - it's data compression You're using fewer bits by just adding some address range to one texture than creating entirely new descriptors.

 

Yeah it's completely arbitrary what they put in those two lists... or more realistically they made lists based on what their hardware can/can't do and labeled one "gaming" to save face

 

Almost deja vu ... I guess Hallock's recent comments should be taken with a grain of salt.

http://www.computerbase.de/2015-06/directx-12-amd-radeon-feature-level-12-0-gcn/