<div dir="ltr"><div dir="ltr">> 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.<div><br></div><div>Thanks. Currently I am trying to orient on Intel, since it</div><div>a, seems the closest non-capability wise and</div></div>b, if push comes to shove, I might be able to compile a new libvulkanintel.so and start tracing with that<div><br></div><div>What do you think would be the better reference? RADV?<br><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 27 Aug 2019 at 00:51, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 26, 2019 at 6:43 AM Daniel Stone <<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Andreas,<br>
<br>
On Sun, 25 Aug 2019 at 21:11, Andreas Bergmeier <<a href="mailto:abergmeier@gmx.net" target="_blank">abergmeier@gmx.net</a>> wrote:<br>
> For a few weeks now I am working on implementing Vulkan for VideoCore 6 AKA 42 (using V3D/DRM). Don't hold you breath ;)<br>
<br>
Great! I can't say much about the specifics of VideoCore hardware, but<br>
at least for some of the common parts ...<br>
<br>
> 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.<br>
><br>
> The following is what I so far think I gathered:<br>
> 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.<br>
<br>
'Stream out' is basically just what DirectX calls its version of<br>
transform feedback. The idea is the same: capturing output from<br>
vertex/geometry stages.<br>
<br>
> 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.<br>
<br>
'XFB' is the most widely-used acronym for transform, as 'trans' or<br>
'cross' can abbreviate to X. 'TF' is not as widely used as XFB.<br>
<br>
> So far my idea would be to implement TF similar to Intel and instead of iterating over "streamout targets" I would iterate XFBs.<br>
<br>
So these would really be the same thing. A streamout target is where<br>
the VC4 writes its output stream of data from these shading stages,<br>
and a counter buffer is where Vulkan writes the output stream of data<br>
from these shading stages.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> The problem with this approach is, that it will not be easy to mimic `cl_emit` calls similar to Gallium.<br>
> My question now is which parts of V3D emits have a dependency.<br>
><br>
> I would assume that I can move TRANSFORM_FEEDBACK_SPECS and TRANSFORM_FEEDBACK_ENABLE to cmd state flush in Vulkan.<br>
> `vkCmdBeginTransformFeedbackEXT` shoudl then only need TRANSFORM_FEEDBACK_BUFFER and TRANSFORM_FEEDBACK_OUTPUT_ADDRESS.<br>
><br>
> Sorry if this is a bit confusing - I am really just trying to figure this out one by one.<br>
<br>
This is getting more into the specifics of how you've structured the<br>
driver, as well as hardware specifics, but it sounds about right to<br>
me.</blockquote><div><br></div><div>Same.  Sounds reasonable but I say that as someone who's never seen a line of that driver. :-)</div><div><br></div><div>--Jason<br></div></div></div>
</blockquote></div></div></div></div>