UE5 seems to only set IndexType to != UNKNOWN when querying RTAS sizes.
This contradicts D3D12 docs, but this matches Vulkan behavior, so do the
same thing. Adds a warn when IBO VA is NULL with non-null format to catch app
bugs.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Temporarily abandons the idea to fuse waiters with execution.
For whatever reason, this seemed to cause random flicker in Halo Infinite
with async compute on, and I have failed to figure out exactly why.
By playing around with how commands are fused, the results changed
dramatically, which means I doubt vkd3d-proton was actually at fault
here.
There is some questionable code around UpdateTileMappings in the game
where a COPY queue is used, and it does not seem to synchronize this with other
queues as far as I can tell. It is uncertain at this time if D3D12
requires a tile update to synchronize with *every* queue or just the
queue being submitted to. We assume the latter, as it's the only
behavior that makes sense.
It is possible that submitting waits as they are queued up
affects synchronization between queues in unexpected ways.
When separating out the wait operations, everything appears to work.
It is also simpler code.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes a bug in the logic trying to combine the waits by simplifying the code.
Problem discovered by HK.
Signed-off-by: Derek Lesho <dlesho@codeweavers.com>
Even when misusing the API, S_OK is still returned on native runtimes.
Keep the error log, and add an error report to command allocator release
if there are still pending submissions.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
D3D12 has some unfortunate rules around CommandQueue::Wait().
It's legal to release the fence early, before the fence actually
completes its wait operation.
The behavior on D3D12 is just to release all waiters.
For out of order signal/wait, we hold off submissions,
so we can implement this implicitly through CPU signal to UINT64_MAX
on fence release. If we have submitted a wait which depends on the
fence, it will complete in finite time, so it still works fine.
We cannot release the semaphores early in Vulkan, so we must hold on
to a private reference of the ID3D12Fence object until we have observed
that the wait is complete.
To make this work, we refactor waits to use the vkd3d_queue wait list.
On other submits, we resolve the wait. This is a small optimization
since we don't have to perform dummy submits that only performs the wait.
At that time, we signal a timeline semaphore and queue up a d3d12_fence_dec_ref().
Since we're also adding this system where normal submissions signal
timelines, handle the submission counters more correctly by deferring
the decrements until we have waited for the submission itself.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
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>
It's technically undefined to use NULL UAV counters,
but drivers all implement some form of robust behavior here
when presented with NULL counters, so we'll have to follow suit.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
We have no way of expressing size / alignment requirements to
applications since the API query does not provide us with heap
information. Reuse the fallback path for promoting placed to committed.
Guardians of the Galaxy hits a case where it tries to place 3x
host-visible 3D images in one heap, and they end up overlapping in
memory due to a 16x16x80 3D texture taking up far less space in optimal
tiling compared to linear tiling on AMD.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
For internal debug shaders, it is helpful to ensure in-order logs when
sorted for later inspection.
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>
Hans-Kristian Arntzen
Derek Lesho