[Mesa-dev] r600g on rv635 and broken mipmaps

[Mathias Fröhlich]

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 will look into alex note today evening.

Greetings

Mathias