[Mesa-dev] r600g on rv635 and broken mipmaps
airlied at gmail.com
Wed May 4 21:57:27 PDT 2011
2011/5/5 Dave Airlie <airlied at 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".
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1033 bytes
Desc: not available
More information about the mesa-dev