On 21.01.2010 18:47, Luca Barbieri wrote: > On Thu, Jan 21, 2010 at 6:34 PM, Corbin Simpson > <mostawesomed...@gmail.com> wrote: >> Maybe it's just me, since I actually wrote the docs, but does anybody >> else read them? >> >> From cso/rasterizer.html (viewable at e.g. >> http://people.freedesktop.org/~csimpson/gallium-docs/cso/rasterizer.html >> ): >> >> gl_rasterization_rules >> Whether the rasterizer should use (0.5, 0.5) pixel centers. When >> not set, the rasterizer will use (0, 0) for pixel centers. >> >> So why aren't these patches using >> pipe_rasterizer_state::gl_rasterization_rules? > > It's a different thing. > gl_rasterization_rules affects the way fragments are rasterized, i.e. > the set of fragments which a primitive is mapped to. > Changing it is equivalent to adding/subtracting a subpixel offset to > the viewport (which seemingly depends on the primitive type). > > The pixel center convention instead sets how the values look like in > the fragment shader. > Changing it is equivalent to adding/subtracting 0.5 to the > fragment.position in the fragment shader. > > In other words, yes, if you set gl_rasterization_rules and the pixel > center in a mismatched way, fragment.position will not be the > coordinate of the "rasterization center". > > As another example, suppose you do a blit with the 3D engine using > fragment.position to sample from a texture rectangle with bilinear > filtering. > A wrong rasterization convention may cause 1 pixel black bars at the borders. > A wrong pixel center convention will cause a 2x2 blur filter to be > applied to the texture. > > BTW, gl_rasterization_rules is ignored by almost all drivers
Most but not all. Not the software based ones, for instance. Should be easy to add to r300 (and the nouveau ones, I assume), I guess these simply don't care enough about environments with different (= DX9) rasterization rules :-). Roland > >>From the spec: > << > The scope of this extension deals *only* with how the fragment > coordinate XY location appears during programming fragment processing. > Beyond the scope of this extension are coordinate conventions used > for rasterization or transformation. > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
