Marek,
On Tuesday, May 03, 2011 01:33:17 you wrote:
> 2011/5/2 Mathias Fröhlich <mathias.froehl...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
