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

[Jose Fonseca]

----- Original Message -----
> Same as Dave. The first one fails, the second one (-use_fbo) passes.
> 
> I just hope lower_left_origin doesn't affect the Y axis of the
> viewport, scissor and gl_FragCoord. If it does, a PIPE_CAP would be
> useful to keep the current behavior.

Maybe I'm not explaining myself properly -- one can keep the current behavior merely by ignoring the lower_left_origin bit -- so I really don't see any need for concern.

> Marek
> 

Jose


> On Sun, Apr 21, 2013 at 9:36 AM, 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?
> >
> >
> > 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
>