In my winelib builds, I get unresolved dxvk::D3D11ImmediateContext::MinFlushIntervalUs symbol. I'm not sure why it doesn't inline this constexpr, but it doesn't seem useful to expose that in header anyway.
Wine needs to setup each thread that has an access to Windows APIs. It means that in winelib builds, we can't let standard C++ library create threads and need to use Wine for that instead. I wrote a thin wrapper around Windows thread functions so that the rest of code just has to use new dxvk::thread class instead of std::thread.
std::wstring is problematic, because wchar_t on other platforms might not be what we need. -fshort-wchar can mitigate that partially, but it's more problematic for stdc++ classes.
Also, using UTF-8 for convertion may not be what's intended, esp. if such strings end up being passed back to system API (eg. open file). The patch uses CP_ACP on mingw build (which is how Windows APIs will interpret it) or CP_UNIXCP on Wine (which is Wine extension to convert to whatever glibc and other host libs expect).
It's also needed for the next patch.
According to the meson documentation, vcs commands need to be a part
of the command string list. Right now, it pulls the version number no
matter what.
In some situations, calling Flush without any commands that
could be flushed would unnecessarily prevent the implicit
flush heuristic from kicking in properly.
Apparently we need those to make sure that the initial layout
transition itself is valid. We don't need to add shader access
though, since we cannot access attachments inside shaders.
Fixes validation errors and some unnecessary cruft. We don't need
visibility operations in the external-to-renderpass dependency
because that part is handled by regular barriers, an execution
dependency is enough (but still required to handle write-after-read.
If a game clears the depth and stencil aspects of a depth-stencil
buffer separately, we must not override the load op and clear value
of the previously set aspect. Fixes a rendering issue in Hitman
Absolution.
Render target views and shader resource views can only be created
with a format that is within the same format family as the image
format. For UAVs, the restrictions are relaxed.
Some operations can operate on only one of the two aspects
of a depth-stencil image. This fixes two possible issues:
- Image memory barriers must be applied to all image aspects
- VK_IMAGE_LAYOUT_UNDEFINED is no longer used as a source layout
if the operation requiring the transition only uses one aspect
