2011/5/5 Dave Airlie <airl...@gmail.com>: >>> So to be honset I do not understand where the data sticks and what I need to >>> do to get it out. >>> May be that observations make sense for somebody else? >>> >> >> I've been staring at this I'm running out of good ideas, and even bad ideas. >> >> It really does seem like the TC has some invalid lines in it maybe, >> and they don't get >> invalidated. So when we render the first mipmap level it samples the >> level 0 image >> via the TC, and pulls in some of say the level 1 image, then we write >> the level 1 image >> with the CB, and go to sample the level 1 image to render the level 2 >> image. That >> sampling of the level 1 image fails, because although we've flush the >> dest cache, >> we haven't flushed the texture src cache. >> >> However saying that I can't find a secret incantation of flags to put >> in the correct place >> to make it work. I'll keep looking at it. > > Okay my guess at the problem is that: > > the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely > on the base in the CB being the same as the texture BASE which it won't > be in the case where we are rendering to mip sublevels. Though I've no idea > how to workaround this without explicit flushes.
Still in fail land here, I also tried to play with this on my RV670 (x2 card), and I couldn't find a working r600g at all on this card in terms of passing fbo-generatemipmaps, so I think we've had a long term problem and SBU fixes may have just covered it up in some cases. Similiar to other debugging emitting CB1 + flush all works on this card as well. The attached patch makes it all "happy". Dave.
hack
Description: Binary data
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
