[Mesa-dev] gl_FragCoord / FBOs vs mesa/st

Keith Whitwell keithw at vmware.com
Mon Nov 15 01:57:31 PST 2010


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



More information about the mesa-dev mailing list