Create the RDCMTL descriptor struct in the ObjC hook and pass it to the C++ wrapped APIs
ie.
WrappedMTLDevice::newTextureWithDescriptor takes a RDMTL::TextureDescriptor &
WrappedMTLDevice::newRenderPipelineStateWithDescriptor takes a RDMTL::RenderPipelineDescriptor &
This means the wrapping and unwrapping of resources in the descriptor structs is handled by the conversion methods for the structs
METAL_NOT_HOOKED
Get class name directly from self pointer instead of getting the class type from self and then the class name from the class type
Change the log to be an RDCERR instead of an RDCWARN
METAL_NOT_IMPLEMENTED_ONCE
Change the log to be an RDCWARN instead of RDCDEBUG to match METAL_NOT_IMPLEMENTED macro
* If the popmarker inserted at the end of an indirect multi-draw is selected
this points past the end of the normal draws, but we don't want to replay that
extra draw.
* Unifying these views means that constant buffers have all the same
reformatting and it avoids having multiple paths for what is now effectively
the same control (a buffer can either have fixed data, repeating data, or
both)
* GL and Vulkan allow buffers to have fixed variables before a trailing AoS
unbounded array. These fixed variables can't be easily displayed in a table
and previously we skipped them. Now we display these in a tree format.
* We also support formats which don't have an unbounded array at all and display
these just with the tree. This will allow the BufferViewer to subsume the
capabilities of the ConstantBufferPreviewer (though it needs to handle opaque
non-buffer-backed variables, and slot-following).
* These elements are consumed but not shown, so the offsets of subsequent
elements still act as if they're there. This may be more convenient than
specifying a manual offset on the next element or a struct size.
* There's no reason to make users aware that the mesh viewer and buffer viewer
are implemented in a common way, they are very different and should be
documented separately.
* This hasn't updated the buffer viewer documentation with the recently added
features.
* This allows the calling code to pass a hint of what packing is known or likely
to be used, meaning less generated manual offsetting/padding when the implicit
rules cover it.
* Instead of having a global tight/non-tight we now let the format string
specify the packing rules (defaulting to scalar - i.e. tight packing as
before), and use the resulting properties to calculate packing.
* This is primarily for GL/VK where the packing rules are not pre-defined and
are also not explicitly reflected, so we instead see what rules are broken
along the way to get the most conservative ruleset we can (that way minimising
the need for manual offset decorations)
* There are several different API packing rulesets - GL has std140 and std430
(and packed/shared, which is implementation defined but is likely to be
similar to one of these or more conservative), VK effectively has rules for
those both, as well as scalar packing which is close to C packing. D3D has one
ruleset for cbuffer packing similar to std140, and effectively scalar for
structured resources.
* These rulesets are quite similar and only differ by the properties here. There
is one exception in the handling of empty structs - but in GLSL these are
illegal so we will take the HLSL interpretation and always treat them as 0
bytes.
baldurk