D3D12Pipe now stores an array of root elements, each one corresponding
to a root element or range in the root signature. Migrated usage in the
D3D12 pipeline state viewer and PipeState retrieval of resources.
Restricted number of resource array textures displayed in the texture
viewer to prevent app hangs.
* If we have a merged file with #lines in it, then we want to split those #lines
into separate files as expected. However the original merged file should be
left alone. Previously this happened if the first thing we saw was a #line but
that was only by coincidence. If there was some preamble before the first
#line we'd start copying that and then stop once we started emitting lines
into other files.
* If the application uses internal format GL_RGBA but format GL_BGRA when
uploading with e.g. glTexImage2D, we store an internal format of GL_RGBA and
allocate any needed mips for initial states with an autocalculated format of
GL_RGBA. It's unclear if this is valid or not but it seems to fail on some
drivers, so save the format used (GL_BGRA) and use that.
* This would require proper barriers and special handling for e.g. readback
resources, and the only time we create initial states is when the resource was
created mid-frame (since all pre-frame resources are dirty, so would have
initial states prepared). That means it's zero initialised, so our zero-
initialised created state is fine.
* Even if the vulkan/GL loader wants to unload us the library should stay
resident to provide a persistent connection, as if it were preloaded/injected.
* If we return back (accurate) replaced IDs in current pipeline state, the UI
won't recognise them since the list of resources is cached and fixed at load
time.
* The replaced ID is still present in the shader reflection info as we return
the replaced shader's reflection and not the original's.
* We also change how we replace a programshader (glCreateShaderProgramv) on GL.
Instead of creating a program and a shader - resulting in two objects
replacing one - we instead replace the shader that got built with a program.
We can do this safely since we know the shader won't be used as an actual real
shader (since it was a program in the original capture too).
* Using <Copy> forcibly copied every build which means if the program is running
a build will fail. Using <Content> will only copy if the file doesn't exist
(so after the first build, it won't try to copy and fail).
* This is a very big blunt hammer for fixing the problem of multithreaded
submission from GL. Every GL call checks to see if the context changed (which
would only happen from a thread switch to a different context) and if detected
it inserts a manual MakeCurrent call equivalent.
* It's slow to capture (when this happens - checking is not particularly slow)
and slow to replay, but it's functional which is an improvement.
Renderdoc seems to somewhat require time units to be in float to be
able to present prettyfied results (ms/us/ns).
We were assuming that but a couple of errors slipped in :
* we were asserting that KHR time units are floats
* we didn't describe the renderdoc units as double (even though we
forced the conversion later on)
This is an alternative to
https://github.com/baldurk/renderdoc/pull/1768 suggested by baldurk.
I found that for some reason when cross compiling, the qrenderdoc
CMakeLists.txt was failing to see the include-bin executable that
renderdoc should have built.
Apparently the .py.c files were no longer required for qrenderdoc, so
removing it also fixed the issue I was seeing.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
* The SPIR-V spec doesn't state what will happen, only that it's undefined. For
the sake of something sensible (and because it has a good chance of matching
at least some hardware) we use D3D's behaviour and set the value to 0xFFFFFFFF
baldurk