Yes, kernel is different. I'm more reserved in this regard. I usually track the drm-fixes (~airlied) branch which most of the time means that it at least somehow works. Yet I make sure to have at least one additional kernel installed that I can boot into if the drm-fixes branch breaks for me.
Mesa version does not metter for me, bug is somewhere in kernel all i can say 3.13 is OK, and this regression is present even in first 3.14-rc1 .
Nope this halfed performance cant be just from disabled hyperz .
I thinked it is just for very oldish hardware, but glad to see all affected so seems like this will be fixed
actually until very recently the open source drivers would lock up my system using the radeon si opensource drivers. the performance is getting better on radeonsi just not quite there and power management is spotty. Catalyst has it's issues but i have been lucky, seriously can't wait for the OS driver to replace the blob but i wish you people wouldn't just dump on the blob. All I see are parrots, all I hear is birds.
amd dev's made meta bug for hyperz:
bug no 75112
and i don't think they fix it fast.
you are my heroLooks like you talking about AMD Cataclysm.
" We need to figure out what combination(s) of GL state cause a problem with hyperZ, then either disable hyperZ in those cases, or adjust the hyperZ-specific state to avoid the hang in those specific cases. Ideally we'd be able to find a small test case where we can reproduce the issue(s)."
From my angle when i know it was bugged also in r200 and also disabled by default in mesas from UMS time, and when i read what people now says it is clearly lighting state .
So maybe developers may enabled it by just disable it for lighting i think .
kernel or mesa?
Well, i hope it is the same, because then we might see it get fixed and have everyone's performance go back up.