Yes, that particular part of the spec is fairly Poulsboriffic. Does any open hardware have a scissor enable/disable bit? Sending from a mobile, pardon the brevity. ~ C. On Oct 12, 2010 8:47 PM, "Dave Airlie" <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote: > On Wed, Oct 13, 2010 at 1:07 PM, Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote: >> On Wed, Oct 13, 2010 at 12:07 PM, Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote: >>> I've noticed that none of the blitters use scissor state, and wondered >>> if there was a reason for this. >>> >>> It looks like drivers are expected to setup scissor state in the >>> framebuffer setup and in the set scissor state, but with r600g due to >>> the underlying state tracking it can end up doing the wrong thing. >>> >>> The 3 patches add CSO cache + u_blit + u_blitter scissor usage. >>> >>> Just wondering if I'm violating some rules of the gallium interface or not. >> >> I realised this was a quite deep hole I started digging in mesa/st, >> any advice on whether cleaning it up is a good idea? >> > > Okay so it helps to read the docs, since it the scissor state enable > relies on a bit in the rasterizer state. > > So it looks like we should always set scissor regs in the framebuffer > state and only modify them if we notice > the rasterizer bit is enabled. > > Dave. > _______________________________________________ > mesa-dev mailing list > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>