On Mon, Jul 23, 2012 at 11:42 PM, Jerome Glisse <j.gli...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
