* We need the dispatch thread dimension to be valid when creating the
shader reflection data, which may happen before we've disassembled the
bytecode.
* We do a minimal pass just to skip to that opcode and extract the dims.
* Searching down from the end for the next lowest event causes us to
sometimes replay backwards when a marker is selected (and has no
event in the array to replay directly). This can crash on vulkan, and
is unintuitive/wrong on other APIs. Instead we follow the behaviour
that we have elsewhere so that when a marker is selected we move
_forward_ in the frame to select the next event after it.
* Checking the history there doesn't seem to be any strong reason for
this direction of search.
* If we don't consistently use wrapped resources then we could get false
negatives.
* For example, views always constructed with the *unwrapped* object, but
when unbinding a backbuffer before a swapchain resize, we used the
*wrapped* backbuffer texture to search for clashes. This meant some
bindings went un-noticed, and left references dangling.
* In order to be able to split apart and partially replay every render
pass, we change them to always STORE instead of DONT_CARE, and then
create a patched version that only has a single subpass (for each
subpass in the original) and has LOAD/STORE semantics.
* However because of the requirements for framebuffer <-> renderpass
we have to now multiply up the framebuffer to make a patched fb to
correspond to each patched renderpass.
* When a primary command buffer is submitted that contained some
secondary executes, we offset their executes to be 'absolute'
root-relative events so they know when they're being partially
replayed.
* If the same secondary is executed in multiple primaries that are
submitted separately, we don't want to apply the same offset over and
over, instead we mark an execute as updated and only offset 'new'
executions.
This removes dependencies on deprecated tools "ant" and "android project"
The new method relies on JAVA_HOME and ANDROID_SDK being set.
It also requires specific versions of the Android build-tools (26.0.1) and
platforms (android-23). See updates to CONTRIBUTING.md and our Travis-CI
config for details.
Travis-CI and documentation also roll forward to latest public NDK r14b.
* In some cases it seems that no sRGB fbconfigs are available, so we
fall back and create a non-SRGB one. This may render incorrectly but
at least it should run without crashing.
* In particular for e.g. elements that don't require a sampler, the
VkSampler may point to a random address if it's uninitialised, and we
shouldn't try to access it at all.
* Most functions we hook and then jump to the real driver we can fetch
just with dlsym to the library, but the ARB context creation function
is an extension and may not be directly exported.
* It's safe to call glXGetProcAddress(ARB) without a context current
though and it's guaranteed to be directly exported, so we can use this
to fetch the function if we don't find it with dlsym.
* This includes ISG1 and OSG1 chunk types which have an extra enum on
the end for the minimum precision type.
* Also add extra casing for min precision types (although anywhere they
are on an externally-facing interface, they're not actually min
precision).
* It's seemingly possible to bind a structured SRV with no format
given, to a Buffer<float4> declaration in the shader. In this case
we can't get the buffer stride/format type from the SRV itself so we
have to go to what's declared in the reflection data itself.
* The change to make the disassembly view not directly a child of a
DockContent but instead a table layout (to add the disassembly type
drop-down) were causing some casts of 'thing.Parent' to fail.
* The +1 for internal NULL terminator must be done internally, otherwise
we end up with "foobar" being a 7-character string of "foobar\0". If
this is then re-serialised we add more and more null terminators.
* In future we could handle async exceptions by storing the exception
information in a std::function derived object (instead of the separate
ExceptionHandling that lives on the stack) and query it out in a new
WaitForInvoke function maybe. Right now we just print the exception
to the output log and abort the callback.
baldurk