The pkg_config helper for premake was not checking for errors. When it
failed to run, either when it is not installed or the queried package is
not found, a cryptic error message would be printed:
"Error: .../xenia/third_party/premake-core/src/base/string.lua:36: attempt to index a nil value (upvalue 's')"
Fix this by checking the return status when calling pkg-config and
printing a descriptive error message.
Transfers are functional on a D3D12-like level, but need additional work so fallbacks are used when multisampled integer sampled images are not supported, and to eliminate transfers between render targets within Vulkan format compatibility classes by using different views directly.
Edit one of the lanes in this unit-test to be larger than the width of
the element-size to ensure that this case is handled correctly.
It should only mask the lower `log2(32)=5` bits of the input, causing
`33`(`100001`) to be `1`(`000001`).
`vprolvd` is an almost 1:1 analog with this opcode and can be
conditionally emitted when the host supports AVX512{F,VL}.
Altivec docs say that `vrl{bhw}` masks the lower log2(n) bits of the
element-size.
[vprold](https://www.felixcloutier.com/x86/vprold:vprolvd:vprolq:vprolvq)
modulos the shift-value by the element size in bits, which is the same
as masking the lower log2(n) bits. So `vrlw` maps exactly to `vprold`.
Since timer_delete does not clean up already queued signals, signal info
data needs to be retained after timer deletion and object destruction in
order to circumvent use-after-free bugs.
Schedule callbacks whith the only guarantee that they will not be run for
the minimum duration specified. Useful for garbage collecting POSIX
timer_create() signal info data.
- Mainly use `assert`s, since failure is very rare
- Forward failure of `CreateSemaphore` to guests because it is more easy
to trigger with invalid initial parameters.
Timing dependencies in this tests were causing spurious test failures:
- Create and Run Thread
- Test Thread QueueUserCallback
They have been largely replaced by spin waits.
- Never use `cond_.notify_one()` because it may wake a thread that is
unrelated to the signalled wait handle, resulting in a lost wake and
possible deadlock. Wait conditions are to be checked by the threads
themselves.
- Refactor and simplify `WaitMultiple`
