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

[Roland Scheidegger]

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