<div class="gmail_quote">On Wed, Aug 25, 2010 at 3:43 PM, Roland Scheidegger <<a href="mailto:sroland@vmware.com">sroland@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">On 25.08.2010 09:05, Ian Romanick wrote: > keith whitwell wrote: >> The point state is complex, there are actually a lot of variations >> built into GL itself which aren't obvious on first reading of the >> spec. Probably the most obscure is that wide points and point sprites >> are specified to actually be rasterized differently, ie color >> different pixels. I'm doing this from memory, but Roland dug into it >> in depth. Wide points have an explicit set of rules for which pixels >> they cover, but point sprites are to be rasterized with the same rules >> as a quad of similar size (again from memory). The docs do explain >> it, but it's complex none the less, and I do still wonder if there is >> a clear way of capturing all the variations. > > I remember a lot of back and forth when we crafted the rasterization > rules for point sprites. I believe the intention was that > implementations could either decompose a point sprite into a quad / two > triangles or reuse the existing wide point rasterization hardware. At > the end of the day, it is a big mess and a pain in the behind. </div>Yes, indeed - new GL tossed out traditional point rendering (i.e. point sprite mode is always active, point rendering similar to what d3d uses). It didn't look to me though that you could use either quad rendering or some point implementation using point rendering rules and be compliant with both gl modes, at the very least there's a difference for zero-sized points (which will disappear with the quad approach but be one pixel with the point rendering approach - that is something however which might be fixed with the min clamp adjustment). So if drivers can't switch point rendering rules, they probably just need to ignore point_quad_rasterization (it is illegal for point quad rasterization to be false but one of the sprite_coord_enable bits set). </blockquote><div> On r300, points are always rasterized as parallelograms or, as you say, quads (can be non-square). I cannot disable quad rasterization, but I can use point size clamping. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> sprite_coord_enable though is per-coord (as per legacy GL, not in d3d or GL3) and should be honored accordingly, though I don't know if there's really something out there which uses, say, 2 textures on a point sprite, one with interpolated texture coords the other with single coord for the whole point... </blockquote><div> sprite_coord_enable matches r300 hw exactly (there are per-texcoord enable bits in hw). </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> So regarding the r300g code, it could possibly ignore point_quad_rasterization (but honoring it shouldn't hurt), and I don't quite understand what that "| 1" part is supposed to do, looks wrong to me. </blockquote><div> It's for gl_PointCoord. It means: if (point_quad_rasterization) sprite_coord_enable |= 1; else sprite_coord_enable = 0; The problem is that if a shader uses gl_PointCoord, st/mesa doesn't set sprite_coord_enable to a non-zero value to actually enable the sprite coords, so I enforce this in the driver (like nvfx does), assuming gl_PointCoord occupies GENERIC0. Marek </div></div>