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
