[Mesa-dev] Mesa (master): r300g: fix gl_PointCoord

[Roland Scheidegger]

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