* This requires setting vmaBDA to true, which is opt-in as it applies
universally to all memory allocations in the test. We don't know if there are
driver impacts from enabling BDA and it may also mess with our tests.
* Apparently the spec allows drivers to do extremely stupid things with
swapchain images and return them even when it's not valid for you to use them
yet because last frame's work to the image is still ongoing, which leads to a
validation warning about using a semaphore when it might technically still be
in flight.
* To get around this because AcquireNextImage doesn't actually block until an
image is ready inspite of having a timeout and being expected to return a
usable image it doesn't, we use a manual fence to do what AcquireNextImage
should be doing.
Highlight that the SSA value used as the phi result is captured from the block branched from, not the SSA value in the current block
i.e.
_label7: // preceded by _label9, _label6
float _375 = phi float [ _label9::_404, _label9 ], [ 1.00000, _label6 ];
float _376 = phi float [ _label9::_375, _label9 ], [ 1.00000, _label6 ];
Step over nop instructions when entering a function
Step over nop instructions after a simulation step
Changed ThreadsAreConverged() -> ThreadsAreDiverged()
Current implementation of ThreadsAreConverged()
* must be in the same basic block
* must be on the same active instruction
Assert that the threads are converged in:
* sampling operations that use derivatives
* derivative instructions
* sync thread group
For all active threads: skip over nop instructions and update the active instruction index
For all active threads execute a single instruction (guaranteed not to be a nop instruction)
* If we don't call SubAlloc (which will consume the whole resource) then it is
pushed into the same free list as is used to allocate non-dedicated buffers
from.
* If we have a config, enabling the debug layer will fail gracefully if we don't
have a ID3D12Debug. This allows overridden D3D12 dll folders to use validation
even if the capture doesn't include a validation DLL.
* This doesn't seem to be documented anywhere but some applications rely on it
and it seems like PIX behaves this way, so it is as with many things in D3D
the defacto standard
Destination copy buffer was sized to the number of events, this did not guarantee enough storage for the per fragment data i.e. small number of events with large of fragments per event
Reserve space for at least 256 fragments or 128 events in the buffer
Do not get data for fragments if the buffer does not have enough space
In the problem case the buffer went from 4KB to 28KB
Jake Turner