[Mesa-dev] [PATCH 2/2] gallium: Replaced gl_rasterization_rules with lower_left_origin and half_pixel_center.

[Christoph Bumiller]

On 21.04.2013 14:35, Jose Fonseca wrote:
> 
> 
> ----- Original Message -----
>> On 21.04.2013 13:18, Jose Fonseca wrote:
>>
>> I think that drivers can just report all 4 CAPs as supported and do the
>> adjustment in the shader themselves (no need for recompilation, just use
>> uniforms, the st already does it like that), provided that the state
>> tracker actually uses the rasterizer origin bit instead of changing the
>> viewport and applies no transformation to the fragment coordinate
>> whatsoever.
> 
> I'm not sure how much that simplifies in the end. If the drivers need to resort to uniforms to deal with all combinations, then how will making the gl_Fragcoord/viewport transformation depend on lower_left_origin simplify things? 
> 
> Is it really true that for all hardware gl_FragCoord will depend on the lower_left_origin rasterizer state?
> 

I don't know about all hardware. R600 doesn't have that origin switch,
but the half-integers switch might have an effect.

My suggestion about letting the driver modify the coordinate was to
avoid having a dependency in the gallium interface between the shader
setting, or worse, yet another cap about whether it exists.

The only (small) issue is, if a driver does handle the origin switch and
compensates for the effect on FragCoord, and the state tracker decides
to not use that switch and just flips the viewport, it has to do its own
transformation on FragCoord, we get to do 2 transformations.

> Finally, I think this is precisely what Marek was concerned; so to allow existing drivers to opt out from having to deal with this, we'll need a cap.

Which is, I guess, why we have to add both versions depending on a CAP
once again, i.e. for some drivers the origin switch in the rasterizer is
used (nouveau at least; this should affect the edge rule; I think I
looked for an independent switch way back and didn't find one) and for
other drivers the viewport is flipped in combination with changing a
separate edge rule rasterizer state.
Maybe some drivers even support both (independent change of edge rule
and origin) ...

> 
> 
> That said, I don't oppose any of this if it make HW driver implementer lives easier.
> 
> But how seriously/quickly are you and other hardware drivers maintainers actually aiming at implementing this? I don't wanna go through all that trouble if nobody will care.
> 

Well, there's not much code (in terms of lines) to write on the driver
side, but code that uglifies things always takes a bit longer to become
comfortable with ...

> 
> Either way, I think that this patch series already is a good improvement over the ugly "one-bit-fit-all-needs" gl_rasterization_rules state, and should cause no regressions whatsoever.  I'd like to tackle the "entanglement" of lower_left_origin with other bits of state in a follow-on gallium change after there is a clearer understanding/consensus if/how will HW implement this.
> 
> Jose
>