d3d12: Shader image load/store support
I'm marching towards compute and ES3.1 support. It seems this isn't strictly a prereq for compute on ES3.1, but it is for compute on desktop GL, and since ES tests are hard to find on Windows... I figured let's go for it. This turns out to be kinda painful.
Then, several patches to our backend compiler. In theory, it already supports shader image load/store. In practice, the way they're done in CL and Vulkan is different enough from GL that some quirks need to be ironed out. Image atomics also hadn't been implemented yet, and the tests for this feature also exposed a missing early-z flag. Lastly, GL shaders don't use the scoped barriers that we get from SPIR-V (CL/Vulkan), so handle those.
Then, the gallium driver gets its turn. Lots of boilerplate tracking / translation, but some key points:
- Support for typed UAV loads for all GL-required formats is not a given, so we have to check for it. I'm not sure how broad support for this ends up being across the ecosystem. TBD if we could work around this, given the casting restrictions mentioned above.
- Cubemap UAVs aren't a thing in D3D, so we lower them to 2D arrays at a few points.
- The algorithm for translating memory barriers (global barriers) into D3D's per-resource barrier concept is sketchy at best, but does satisfy the
host-memory-barrier
piglit tests. - Format casting requires that the resources be created with the
TYPELESS
variation of formats. Since we don't seem to get aPIPE_BIND_SHADER_IMAGE
flag, this means that all UAV-capable resources get created with theALLOW_UNORDERED_ACCESS
flag and theTYPELESS
format. - The lowering pass for format casting is pretty gnarly, but does seem to work okay, at least for the stores that are tested by piglit.