* What gets listed as a 'drawcall' is a bit fuzzy - previously it was
drawing calls, dispatches and clears, but you could make a good
argument for these to be included as well. As a semi-experiment, these
calls are now included and will be listed in the event browser.
* Other calls can change resources like direct buffer or texture uploads
and Map() type calls, but these remain as API calls listed between
draw calls. Again this is mostly an arbitrary distinction.
* D3D11 logs are backwards compatible, GL logs are not (although it'd
be relatively simple, GL logs will likely break backwards compat soon
anyway, so not worth supporting it now only to break it soon).
* Since RenderDoc is heavily mixed .NET/C++ code, regardless of any
disadvantages this option is practically required (e.g. if building in
profile, the first error message or assert will take the program down
as the breakpoint won't get caught).
* In the UI, enabling this option will always go into csproj.user, but
in fact the option works fine if you manually put it into the csproj,
which means this will be the default for all new clones. Yay!
* Previously for post VS data we could maintain the index buffer by just
doing the stream-out/transform feedback for a point list with each
unique index. To maintain the index buffer we padded out any gaps in
the indices with a single value, so that we could just shift the
indices. This causes severe problems though if the indices start at 0
and contain an invalid value like 0xcccccccc - we'd allocate a huge
array and perform a massively wasteful streamout.
* Instead, we just stream out on the tightly packed list of unique
indices, then remap each 'real' index to where it is in the tightly
packed output buffer.
* This prevents arrays or cubemaps from having the slice or face index
be incorrectly modified by the mip being displayed. Thanks Xavyiy on
twitter for the report.
https://twitter.com/Xavyiy/status/574352181190594560
* When we figure out which event a marker region should jump to if you
select the parent, we want to pick the last valid event ID that isn't
just a label. However previously this was being done by iterating over
the children and picking the last one and assuming there would be a
node of that index - which isn't true in the case where some drawcalls
were entirely omitted. It would either index out of bounds, or index
incorrectly.
* This shader is necessary for the MSAA-to-array copying functionality
used, and without it we bind a NULL vertex shader and can end up with
driver crashes.
* The UAV array is provided as we expect it - with UAVs from 0 onwards
even if their 'slots' are 4, 5, 6 etc or whatever. UAVStartSlot is
the slot of the 0th UAV.
* Also in many places OpenGL is now advertised as full support, since it
is pretty close by now and needs people to jump on it full-time and
use it in anger.
* I doubt anyone will notice the file->open filter unless they look for
it so it's no good for 'discovering' the image viewing capability, but
it might be convenient for people who know about it.
* This means the redeclarations are a bit more flexible if a shader
(like a geometry shader) redeclares one already, but not the other,
we'll only substitute in the missing one.
* Note this code is still a bit flakey e.g. in edge cases like if
someone puts "in gl_PerVertex" in a comment, then it will fail.
I want to avoid putting a full parser in, but perhaps stripping the
source of any comments is a reasonable future step.
* GL doesn't seem to support reading both depth and stencil channels
from a single texture, so we need to do a second pass to read back
the stencil component
* For range maps, similar to glFlushMappedBufferRange, we assume the
user selected the range deliberately and we upload it all. We only
find a difference range for whole-buffer maps (of large enough
buffers). This includes glMapBuffer(), by definition.
* Also, the comparison point is between the map pointer, so we have to
offset the shadow pointer to compare it against to get accurate
results.
* glBufferStorage was less of a problem as it was immutable but the data
that got uploaded was uninitialised memory, it is now filled with 0xdd
* glBufferData could be used to invalidate a whole buffer, by passing
NULL as data for an existing buffer. This caused a mismatch where the
driver could (legally) have the same data, but our serialised copy
was random uninitialised memory. The diff was done against the 'real'
data but on serialise the base data was different, causing invalid
data to be used.
* glBufferData isn't only used for creation, it is often used to upload
new data to a buffer, which means that during the captured frame any
're-create' type calls should go into the context record.
* We need to copy the X display (by fetching its connection string and
calling XOpenDisplay), so that if the Display* we had gets closed then
nothing will crash.
* Also in the HLSL version, we were indexing off the end of an array
since we were drawing 5 lines but only had 4 verts in the array.
Oops!
* We can remove D3D's OutlineStripVB, as we're doing it all in the
shader.
* The unpack parameters are ignored for compressed images unless the
compressed width, height, depth and size parameters are set (whichever
are required for the given unpack param). So we roll this into our
calculation of the fast path, which means that we only use them in
UnpackCompressed if they are valid.
* This can happen when we're copying from a source program to a dest
program where the source is non-separable and had an attribute
optimised out entirely, but the destination is separable and so still
wants that attribute. In this case it'll come out in the wash and
we can just skip it.
* We used to switch to the context that the object was created on and
fetch initial state there, but this isn't safe e.g. the switch
operation could fail if the context was active on another thread.
Instead we queue up such objects to have their data fetched the next
time we see the context made current.
* If we never get the initial state for that object we assume that
context is never used, so it's OK to just not have initial states -
it's marked as invalid so we don't try to restore those states on
replay.
* Note: this obviously falls down in the even that the context is
already current on another thread and we just get commands from there
without an explicit 'MakeCurrent' call. But we already don't handle
that as we don't detect that and log the state change (or properly
handle multithreaded commands), so it's not any worse support.
* Apparently although there are no errors thrown if you pass
GL_ALL_BARRIER_BITS (0xffffffff), if you remove a bit then an error
will be thrown for unrecognised bits :(.
* Since it's not harmful to leave in the mapped buffer bit we just let
it remain.
* We need a context to be current when the frame capture happens so that
we can fetch initial contents and such. This is a hack as there's no
guarantee it's correct or will work, but we temporarily make the last
context that was active on this thread active again, to fetch our
data.
* This could break if that context is active elsewhere, or isn't a valid
context (ie. maybe it was a temporary context used to fetch func
pointers).
* A better fix would be to delay any GL work we need to do until the
next time a good context becomes current, but that becomes dicey in
itself.
* Note that we serialise out the new render state any time we reach a
MakeCurrent call, so we can safely 'skip' the initial render state
at the start of a frame.
* We can't just link ALL programs as separable to be safe, since this
hits the same problem of some shaders not being valid as separable :(.
* This should fix the case where a separable program with initial state
was failing to link before, without breaking non-separable programs.
baldurk