* We can load up the msdia140.dll manually and initialise it that way even if
it's not registered properly. That does mean we need to locate the DLL on our
own though - we try in PATH and in a few default paths, and otherwise prompt
the user for it (and save the path in our config).
* 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.
baldurk