BTW I'd also like to get this to 7.9 if there are no concerns. Marek
On Thu, Dec 2, 2010 at 9:33 PM, Marek Olšák <mar...@gmail.com> wrote: > Hi, > > the attached patch fixes this gl_FragCoord madness. It uses a fragment > shader constant to do the transformation and the constant is set > transparently with other STATE_* constants in Mesa core. The changes are > quite small. Please review. > > Best regards > Marek > > > On Mon, Nov 15, 2010 at 10:28 AM, Keith Whitwell <kei...@vmware.com>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 >> >> Keith >> >> >> _______________________________________________ >> 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