* On some GPUs the stencil output comes in all channels, not just green, and
it's unclear if this is legal or not. To be safe just mask out the green we
expect.
* On all APIs structs are aligned up to 16-byte alignment, and on D3D as with
arrays then elements coming after the struct can be packed into the padding
after the last struct element.
* These tests ensure that texture rendering works correctly for all different
types of texture types, and for all formats, across different APIs, including
across a remote-proxy connection.
* We assume that fxc won't output a denormalised float in the bytecode, and this
prevents us from flushing integer inputs to otherwise flushable float-type
operations
* Visual assist comes with a pre-defined interpretation of TEST() for
googletest, which conflicts with ours. We can't seem to override it with a
va_stdafx.h even
* If a buffer has been marked as dirty mid-frame but wasn't dirty at the start
of the frame then it won't have initial contents. We have to treat it as if it
wasn't dirty and fall back to using our existing data for it, assuming that is
a valid way to pre-populate the map's shadow buffer.
* This is better than testing by platform/platform version, because we can check
specifically for extensions and avoid running a test we know will fail because
extensions aren't supported.
* Instead of only doing a very lightweight check to see if the API is available
up-front, we now share the API initialisation among all API tests far enough
to determine availability of extensions, features, etc. Then we can precisely
determine which tests are available and which aren't before running.
* This is primarily around initial states - either a resource which is from a
previous frame and maybe wasn't dirtied and needs initial states created for
it when it's modified mid-frame, or a resource that's created and destroyed
all within one frame.
* We also fix a number of issues that could cause incorrect formats to be
generated.
* Test cases added for D3D11/GL/Vulkan to test different struct types. These
aren't automated at the moment because most of the code they're testing is in
the UI itself.
* We also pick the output pixel in the CBuffer_Zoo tests to ensure the API
agrees with our interpretation of the data.
* Follow-up commit will tidy D3D cbuffer code that needs it.
* This is the only way in GL to do rendering from one mip to another. We handle
it and display the whole texture even if it's temporarily constricted, and
display the mip state in the pipeline viewer.
* If the mip state is constricted at the start of the frame capture, only mips
0..MAX will be visible at all and other mips will be assumed to not be valid.
* Where available - on Win8+ basically. On win7 the video doesn't play (but most
of the demo also doesn't work, so that's not much change).
* Added a short 10kb clip from Caminandes (http://www.caminandes.com/sharing)
baldurk