Apparently RT shaders in RE Engine require min16float to
be implemented as native FP16. Fun ... ._.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
With DXR, it seems like some applications require other FL 12.2 features
to be enabled even if they are not actually used. Various RE engine
titles seem to be affected by this.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
We cannot handle all scenarios if COLLECTIONS are incompatible,
but test the easier cases.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
CP77 relies on this to work somehow ...
The DXR spec seems to suggest this is allowed, but there is no direct
concept for this in Vulkan.
This seems to work on NVIDIA at least, but we're on very shaky ground
here ...
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
The hash should only depend on the raw byte stream, not the entire DXBC
blob. Useful now since we can declare root signatures either through
DXBC blob or as RDAT object (which is raw).
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
To keep things simple, outer code is responsible for keeping string
alive. Intended to be used for RTPSO entry point name debugging.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Handle embedded DXIL subobjects and fix various issues exposed by the
upcoming new tests.
Associating with global root signatures, shader config and pipeline
config needs to be rewritten so that we validate uniqueness late.
The strategy here is to look at all exports we care about and find an
association.
There are many priority levels which are implied by how I understand the
DXR docs. State objects in the API win over embedded DXIL state objects.
Any DXIL state object wins over a collection.
Hit group associations can trump an entry point. It's not entirely clear
how this works, but we let it win if it has higher priority, i.e.
an explicit association directed at the hit group.
There's also cases where explicit assignment trumps explicit default
assignment, which then trumps just declaring a state object.
Collection state is inherited in some cases like AddToStateObject() even
if this seems to be undocumented behavior.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
This is barely implementable, and relies on implementations to do kinda
what we want.
To make this work in practice, we need to allow two pipelines per state
object. One that is created with LIBRARY and one that can be bound. When
incrementing the PSO, we use the LIBRARY one.
It seems to be allowed to create a new library from an old library.
It is more convenient for us if we're allowed to do this, so do this
until we're forced to do otherwise.
DXR 1.1 requires that shader identifiers remain invariant for child
pipelines if the parent pipeline also have them.
Vulkan has no such guarantee, but we can speculate that it works and
validate that identifiers remain invariant. This seems to work fine on
NVIDIA at least ... It probably makes sense that it works for
implementations where pipeline libraries are compiled at that time.
The basic implementation of AddToStateObject() is to consider
the parent pipeline as a COLLECTION pipeline. This composes well and
avoids a lot of extra implementation cruft.
Also adds validation to ensure that COLLECTION global state matches with
other COLLECTION objects and the parent. We will also inherit global
state like root signatures, pipeline config, shader configs etc when
using AddToStateObject().
The tests pass on NVIDIA at least.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Just use VK_NULL_HANDLE. We rely on the disk cache to exist anyways
here. We never serialize the global pipeline cache, so it might just
confuse drivers into disable disk cache if anything.
Also reduce memory bloat.
Also gets rid of very old NV driver workaround where we forced global
pipeline cache.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
We rely on zerovram behavior in drivers. Opt-in to this path where we
know implementation does what we want (backed up by testing).
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
The suballocation test should also try to allocate >= 2 MiB buffers so
we can verify VRAM clear behavior for dedicated allocations as well.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Transfer batches buffers CopyTextureRegion calls for batching.
The flushes needs to happen in a few places:
1. ResourceBarrier: This is where the transition from COPY_DEST to other
might happen, at which point the writes must be visible. This might
also transition away from COPY_SRC which invalidates the
precondition.
2. Copy operations. Copies to the same resource are implicitly ordered.
3. Draws and dispatches. These are not strictly necessary, but we don't
want too much command reordering so flushing here seems good.
4. Close. So that we don't throw commands into the void.
Signed-off-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
A parameter preparation stage, a pre-execution barrier stage, then finally
the execution and post-execution barrier stage.
Signed-off-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
5.3.9.5 in D3D11 spec explicit outlines when we can
cast to R32{U,I,F}. The D3D12 validation layers
seem to have missed this.
Fixes assertions in RADV when running test under debug.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Hans-Kristian Arntzen
Tatsuyuki Ishi
Georg Lehmann