[Mesa-dev] r600g on rv635 and broken mipmaps

[Dave Airlie]

2011/5/3 Mathias Fröhlich <Mathias.Froehlich at gmx.net>:
>
> Marek,
>
> On Tuesday, May 03, 2011 01:33:17 you wrote:
>> 2011/5/2 Mathias Fröhlich <Mathias.Froehlich at gmx.net>:
>> > I have again spent some more tries with different kinds of flushes on the
>> > rv635. What helps for the mipmap problem here is emitting a
>> > texture_barrier as well as flushing anything that covers the whole
>> > memory range and more than two arbitrary color buffers. !?!
>>
>> The texture barrier in u_gen_mipmap seems to be the proper fix
>> (texture_barrier can be NULL on other drivers though), but we should
>> first make sure it wouldn't be hiding a bug elsewhere (see Alex's email).
>
> Hmm, I am not sure about this. I already had that patch also.
>
> Correct me when I am wrong:
> In u_gen_mipmap, we call cso_set_framebuffer, which I expect to be aequivalent
> to switching rendering outputs to a different fbo. When I do the aequivalent
> from OpenGL level, I expect to have everything available from the previous
> bound fbo without the need for the texture barrier extension (I don't recall
> the exact name). True?
>
> Which led me to the to the conclusion that I do not want to use an explicit
> texture barrier in this case but need to have something that flushes implicitly
> on setting a new framebuffer state.
> True?
>
> That would have the advantage that we already know what bo range to flush
> instead of just the whole gpu memory like it is done and required for the
> texture barrier.
> That this does not work for the rv635 does not imply that other chips/drivers
> cannot make use of this additional knowledge.
> ... my two cents.
>
>
> Appart from my current expectation about the implicit flush semantics on the
> framebuffer state, some notes on what flush works and what not:
>
> The reason that the texture barrier works for me, is - by experimental
> software development - that the texture barrier flushes the whole memory range
> with the
>
> S_0085F0_TC_ACTION_ENA(1) | S_0085F0_CB_ACTION_ENA(1) |
>                        S_0085F0_CB0_DEST_BASE_ENA(1) |
> S_0085F0_CB1_DEST_BASE_ENA(1) |
>                        S_0085F0_CB2_DEST_BASE_ENA(1) |
> S_0085F0_CB3_DEST_BASE_ENA(1) |
>                        S_0085F0_CB4_DEST_BASE_ENA(1) |
> S_0085F0_CB5_DEST_BASE_ENA(1) |
>                        S_0085F0_CB6_DEST_BASE_ENA(1) |
> S_0085F0_CB7_DEST_BASE_ENA(1)
>
> bits.
> If I do the same in r600_context_flush_dest_caches instead of the cache flush
> and invalidate and reduce the flags to say
>
> S_0085F0_CB_ACTION_ENA(1) |
>                        S_0085F0_CB0_DEST_BASE_ENA(1) |
> S_0085F0_CB1_DEST_BASE_ENA(1)
>
> It works for me also, but
>
> S_0085F0_CB_ACTION_ENA(1) |
>                        S_0085F0_CB0_DEST_BASE_ENA(1)
>
> does not work.
>
> But that puzzled me. Note that there is no S_0085F0_TC_ACTION_ENA(1) enable in
> there, and also there is no second color buffer while rendering mipmaps to
> flush. Also the colorbuffer bo's are already flushed explicitly for their bo
> range in r600_context_flush_dest_caches with their apropriate flags and ranges.
>
> The observation was that as long as I have at least 2 arbitrary colorbuffer
> bits included in this PKT3_SURFACE_SYNC and the flush covers the whole gpu
> memory range, the mipmaps are correct. Setting any other
> {SMX,TC,VC}_ACTION_ENA(1) flags just did not matter for my setup.
>
> 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.

Dave.