<div dir="ltr"><br><br>On Fri, Mar 15, 2019 at 5:00 PM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote:<br>><br>> On Fri, Mar 15, 2019 at 11:52 AM Connor Abbott <<a href="mailto:cwabbott0@gmail.com">cwabbott0@gmail.com</a>> wrote:<br>> ><br>> > On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote:<br>> > ><br>> > > On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig <<a href="mailto:alyssa@rosenzweig.io">alyssa@rosenzweig.io</a>> wrote:<br>> > > ><br>> > > > > This is needed if you can only handle point sprites on certain<br>> > > > > varyings but not others. This is the case for nv30- and nvc0-based<br>> > > > > GPUs, which is why the cap was introduced.<br>> > > > ><br>> > > > > If your GPU does not have such restrictions, you can safely remove the cap.<br>> > > ><br>> > > > Ah-ha, I see, thank you.<br>> > > ><br>> > > > I can't handle point sprites on any varyings (they all have to get<br>> > > > lowered to gl_PointCoord), so.. :)<br>> > ><br>> > > Yeah, that's not extremely surprising. Point sprites weren't a thing<br>> > > in GLES 1, and only available as gl_PointCoord in GLES 2. With GL 1.x<br>> > > + multitexture, you can have up to 8 tex coords used in your fragment<br>> > > pipeline, and so need a fixed-function way of setting them to point<br>> > > coords when drawing points. Hence the current TEXCOORD semantics of<br>> > > just bumping generic varyings by 8, so that we can be sure that any<br>> > > shaders with true gl_TexCoord[] usage get the low 8 varyings assigned<br>> > > (and which, on nvc0+ go through "special" shader outputs, subject to<br>> > > the replacement).<br>> > ><br>> > > Note that e.g. Adreno A3xx+ is capable of doing the replacement<br>> > > everywhere, despite being a GLES-targeted GPU. So it's not out of the<br>> > > realm of possibility that you just haven't figured out the full<br>> > > mechanism for doing it yet.<br>> ><br>> > 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.<br>><br>> Yeah, any (gl_TexCoord) varying may get replaced by a point sprite<br>> coord (in GL 1.x / GL 2.x). Note that there's additional complication<br>> from coordinate inversion, when you're drawing on the winsys fb vs an<br>> fbo. So you have to be able to generate both S,T and S,1-T. [Or<br>> perhaps there's an explicit control for it, I forget.] With GLES2+,<br>> it's just gl_PointCoord though.<br>><br>> The way gallium handles this is that you get a mask of varyings to<br>> replace in <a href="https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_state.h#n188">https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_state.h#n188</a><br><div>> + whether to invert or not (sprite_coord_mode).</div><div><br></div><div>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.<br></div></div>