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@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
