[Mesa-dev] [PATCH 2/2] gallium: Replaced gl_rasterization_rules with lower_left_origin and half_pixel_center.
Christoph Bumiller
e0425955 at student.tuwien.ac.at
Sun Apr 21 03:42:04 PDT 2013
On 21.04.2013 12:34, Dave Airlie wrote:
> On Sun, Apr 21, 2013 at 5:36 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> ----- Original Message -----
>>> Do we really need the lower_left_origin state? I think I can't
>>> implement it for radeon and it's the kind of stuff that should be
>>> taken care of by the state tracker anyway.
>> My understanding is that hardware had switches for this sort of thing. It's really hard to provide fully-conforming rasterization for opengl, dx9 & dx10 without it.
>>
>> If your hardware allows to put a negative pitch on rendertargets, then that should also do it.
>>
>> If you know what is the hardware's sub-pixel rasterization resolution, then adding a vertical bias equal to that amount, depending on this state, would give a very close approximation. (This would get the top/bottom edges right, at expense of small inaccuracies on non-horizontal edges)
>>
>>> Isn't it sufficient to just
>>> set a viewport which is upside down, like we do now?
>> I'm not aware of rasterization top-left rule being affected by the viewport flipping.
>>
>> Do both
>>
>> ./bin/triangle-rasterization -auto
>> ./bin/triangle-rasterization -use_fbo -auto
>>
>> currently work for you?
>>
> just FYI, on my evergreen, the first fails the second passes, maybe
> someone could try on fglrx, I'd be sorta willing to guess AMD hw just
> does DX10 :)
>
> and I think I've heard some complaints about our rendering offseting
> being wrong somewhere in the past on r600.
Same on nouveau. On NV blob it's the other way around, it fails for
-use_fbo. So clearly, both can work.
> Dave.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list