Re: [Mesa-dev] Difference between TransformFeedback Gallium <-> Vulkan (V3D)
On Mon, Aug 26, 2019 at 6:51 PM Jason Ekstrand wrote: > On Mon, Aug 26, 2019 at 6:43 AM Daniel Stone wrote: > >> Hi Andreas, >> >> On Sun, 25 Aug 2019 at 21:11, Andreas Bergmeier >> 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. > Yeah that is unpleasant. The core of transform feedback is really an atomic add instruction that returns in the thread ID order and can fail if the remaining free range is too small. With that, transform feedback can be nicely emulated in the shader. The fact that it's the only way to do buffer append in the thread ID order makes it pretty unique, and perhaps it would be more useful if it was supported by compute shaders. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Difference between TransformFeedback Gallium <-> Vulkan (V3D)
On Tue, 27 Aug 2019 at 09:03, Andreas Bergmeier wrote: > > > 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? One thing to remember is you don't need XFB for a conformant vulkan driver, the extension isn't even an official one. It's probably the last place to start :-) Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Difference between TransformFeedback Gallium <-> Vulkan (V3D)
> 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 wrote: > On Mon, Aug 26, 2019 at 6:43 AM Daniel Stone wrote: > >> Hi Andreas, >> >> On Sun, 25 Aug 2019 at 21:11, Andreas Bergmeier >> 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
Re: [Mesa-dev] Difference between TransformFeedback Gallium <-> Vulkan (V3D)
On Mon, Aug 26, 2019 at 6:43 AM Daniel Stone wrote: > Hi Andreas, > > On Sun, 25 Aug 2019 at 21:11, Andreas Bergmeier > 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
Re: [Mesa-dev] Difference between TransformFeedback Gallium <-> Vulkan (V3D)
Hi Andreas, On Sun, 25 Aug 2019 at 21:11, Andreas Bergmeier 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. > 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. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
