* This will enable the last few python list emulation functions, like
index (which needs operator== to find objects) and sort (which
obviously needs operator< to sort).
* This is to support python bindings - the pyside implementation of
QVector, QString, etc is not available to SWIG, so SWIG treates these
all as opaque types.
* Rather than trying to set up bindings that work for rdcarray and
QList/QVector, or implementing separate bindings, we instead just say
that the public interface must use the rdc types. In most cases they
seamlessly convert to/from Qt types anyway.
* In a couple of places we use an array of pairs instead of a map. In
future we probably want an rdcdict or rdcmap with proper dict bindings
in python.
* Previously we'd cache a copy of each command buffer at load time, and
submit it any time we're not partially re-recording. This has a couple
of drawbacks though:
- Technically we do some things that invalidate those command buffers,
like updating descriptor sets (with initial state application) and
so for 100% correctness we'd need to re-record.
- It also means that any edits we apply, like modified shaders, don't
properly apply to the whole frame, they only apply to whichever
command buffer is currently being partially recorded.
* We refactor out the 're-record all commands' behaviour previously
reserved just for applying GPU counters, and use that for re-recording
any command buffers that are wholly or partially submitted. Note that
it's still true that only one primary and one secondary at most are
actually *partially* re-recorded. The others are re-recorded in their
entirety.
* We almost always mean DXGI_FORMAT_R10G10B10A2_UNORM instead and the
xr bias format is rarely used (so unlikely to be the right
interpretation) and might not work at all.
* Technically the resolve doesn't allow format conversion at all, so
instead of resolving directly to the swapchain image we need a middle-
man image of the same format as we use internally for the MSAA target
(RGBA8_SRGB) to resolve to, then blit from that to the actual
backbuffer.
* Historically a long time ago, resources created in the middle of a
frame capture were then replayed with their creation/destruction each
time the frame was replayed. Likewise resources destroyed before the
frame (but kept alive for a dependency) were also released on replay.
* This was faithful but unnecessary. Now we just create all resources
needed anywhere in the frame up front, and release them only on
shutdown.
* On the immediate context after an ExecuteCommandList we were properly
restoring the state if specified, but if the state isn't to be
restored it must be cleared - otherwise we incorrectly inherit state
from the deferred context.
* ARB_texture_view only works on textures allocated with
ARB_texture_storage so we have to check for both extensions and then
use texture storage to allocate space for the destination array
texture.
* This means we don't have a lingering size >0 for an array that won't
be used for NULL. Mostly on read this is immaterial but on write it
is significant.
* This is a *very* light-touch analytics system that will track the
simplest and most anonymous statistics that can be useful in
determining which features are most used or perhaps underused, and
where it's best to direct development attention.
* It is entirely implemented in the UI layer, no analytics-gathering
code exists in the library that's injected into programs, and of
course no capture data (screenshots, resource contents, shaders, etc
etc) is transmitted.
* Once it's turned on, it will apply to both development and release
builds. It tracks stats over a month, and then at the beginning of a
new month it sends the previous data.
* When the user first starts up a build with analytics if there's no
previous analytics database then they are informed of the new code and
asked to approve it. They have the option of selecting to manually
verify any sent reports, or just opt-ing out entirely.
baldurk