[Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD

Connor Abbott cwabbott0 at gmail.com
Fri Mar 15 15:51:50 UTC 2019


On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>
> On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig <alyssa at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190315/89d51b00/attachment.html>


More information about the mesa-dev mailing list