Christoph Bumiller wrote: > Michel Dänzer schrieb: >> On Tue, 2009-07-28 at 16:47 -0700, Ben Skeggs wrote: >>> Module: Mesa >>> Branch: master >>> Commit: d1b9183e64e819d389688074c3db338bd0d2d80e >>> URL: >>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=d1b9183e64e819d389688074c3db338bd0d2d80e >>> >>> Author: Christoph Bumiller <[email protected]> >>> Date: Wed Jul 29 01:21:41 2009 +0200 >>> >>> nv50: fix viewport transform >>> >>> The translation also needs to be inverted, and in bypass mode >>> the state tracker incorrectly assumes that Y = 0 = TOP, so we >>> need inversion there to; NDC clipping has to be deactivated >>> explicitly. >> If there's indeed an incorrect assumption in the state tracker, that >> should be fixed, rather than working around it in drivers. >> >> Note that it's my understanding that as far as a Gallium driver is >> concerned, Y=0 always corresponds to the start of the renderbuffer. >> Anything else is up to the state tracker. >> >> > To me it looks like if you pass coordinates to the nv50's 3D engine, > you have the coordinate origin at the bottom left (which is not the > start of memory), which is the reason for all the inversion. > > When drawing a quad in bypass mode with the default framebuffer, you > have st_fb_orientation == Y_0_TOP, so if you want to, say, clear the > top half of the screen, the state tracker will submit vertices with > y = 0 and y = h/2, which turns out wrong if we deactivate the viewport > transform. > > Summarized, if the hardware has the window coordinate origin at the > bottom left, the pipe driver is responsible for correcting that, so > I guess the line 'state tracker incorrectly assumes' is probably not > well formulated. > > Or maybe I'm wrong and there's another reason why stuff appears upside > down only on nv50 when using the unmodified viewport parameters ...
In any case, I double-checked the state tracker and everything looks OK there. The gallium viewport is specified such that (0,0) is the upper-left corner of the surface. One place where upside down rendering has been a problem is with rendering to FBOs vs. the regular framebuffer. But the state tracker should be taking care of this so that gallium drivers don't have to care. It's possible there's still a bug somewhere but this stuff has been pretty well tested by now. -Brian ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
