* VULKAN_LAYER_FOLDER points outside the prefix to /etc in absolute, so
usually if you customise one you'll want to customise the other.
* This is especially true if you're pointing the install prefix at some
non-root location, and you want make install to succeed instead of
failing to write to /etc.
* If there's a variable which is unused and has no binding declared, it
will be sorted to the end of the list and given a binding of 0. We
don't want to let this override a valid binding for 0, so make sure we
prioritise any variable which is marked as used over one that is
unused.
Before this, when binding multiple sets that use dynamic offsets, the
wrong offsets would be stored for all sets other than the first. This
caused the wrong offsets to be used when replaying individual draws.
* 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.
baldurk