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. Cheers, -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
