* This allows better identification of a shader from its reflection
bundle. The entry point was already 'optionally' in the debug info
struct which is no longer a great location for it.
* For APIs where the entry point isn't contractual and it might not be
listed, instead we just fall back to 'main'. This means that the UI
or anyone fetching the info can be guaranteed that some sensible entry
point will be listed.
* Also for the debug info, remove the 'entryFile' index and instead just
guarantee that as much as possible the entry point will be in the
first file in the list.
* Things like addressing modes, stencil operations, and other things the
UI didn't need to know about previously were only exposed as string
values to be passed through and displayed.
* Now we describe these with enums so the API can be properly
introspected and used by consumers that might want to know the actual
values of these states.
- Added the ability to select an external SPIR-V disassembler and to use
it for editing any of the shaders in the pipeline.
Tested with SPIRV-Cross (https://github.com/KhronosGroup/SPIRV-Cross)
Fragment, Vertex, Geometry, Compute shaders
* The exact contents depend on the API - on D3D11 this is the bytecode
blob, on Vulkan it's the SPIR-V. On OpenGL it is just a concatenation
of all the source files passed in sequence.
* In a couple of places I had to resort to if(IsHighContrast) but mostly
this is just using system brushes consistently or not assuming black
text.
* The default DockPanel theme doesn't work well, so make a minimal high-
contrast theme for it and assign it everywhere.
* The pipeline flow was using fixed colours, use system brushes for the
different elements and switch based on high-contrast to ensure active
and inactive stages are visible (using ActiveCaption looks bad on
normal themes because it's a big block of colour).
* For some reason the flat toolstrip renderer doesn't handle white-on-
black themes, but the system one does. It's a little clunkier but it
shows up correctly without writing tons of custom painting code.
* Range histogram uses a properly contrasting colour for the border.
* Treelist views use a better system colour for selected rows when
inactive and hovered rows (when high contrast).
* Mesh view grids have a system background instead of white
* Various things (pipeline state, mesh viewe) set text colour when
colourising backgrounds of things instead of assuming black.
* For D3D11 and Vulkan, any views which don't just map to the whole
buffer or image will be highlighted in a colour, and when mousing over
that row a small tooltip will be displayed with the view parameters
that differ.
* Since the Vulkan views are tighter and more strictly specified, we can
always safely use the view format (in the non-mutable case it must
exactly match the underlying resource's format).
* Currently at least glslang doesn't emit OpSource with source data
embedded, so we don't pull it out and for the moment we just pre-fill
the shader editor with the disassembly text (which is sort of but not
really GLSL) as a better-than-nothing default.
* This will handle the new vulkan binding model with multiple descriptor
sets and arrays of objects in each binding. It also makes a few tidy
ups and improvements to other APIs in presentation - will e.g. now
show thumbnails for vertex and other stages.
baldurk