Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
> So you have to be able to generate both S,T and S,1-T. [Or > perhaps there's an explicit control for it, I forget.] With GLES2+, > it's just gl_PointCoord though. FWIW, the blob emits a linear (er, affine technically?) transformation in the shader to do the flip, loading the matrix from a special uniform so they can reuse the same shader across contexts and maybe also APIs. This seems a little excessive to me since for OpenGL scanout they're just using the identity matrix but hey. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
On Fri, Mar 15, 2019 at 5:00 PM Ilia Mirkin wrote: > > On Fri, Mar 15, 2019 at 11:52 AM Connor Abbott wrote: > > > > On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin wrote: > > > > > > On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig < aly...@rosenzweig.io> wrote: > > > > > > > > > This is needed if you can only handle point sprites on certain > > > > > varyings but not others. This is the case for nv30- and nvc0-based > > > > > GPUs, which is why the cap was introduced. > > > > > > > > > > If your GPU does not have such restrictions, you can safely remove the cap. > > > > > > > > Ah-ha, I see, thank you. > > > > > > > > I can't handle point sprites on any varyings (they all have to get > > > > lowered to gl_PointCoord), so.. :) > > > > > > Yeah, that's not extremely surprising. Point sprites weren't a thing > > > in GLES 1, and only available as gl_PointCoord in GLES 2. With GL 1.x > > > + multitexture, you can have up to 8 tex coords used in your fragment > > > pipeline, and so need a fixed-function way of setting them to point > > > coords when drawing points. Hence the current TEXCOORD semantics of > > > just bumping generic varyings by 8, so that we can be sure that any > > > shaders with true gl_TexCoord[] usage get the low 8 varyings assigned > > > (and which, on nvc0+ go through "special" shader outputs, subject to > > > the replacement). > > > > > > Note that e.g. Adreno A3xx+ is capable of doing the replacement > > > everywhere, despite being a GLES-targeted GPU. So it's not out of the > > > realm of possibility that you just haven't figured out the full > > > mechanism for doing it yet. > > > > Can you replace more than one varying and output multiple points vertex shader, or something crazy like that? On Mali gl_PointCoord is just a normal varying whose descriptor points to a special point-coord buffer that gets fed to the tiler, so we should be able to make an arbitrary varying "turn into" gl_PointCoord just by changing its descriptor at draw time. > > Yeah, any (gl_TexCoord) varying may get replaced by a point sprite > coord (in GL 1.x / GL 2.x). Note that there's additional complication > from coordinate inversion, when you're drawing on the winsys fb vs an > fbo. So you have to be able to generate both S,T and S,1-T. [Or > perhaps there's an explicit control for it, I forget.] With GLES2+, > it's just gl_PointCoord though. > > The way gallium handles this is that you get a mask of varyings to > replace in https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_state.h#n188 > + whether to invert or not (sprite_coord_mode). Oh, whoops... I guess I was thinking of gl_PointSize. gl_PointCoord in the fragment shader does indeed come through an extra-special varying, at least the way the blob does it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
On Fri, Mar 15, 2019 at 11:52 AM Connor Abbott wrote: > > On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin wrote: > > > > On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig > > wrote: > > > > > > > This is needed if you can only handle point sprites on certain > > > > varyings but not others. This is the case for nv30- and nvc0-based > > > > GPUs, which is why the cap was introduced. > > > > > > > > If your GPU does not have such restrictions, you can safely remove the > > > > cap. > > > > > > Ah-ha, I see, thank you. > > > > > > I can't handle point sprites on any varyings (they all have to get > > > lowered to gl_PointCoord), so.. :) > > > > Yeah, that's not extremely surprising. Point sprites weren't a thing > > in GLES 1, and only available as gl_PointCoord in GLES 2. With GL 1.x > > + multitexture, you can have up to 8 tex coords used in your fragment > > pipeline, and so need a fixed-function way of setting them to point > > coords when drawing points. Hence the current TEXCOORD semantics of > > just bumping generic varyings by 8, so that we can be sure that any > > shaders with true gl_TexCoord[] usage get the low 8 varyings assigned > > (and which, on nvc0+ go through "special" shader outputs, subject to > > the replacement). > > > > Note that e.g. Adreno A3xx+ is capable of doing the replacement > > everywhere, despite being a GLES-targeted GPU. So it's not out of the > > realm of possibility that you just haven't figured out the full > > mechanism for doing it yet. > > Can you replace more than one varying and output multiple points vertex > shader, or something crazy like that? On Mali gl_PointCoord is just a normal > varying whose descriptor points to a special point-coord buffer that gets fed > to the tiler, so we should be able to make an arbitrary varying "turn into" > gl_PointCoord just by changing its descriptor at draw time. Yeah, any (gl_TexCoord) varying may get replaced by a point sprite coord (in GL 1.x / GL 2.x). Note that there's additional complication from coordinate inversion, when you're drawing on the winsys fb vs an fbo. So you have to be able to generate both S,T and S,1-T. [Or perhaps there's an explicit control for it, I forget.] With GLES2+, it's just gl_PointCoord though. The way gallium handles this is that you get a mask of varyings to replace in https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_state.h#n188 + whether to invert or not (sprite_coord_mode). Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin wrote: > > On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig wrote: > > > > > This is needed if you can only handle point sprites on certain > > > varyings but not others. This is the case for nv30- and nvc0-based > > > GPUs, which is why the cap was introduced. > > > > > > If your GPU does not have such restrictions, you can safely remove the cap. > > > > Ah-ha, I see, thank you. > > > > I can't handle point sprites on any varyings (they all have to get > > lowered to gl_PointCoord), so.. :) > > Yeah, that's not extremely surprising. Point sprites weren't a thing > in GLES 1, and only available as gl_PointCoord in GLES 2. With GL 1.x > + multitexture, you can have up to 8 tex coords used in your fragment > pipeline, and so need a fixed-function way of setting them to point > coords when drawing points. Hence the current TEXCOORD semantics of > just bumping generic varyings by 8, so that we can be sure that any > shaders with true gl_TexCoord[] usage get the low 8 varyings assigned > (and which, on nvc0+ go through "special" shader outputs, subject to > the replacement). > > Note that e.g. Adreno A3xx+ is capable of doing the replacement > everywhere, despite being a GLES-targeted GPU. So it's not out of the > realm of possibility that you just haven't figured out the full > mechanism for doing it yet. Can you replace more than one varying and output multiple points vertex shader, or something crazy like that? On Mali gl_PointCoord is just a normal varying whose descriptor points to a special point-coord buffer that gets fed to the tiler, so we should be able to make an arbitrary varying "turn into" gl_PointCoord just by changing its descriptor at draw time. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig wrote: > > > This is needed if you can only handle point sprites on certain > > varyings but not others. This is the case for nv30- and nvc0-based > > GPUs, which is why the cap was introduced. > > > > If your GPU does not have such restrictions, you can safely remove the cap. > > Ah-ha, I see, thank you. > > I can't handle point sprites on any varyings (they all have to get > lowered to gl_PointCoord), so.. :) Yeah, that's not extremely surprising. Point sprites weren't a thing in GLES 1, and only available as gl_PointCoord in GLES 2. With GL 1.x + multitexture, you can have up to 8 tex coords used in your fragment pipeline, and so need a fixed-function way of setting them to point coords when drawing points. Hence the current TEXCOORD semantics of just bumping generic varyings by 8, so that we can be sure that any shaders with true gl_TexCoord[] usage get the low 8 varyings assigned (and which, on nvc0+ go through "special" shader outputs, subject to the replacement). Note that e.g. Adreno A3xx+ is capable of doing the replacement everywhere, despite being a GLES-targeted GPU. So it's not out of the realm of possibility that you just haven't figured out the full mechanism for doing it yet. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
> This is needed if you can only handle point sprites on certain > varyings but not others. This is the case for nv30- and nvc0-based > GPUs, which is why the cap was introduced. > > If your GPU does not have such restrictions, you can safely remove the cap. Ah-ha, I see, thank you. I can't handle point sprites on any varyings (they all have to get lowered to gl_PointCoord), so.. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
This is needed if you can only handle point sprites on certain varyings but not others. This is the case for nv30- and nvc0-based GPUs, which is why the cap was introduced. If your GPU does not have such restrictions, you can safely remove the cap. -ilia On Fri, Mar 15, 2019 at 12:25 AM Alyssa Rosenzweig wrote: > > I don't know why this was on to begin with...? > > Signed-off-by: Alyssa Rosenzweig > --- > src/gallium/drivers/panfrost/pan_screen.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/src/gallium/drivers/panfrost/pan_screen.c > b/src/gallium/drivers/panfrost/pan_screen.c > index 9cd65ca8ff8..9672048bca8 100644 > --- a/src/gallium/drivers/panfrost/pan_screen.c > +++ b/src/gallium/drivers/panfrost/pan_screen.c > @@ -195,9 +195,6 @@ panfrost_get_param(struct pipe_screen *screen, enum > pipe_cap param) > case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: > return 0; > > -case PIPE_CAP_TGSI_TEXCOORD: > -return 1; /* XXX: What should this me exactly? */ > - > case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER: > return 0; > > -- > 2.20.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
I don't know why this was on to begin with...? Signed-off-by: Alyssa Rosenzweig --- src/gallium/drivers/panfrost/pan_screen.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/gallium/drivers/panfrost/pan_screen.c b/src/gallium/drivers/panfrost/pan_screen.c index 9cd65ca8ff8..9672048bca8 100644 --- a/src/gallium/drivers/panfrost/pan_screen.c +++ b/src/gallium/drivers/panfrost/pan_screen.c @@ -195,9 +195,6 @@ panfrost_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; -case PIPE_CAP_TGSI_TEXCOORD: -return 1; /* XXX: What should this me exactly? */ - case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER: return 0; -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
