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

[Marek Olšák]

On Wed, Aug 25, 2010 at 3:43 PM, Roland Scheidegger <sroland at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100825/a4038ada/attachment.htm>