On Wed, Aug 25, 2010 at 3:43 PM, Roland Scheidegger <srol...@vmware.com>wrote:
> 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. > > 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). > 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. 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... > sprite_coord_enable matches r300 hw exactly (there are per-texcoord enable bits in hw). 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. > 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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
