2011/5/3 Mathias Fröhlich <mathias.froehl...@gmx.net>:
>
> 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.
As noted in the r6xx/r7xx programming guide, SURFACE_BASE_UPDATE
packets are required on rv6xx for the cp surface sync logic to work
correctly. I suspect you are seeing the results of that.
Alex
>
> 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
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
