<div dir="ltr"><div>For a few weeks now I am working on implementing Vulkan for VideoCore 6 AKA 42 (using V3D/DRM). Don't hold you breath ;)</div><div><br></div>Currently I am trying to understand what is necessary or how to interact with V3D. So I am looking at TransformFeedback because it interacts with quite a few other parts of the pipeline and still seems less mangled into the big logic than other features. So I am comparing how Gallium (V3D) is handling TF in the state tracker VS how Vulkan (Intel) is handling the Extension.<div><br></div><div>The following is what I so far think I gathered:</div><div>1. GV3D is handling TransformFeedback directly with other bound parts of the pipeline (e.g. `emit_state` in _v3dx_emit.c_). It seems to look into the shader and associated TF specs. It seems to use "streamout targets", although I do not yet understand what these are really. Then it passes all the offsets, indices and finally resources to V3D.</div><div>2. The Vulkan Extension only knows about CounterBuffers and iterates over these. Intel seems to call TF -> XF? and subsequently the buffers XFB. Have also not yet gathered what is the difference and what all the gazillion acronyms mean.</div><div><br></div><div>So far my idea would be to implement TF similar to Intel and instead of iterating over "streamout targets" I would iterate XFBs.</div><div>The problem with this approach is, that it will not be easy to mimic `cl_emit` calls similar to Gallium.</div><div>My question now is which parts of V3D emits have a dependency.</div><div><br></div><div>I would assume that I can move TRANSFORM_FEEDBACK_SPECS and TRANSFORM_FEEDBACK_ENABLE to cmd state flush in Vulkan.</div><div>`vkCmdBeginTransformFeedbackEXT` shoudl then only need TRANSFORM_FEEDBACK_BUFFER and TRANSFORM_FEEDBACK_OUTPUT_ADDRESS.</div><div><br></div><div>Sorry if this is a bit confusing - I am really just trying to figure this out one by one.</div><div><br></div><div>Any information would be appreciated.</div><div><div><div><br></div></div></div></div>