On 21.04.2013 12:34, Dave Airlie wrote: > On Sun, Apr 21, 2013 at 5:36 PM, Jose Fonseca <jfons...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
