<div dir="ltr">On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote: > > On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig <<a href="mailto:alyssa@rosenzweig.io">alyssa@rosenzweig.io</a>> 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. <div> </div><div>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. </div></div>