Include the discarded offset when indexing to get the post mod data per fragment
Do not include the discarded offset when indexing to get the primitive ID per fragment (primitive ID uses a replacement shader which is not affected by discards in the original shader)
Store the post mod depth data in slot 1 of the depth output to make the indexing simpler to keep track of discarded fragments
Set the post mod data for discarded fragments (excluding the final fragment) to be the known texture after (which starts as the pre mod data and is updated for non-discarded fragments).
Instead of GPUVendorFromPCIVendor() which returns Unknown for the llvm_pipe driver.
This then prevents being able to force replay to run on llvm_pipe when opening a capture.
- .cache/: generated by clangd
- compile_commands.json: usually generated by vscode or build system
- .vsocde: generated by vscode
`compile_commands.json` and `.vscode` are usually specific to a person's
environment, not configurable in any way, so there is no reason to put
them in the git repository at all.
Previously the code was using the original ID to look for the texture in m_pDriver->m_Textures which would create a default entry if the ID was not found leading to numSlices = 0 and then the pipeline state resource tooltip would show "covers slices 0-4294967294"
The save capture modal message box could process messages which could delete a LiveCapture, the pointer had already been copied into a local list, then try to use deleted memory.
Before, if a row was selected, the color was completely replaced, which
makes the color preview column completely useless for that row.
This change also fixes some inconsistencies with how the selection hover
works on tree widgets; previously part of the row was not highlighted.
Before, the buffer could be overrun, which could result in anything from
garbage data to the GPU device being lost to segfaults. Now, correct
data is gathered.
We can't know in advance how many primitives will hit the targetted
pixel, so it's not possible to create the buffer until after our first
pass for each events (fortunately we do know the number of events in
advance). It is possible that we don't need a larger buffer, though,
in which case the original one can be re-used.
* If we select an event we will refresh the overlay before saving the pipeline
state meaning before the cache is updated. This might cause us to render the
overlay to a stale texture.
* We often create stream readers or writers directly on the result of a fopen,
and we want them to be 'safe' to use (marked as errored, but not crashing).
Ideally would use "retain" but that would require upgrading to recent compilers in CI and the project.
__attribute__((retain)) function/variable to prevent linker garbage
collection.
* Previously we were obtaining the image layout from before the current command
buffer was recorded, but this is out of date if the image layout has changed
during the command buffer. Worst case it could be e.g. UNDEFINED if the image
was created and not used until the current command buffer.
* If the remote host disconnects during the selection process we will no longer
have a valid connection, we shouldn't sanitise the resulting path according to
local filenames.
Jake Turner