----- Original Message ----- > 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.
This really just affects a corner cases -- where edges are perfectly horizontal and go precisely through the pixel center -- but there might be apps out there that draw a lot of screen aligned rectangles, and end up hitting this more often than one would imagine. (For example, GL based UI/HTML rendering engine at 50% zoom). > Same on nouveau. On NV blob it's the other way around, it fails for > -use_fbo. So clearly, both can work. Interesting. Whenever I tested with NVIDIA proprietary drivers (and I did it on more than one driver version / hw), both cases always passed. This is what I just tested: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro K1000M/PCIe/SSE2 OpenGL version string: 4.3.0 NVIDIA 310.14 OpenGL shading language version string: 4.30 NVIDIA via Cg compiler Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
