* It's possible for two threads to hit GetProcAddress on the same module at
once, try to late-fetch the ordinals, and clash. If we lock then only one
thread will perform the fetch, the other thread can wait and bail out once it
finds the ordinals already filled out.
* The WrappedOpenGL constructor may run too early, before capture options are
properly processed. So we re-process them when and if the API is properly
initialised.
* Instead of calculating the mesh output size exponentially by continuously
doubling, we instead double up to a reasonable size (256MB) and then just
allocate only enough to cover what we need after that point. This avoids
getting into the situation where a mesh needs 1.04GB of data and we allocate a
2GB buffer - which may then fail.
Replace call to SHCreateDirectoyExW on the win32 platform with multiple
calls to CreateDirectoryW to avoid deadlock within CoUninitialize which
is called from SHCreateDirectoyExW. MSDN states that calling
CoInitialize during DllMain is prohibited. SHCreateDirectoyExW
internally calls CoInitialize, thus calling SHCreateDirectoyExW inside
the DllMain is prohibited as well.
* This isn't a real bug, it only happens temporarily during first show of a
window while the geometry is all messed up, but it causes some error spam in
the log so it's better to fix.
* This resource will fail when passed to any other function, so since we don't
support tiled resources currently on D3D12 just print a stronger error and
return an error.
* This prevents us from accidentally unwrapping at List2 level when List2 might
not be available, and we only need List.
* If we need higher list levels we can unwrap explicitly, and it's clearer that
it needs an availability check.
* Instead of just configuring SPIR-V disassemblers and picking only the first
one when we need to edit SPIR-V, we allow setting up any shader processor that
goes between two shader encodings.
* When editing, the default will still be to use embedded source, and then after
that the first tool that goes from the native shader format to a text format,
but the drop-down allows you to pick any of them.
* Similarly in the shader viewer you can configure the compilation options and
method, to choose the compiler you want to use. Embedded command line
parameters in the shader are automatically appended.
* This means e.g. the D3D11 back-end can accept DXBC directly if the UI can
provide it, or compile from HLSL as before.
* More importantly, the Vulkan back-end can take SPIR-V compiled from any
source, or compile from GLSL as before as a fall-back.
* This will allow the backend to specify both the native format (e.g. SPIR-V,
DXBC) as well as a language it might be able to internally compile (GLSL or
HLSL).
* The caller will then able to decide for itself whether it wants to compile to
native format and pass that down, or pass the language down and let it be
built internally.
* Currently BuildTargetShader still only accepts shader source.
* For DXBC files, we decode the D3DCOMPILE flags back into fxc parameters, and
vice-versa.
* For SPIR-V, glslang will embed command line parameters as OpModuleProcessed
strings or opcodes.
* This is stored as a "@cmdline" shader compile flag.
baldurk