Since it seemed curious that upstream would not just make this parameter the default, I inquired as to possible side effects or hidden bugs that this parameter might trigger. Here is Eric Anholt's response, via Rolla:
"I seem to recall that there were some issues with cliprect handling with INTEL_BATCH or something, and I may have had concerns with synchronization with it. I remember that quick inspection said that leaving it disabled was the right thing to do. It's irrelevant now anyway, as that path is replaced in TTM mode, and we're doing the equivalent code even in non-TTM. Not dumping all of your commands into the ring saves a copy and allows greater concurrency, leading to performance improvements. Of course, we also expose other bugs (poorly implemented hang-detection timeouts) by allowing greater concurrency, and that's among the stuff we're working on fixing in master. So, setting INTEL_BATCH now in old mesa would probably be a bad idea for that reason alone, ignoring the other reasons I seem to remember with that specific implementation of the batch buffer idea." So, it sounds like there may be corner cases where this setting would bring instabilities. I'm not sure it's worth taking that risk for Hardy. But I'll leave this bug open in case folks wish to research it more thoroughly. What I'd like to hear is if people try out this setting and it causes a bug. We don't need more confirmation of the performance effects. -- INTEL_BATCH=1 should be enabled per default for Intel graphic hardware https://bugs.launchpad.net/bugs/195843 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
