----- 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 <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? > > > > > > 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
