[Mesa-dev] Difference between TransformFeedback Gallium <-> Vulkan (V3D)

[Jason Ekstrand]

On Mon, Aug 26, 2019 at 6:43 AM Daniel Stone <daniel at fooishbar.org> wrote:

> Hi Andreas,
>
> On Sun, 25 Aug 2019 at 21:11, Andreas Bergmeier <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 ;)
>
> Great! I can't say much about the specifics of VideoCore hardware, but
> at least for some of the common parts ...
>
> > 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.
>
> 'Stream out' is basically just what DirectX calls its version of
> transform feedback. The idea is the same: capturing output from
> vertex/geometry stages.
>
> > 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 the most widely-used acronym for transform, as 'trans' or
> 'cross' can abbreviate to X. 'TF' is not as widely used as XFB.
>
> > So far my idea would be to implement TF similar to Intel and instead of
> iterating over "streamout targets" I would iterate XFBs.
>
> So these would really be the same thing. A streamout target is where
> the VC4 writes its output stream of data from these shading stages,
> and a counter buffer is where Vulkan writes the output stream of data
> from these shading stages.
>

Be warned that the way the Intel streamout hardware works is really weird.
It's designed from the perspective of something walking a buffer and trying
to figure out which outputs to grab.  This is completely backwards (or
inside-out, whichever is weirder) from the API which is written from the
perspective of a shader shoving data into a buffer.  If you're looking at
the ANV code, it's really easy to get turned around.


> > 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.
>
> This is getting more into the specifics of how you've structured the
> driver, as well as hardware specifics, but it sounds about right to
> me.


Same.  Sounds reasonable but I say that as someone who's never seen a line
of that driver. :-)

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190826/152374e1/attachment.html>