On Mon, Nov 15, 2010 at 4:57 AM, Keith Whitwell <kei...@vmware.com> wrote:
> 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...
FWIW, r6xx+ hw has a set of shader booleans (32 per shader type)
defined in registers for toggling chunks of code in your shaders, so
you could build a shader and constant buffer to handle multiple
situations, then just update the boolean values when you need to
change what chunk of code is required. I currently use this in the
EXA/Xv code in the ddx for handling several senarios in the same
shader.
Alex
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
