[Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2

Marek Olšák maraeo at gmail.com
Mon Jul 23 15:18:59 PDT 2012


On Mon, Jul 23, 2012 at 11:42 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> No, it helps on evergreen too, redwood,juniper,turks and bart are the
> only one i tested with. Evergreen is in a slightly better position but
> when it comes to lockup there is no good metrics.
>
>> Concerning older chipsets, I can do the bisection only on rs880, rv670
>> and rv730. That will have to suffice. One way or another, every single
>> change must be done for a *reason* and that reason should be
>> documented if it's not obvious. Please give me all the necessary
>> information, so that I can start bisecting. That is what lockups your
>> patch fixes and where (name apps or tests, a specific place in a game,
>> etc.) on what chipsets and whether hyperz is enabled.
>
> Sorry no such things. It just helps, pick something test with and
> without and you will see that with it lockup less often. I did not did
> any of the change in isolation to fix a single case, it's just that
> with all the change it helps.

Fair enough, but please add clearly-understandable comments describing
why each questionable piece of code is required to all the places in
the code that I mentioned in the sections (1) and (3) of my first
email. To give you just one example:

/* XXX We flush the texture cache every drawing operation on chipsets
without a vertex cache, which may decrease performance, but it helps
with hyperz lockups. */ ... before "if (!rctx->has_vertex_cache)"  in
*_flush_emit.

Only this will assure the other developers won't touch your code until
the hyperz issue is resolved completely.

Marek


More information about the mesa-dev mailing list