On 25.08.2010 15:43, Roland Scheidegger 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). > 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... > 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. > > Roland
Forgot to mention, of course point_quad_rasterization definitely makes a large difference when either point_smooth or msaa are enabled, since points rasterized as quads will still be square but otherwise a circle needs to be drawn (and different rules apply for this depending on if only point smooth is enabled or msaa is enabled...) Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
