Am 27.06.2014 04:31, schrieb Michel Dänzer:
On 25.06.2014 12:59, Michel Dänzer wrote:
On 24.06.2014 19:14, Christian König wrote:
Am 24.06.2014 08:49, schrieb Michel Dänzer:
On 23.06.2014 18:56, Christian König wrote:
Am 23.06.2014 10:15, schrieb Michel Dänzer:
On 19.06.2014 18:45, Christian König wrote:
I think even when we revert to the old code we have a couple of
unsolved
problems with the VM support or in the driver in general where we
should
try to understand the underlying reason for it instead of applying
more
workarounds.
I'm not suggesting applying more workarounds but going back to a known
more stable state. It seems like we've maneuvered ourselves to a rather
uncomfortable position from there, with no clear way to a better place.
But if we basically started from the 3.14 state again, we have a few
known hurdles like mine and Marek's Bonaire etc. which we know any
further improvements will have to pass before they can be considered
for
general consumption.
Yeah agree, especially on the uncomfortable position.
Please try with the two attached patches applied on top of 3.15 and
retest. They should revert back to the old implementation.
Unfortunately, X fails to start with these, see the attached excerpt
from dmesg.
My fault, incorrectly solved a merge conflict and then failed to test
the right kernel.
[...]
Please try attached patches instead,
With these patches, 3.15 just survived two piglit runs on my Bonaire,
one with the GART poisoning fix and one without. It never survived a
single run before.
Acked-and-Tested-by: Michel Dänzer <michel.daenzer@xxxxxxx>
So, are these patches going to 3.16 and 3.15?
We could send them in for 3.15, but for 3.16 we have some new features
that depend on the new code.
We could backport them to the old code, but I really want to work on
figuring out what's wrong with the new approach instead.
Going to prepare a branch for you to test over the weekend, would be
nice if you could give it a try on Monday and see if that fixes the
issues as well.
Thanks,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel