* For pipelines using tessellation or containing a geometry shader we use
transform feedback to fetch the output of the vertex pipeline after these
stages.
* This will allow the backend to specify both the native format (e.g. SPIR-V,
DXBC) as well as a language it might be able to internally compile (GLSL or
HLSL).
* The caller will then able to decide for itself whether it wants to compile to
native format and pass that down, or pass the language down and let it be
built internally.
* Currently BuildTargetShader still only accepts shader source.
* If we make WindowingData an empty struct not an opaque one, it won't leak memory
* Similarly we need typemaps to allow python to pass plain ints and have them cast to pointers
* The main addition here apart from some extra stubs is a new rdc type
for date time objects.
* Although the module doesn't do anything and is only used for docs
reflection it is desirable to not have to link against Qt as this
can cause problems when linking the module without unresolved symbols.
* We enforce a naming scheme more strongly - types, member functions,
and enum values must be UpperCaseCamel, and member variables must be
lowerCaseCamel. No underscores allowed.
* eventId not eventID or EID, and Id preferred to ID in general. Also
for resourceId.
* Removed some lingering hungarian m_Foo naming.
* Some pipeline state structs that are almost identical between the
different APIs are pulled out into common structs. Where something
doesn't make sense (e.g. viewport enable for vulkan) it will just be
set to a sensible default (in that case always true).
* Changed scissors to be x/y & width/height instead of sometimes
left/top/right/bottom
* Abbreviations are discouraged, e.g. operation not op, function not
func.
* 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.
* Enums are now proper python enums instead of just being a class with
static int members.
* Fix a refcounting issue with SWIG generated code to access nested
child structs.
* The new system contains the ability to export serialised data to a
structured form in memory - and conversion back to serialised bytes.
* This will allow offline transformations/visualisation of capture files
as well as more rich representations of API calls in the UI.
* Likewise it enables a number of optimisations such as the ability to
write straight from mapped API memory to disk via a compressor,
without any intermediate copies.
* Note that while this is public and uses std::string, because it's a
template with specialisations in a .inl the string never crosses a
module boundary - each including module has its own implementation.
* This will be used as part of the upcoming serialisation refactor.
* Some POD structs are still given ToStr implementations as we haven't
yet switched over the serialisation system to expect all structs to
have serialise functions.
* We have some special handling to allow SWIG wrapping of these types:
SDFile owns the chunks and buffers within, and each object owns its
children. Copying is disallowed except from SWIG where we assume the
wrapper is handling lifetime management for its objects externally.
* Previously we would convert from python to C++ arrays immediately by
copying, and vice-versa convert TO python immediately by creating a
new python list by copying.
* This however behaves rather poorly in common situations, e.g.:
> foo.bar.append(5)
Would not append 5 to foo.bar, but copy foo.bar to a temporary, append
5 to it, then destroy it leaving foo.bar untouched.
* Instead we leave the C++ array type as a pointer for as long as we can
and instead implement the python sequence API as extensions/slots that
work in-place on the original array.
* Since these types are more prevalent than originally designed, it
makes more sense to remove the namespace for ease of typing/naming.
* Also add a specialised type 'bytebuf' for an array of bytes.
* This makes mapping easier to SWIG since there's no special casing for
namespaced arrays. Especially so for nested cases like
rdctype::array<rdctype::str> -> rdcarray<rdcstr>
* For the most part the interface is stl-compatible, but we have a few
little changes of our own for convenience.
* This class is still needed after deleting the C# UI, because we don't
want to pass C++ stl structs over module boundaries and possibly run
into hard to diagnose incompatibilities.
* The former is only needed inside tp_init of a new object. Instead when
we want to pass in and own a pointer, we use SWIG_POINTER_OWN.
* This also removes the need to pass 'self' all the way down in
ConvertToPy which tidies up a lot of code.
* The bug seems to happen if two raw strings concatenated together are
large enough, so instead we pass them as separate parameters to a
different macro then concatenate them inside the macro.
* 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.
* Generally this means removing ref out parameters and instead returning
values. In a couple of cases we will want to avoid copies in future
either by returning const references (e.g. to the pipeline state which
is immutable).
* At the same time, some pointless bool return values that were always
true and didn't indicate errors have been removed. They can be added
again if an error condition comes back.
* Some free functions still have out parameters as C linkage doesn't
allow returning user types by value.
* The C# UI still invokes into C wrappers for all the C++ classes, which
handle taking the return value and doing a copy into an out parameter
still for compatibility.
* We need to keep a PythonContext (and its globals Dict) around while
we still have some pending callbacks happening. So now the external
code creates a PythonContext and then releases it when it's done, but
the context will hang around until the global redirector object is
destructed, which is responsible for deleting the context.
* The global redirector is deleted when a refcounting cycle is detected
and the dict is unreachable, which only happens after the context is
released.
* Any time a callback is passed to something and converted to a
std::function we add a reference on the global redirector to keep it
alive. When the callback has finished executing we remove the ref.
* This way, any pending callbacks that have been called but not finished
or converted (queued) and not called yet asynchronously will keep the
context object alive to be able to output, handle exceptions, etc.
* Additionally we need to detect when we're being called asynchronously
and handle exceptions separately instead of trying to propagate up the
call chain, because there might not be any more python code up the
chain (e.g. the render manager calling a python callback).
baldurk