[Mesa-dev] v3d: Difference between TransformFeedback Gallium <-> Vulkan

[apinheiro]

On 26/8/19 13:28, abergmeier at gmx.net wrote:
> For a few weeks now I am working on implementing Vulkan for VideoCore 
> 6 AKA 42 (using V3D/DRM). Don't hold you breath ;)
>
> 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.
>
> The following is what I so far think I gathered:
> 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.
> 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.


XFB is a really common acronym for transform feedback. So yes, XFB and 
TF are acronyms fro the same.

>
> So far my idea would be to implement TF similar to Intel and instead 
> of iterating over "streamout targets" I would iterate XFBs.
> The problem with this approach is, that it will not be easy to mimic 
> `cl_emit` calls similar to Gallium.
> My question now is which parts of V3D emits have a dependency.
>
> I would assume that I can move TRANSFORM_FEEDBACK_SPECS and 
> TRANSFORM_FEEDBACK_ENABLE to cmd state flush in Vulkan.
> `vkCmdBeginTransformFeedbackEXT` shoudl then only 
> need TRANSFORM_FEEDBACK_BUFFER and TRANSFORM_FEEDBACK_OUTPUT_ADDRESS.
>
> Sorry if this is a bit confusing - I am really just trying to figure 
> this out one by one.
>
> Any information would be appreciated.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190827/7a3276f1/attachment.html>