[Mesa-dev] r600g on rv635 and broken mipmaps

[Dave Airlie]

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".

Dave.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hack
Type: application/octet-stream
Size: 1033 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110505/8ecde123/attachment.obj>