Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WriteToSubresource and CheckFeatureSupport Decode and Process Functions Should Forward Thread and Index #1368

Open
andrew-lunarg opened this issue Nov 23, 2023 · 0 comments
Labels
P2 A high-priority code maintenance issue or a functional problem that is recoverable or not a crash.

Comments

@andrew-lunarg
Copy link
Contributor

andrew-lunarg commented Nov 23, 2023

Decode of the CheckFeatureSupport functions are very special cases due to them passing data through void pointers with type erasure. Decode and Consumer Process functions for them should still support standard method parameters like thread and block index, probably using the ApiCallInfo object in the same way as other functions in both main APIs do.

Example member function we would want in the base class header:

virtual void Process_ID3D12Resource_WriteToSubresource(
        const ApiCallInfo& call_info,
        format::HandleId object_id,
        HRESULT return_value,
        UINT DstSubresource,
        StructPointerDecoder<Decoded_D3D12_BOX>* pDstBox,
        void* pSrcData,
        UINT SrcRowPitch,
        UINT SrcDepthPitch) {}

Instead we currently have:

virtual void Process_ID3D12Resource_WriteToSubresource(
        format::HandleId object_id,
        HRESULT original_result,
        UINT DstSubresource,
        StructPointerDecoder<Decoded_D3D12_BOX>* pDstBox,
        void* pSrcData,
        UINT SrcRowPitch,
        UINT SrcDepthPitch) {}

Sidebar

Manual process functions in general should use the same signature that we would expect generation to produce if it were working including the same names for arguments. Why? Because some consumers with simple uses like JSON conversion might still be able to be generated even though the main replay one needs custom handling, and those generators will expect the standard generated function signature with arguments named identically to the underlying API entrypoint's ones.

Note, one way to ensure this would be to let headers always be generated and only block generation for the bodies. The manual/custom function bodies could then be typed into a compilation unit and named void GeneratedClassX::Process_Y(...) {...} even though they are not generated but manually-written without needing to put them in a base class for custom things at all. If it seems off to manually write a member function for a class called GeneratedX, well maybe change the class name?

@andrew-lunarg andrew-lunarg changed the title CheckFeatureSupport Decode and Process Functions Should Forward Thread and Index WriteToSubresource and CheckFeatureSupport Decode and Process Functions Should Forward Thread and Index Nov 24, 2023
@bradgrantham-lunarg bradgrantham-lunarg added the P2 A high-priority code maintenance issue or a functional problem that is recoverable or not a crash. label Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 A high-priority code maintenance issue or a functional problem that is recoverable or not a crash.
Projects
None yet
Development

No branches or pull requests

2 participants