Philip Rebohle

Looks like there are some unused variable warnings from the new tests, other than that LGTM.

Looking into this, the game imports a 16GB (yes, that's right, **giga**bytes) host allocation into D3D12 via `OpenExistingHeapFromAddress`, which subsequently causes queue submissions to be extremely slow in the Linux...

This generally just means that you're running out of VRAM, the fallback mechanism is necessary for games not to crash but **will** cost performance. Whether or not this is expected...

Can you please clarify what you mean by "stops to work" and give us the exact steps required to reproduce that? Building stuff seems to work fine here: 

What are your settings? There's a known GPU hang with upscaling enabled but that might very well be a game bug.

If there is heavy reliance on StructuredBuffer or ByteAddressBuffer loads, this is somewhat expected. There is currently no good way to implement these efficiently in Vulkan for hardware that has...

FWIW the D3D12 renderer of this game is known to be extremely buggy to the point where it's half-broken even on Windows (lots of broken things going on like out-of-bounds...

So what exactly does this actually do with the "DirectX" option? Does this just call GetFrontBufferData on a swap chain before actually rendering the menu or something? GDI is not...

Do whatever you want with it, this is trivial work anyway. Note that this project is not a translation layer, it's just a shim library to make D3D11 applications use...

Debugged this for a bit, this appears to be an inaccuracy with hardware Z interpolation with huge (and I'm talking *insanely* huge) polygons. The game renders a box with post-projection...