Comment 7 for bug 195843

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.