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

[Christoph Bumiller]

On 21.04.2013 09:36, Jose Fonseca 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.

I have a switch for the upside down thing, but maybe it could be
framebuffer state instead of rasterizer state (since it's going to
either not change (D3D) or only change with the famebuffer, and I have
to set WINDOW_OFFSET_Y to 0 / fb height depending on the setting of Y
direction (the latter won't work with MRTs, but that's the non-FBO case
anyway)) ?

R600 seems to have PA_SU_VTX_CNTL.PIX_CENTER but no state to change the
window origin / direction ... and I'd rather not have to bother with it
myself either.

Also, note that this state and the pixel center one might (or maybe I
should say will) affect the values of hardware's gl_FragCoord and hence
PIPE_CAP_TGSI_FS_COORD_ORIGIN/PIXEL_CENTER*, i.e. the shader
transformation of that input must be adjusted according to this state.
I'd probably be OK with making this the driver's task.

> 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?
>
>
> If drivers don't provide this state, the only way to workaround it I know would be to store textures (or drawables?) up-side down, and flip them on gl(Get)TexImage & friends.  This would be like using a cannon to shoot a fly (a lot of work and a lot of overheads for a small correctness detail).  I think the drivers are better equipped to handle this.
>
> And you always have the option of merely ignoring this state.  Top-left rule correct rasterization has, after all, been ignored till date, and nobody cared.
>
>
> For the record, my motivation here is simple: llvmpipe gets the right behavior on GL drawables, and fails on GL FBOs & D3D 9/10. I want to get the right behavior on D3D 9/10 without causing regressions on GL drawables.
>
> BTW, I'd imagine that if hardware rasterizer behavior is hardcoded to anything, it would be to D3D 9/10 behavior. That is, they would get GL FBO right, but drawables wrong.
>
>
> Jose
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev