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

[Andreas Bergmeier]

> 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.

Thanks. Currently I am trying to orient on Intel, since it
a, seems the closest non-capability wise and
b, if push comes to shove, I might be able to compile a new
libvulkanintel.so and start tracing with that

What do you think would be the better reference? RADV?

On Tue, 27 Aug 2019 at 00:51, Jason Ekstrand <jason at jlekstrand.net> wrote:

> 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/20190827/59bd2e71/attachment-0001.html>