On Mon, 2010-11-15 at 01:32 -0800, Keith Whitwell wrote: > On Mon, 2010-11-15 at 01:28 -0800, Keith Whitwell wrote: > > On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote: > > > Eric just checked in a test into piglit that tests that the > > > gl_FragCoord works the right way up for FBOs, > > > > > > Now all the gallium drivers fail this currently and fixing it creates > > > an ugly linkage between the currently bound buffer and the fragment > > > shader, since if you swap from an FBO to rendering to the front > > > buffer, you need recompile the fragment shader to emit a proper wpos > > > manipulation. Just wondering if anyone sees a nicer way to do this, > > > than caching frag shaders with some sort of key in the state tracker, > > > (which is pretty much what 965 has done.). > > > > I guess the other possibility would be to have a couple of constants in > > the constant buffer which get factored into the fragcood calculation in > > such a way as to effect a flip based on their value, eg: > > > > fc' = fc * const[0].x + const[0].y > > > > where const[0] is either > > -> {1, 0} for non-flipped > > -> {-1, fb_height} for flipped > > Another question is how to tell the pipe driver which of these to use -- > probably we want an explicit flag in one of the state atoms > (rasterizer?) to select between the two possibilities?
...hmm need more coffee. Of course you'd do this at the state tracker level (as you detailed) & the pipe drivers wouldn't need to think about it... Keith _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev