> 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 <ja...@jlekstrand.net> wrote: > On Mon, Aug 26, 2019 at 6:43 AM Daniel Stone <dan...@fooishbar.org> wrote: > >> Hi Andreas, >> >> On Sun, 25 Aug 2019 at 21:11, Andreas Bergmeier <abergme...@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 >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
