Intel's Mesa Driver Is Going Faster For Unigine

[phoronix]

Phoronix: Intel's Mesa Driver Is Going Faster For Unigine

Eric Anholt at Intel has a new Mesa GLSL patch to add a new pass for their compiler that decreases the number of instructions and can result in performance improvements...

http://www.phoronix.com/vr.php?view=MTQ4OTk

[ciplogic]

CSE stands for Common Subexpression Elimination not Constant Subexpressio Ellimination

If you have:

a = b+c
d = b+c

The code will become

e = b+c
a = e
d = e

In rest, it is great to have such of a great impact in this "real life" benchmark.

[smitty3268]

Not quite the whole story.

I'm guessing Eric is looking at optimizing tropics now because of a recent Intel regression:

Hi Eric,
>>> The frame rate of Unigine Tropics (with low shader quality) dropped
>>> from 40.8 to 23.5 after this change.

So while common optimizations like this are great for everyone, there's still a big regression and it's likely this change won't be that big for other drivers. Especially r600g, which already has a bunch of optimizations like CSE running in their own driver already.

[Kayden]

So while common optimizations like this are great for everyone, there's still a big regression and it's likely this change won't be that big for other drivers. Especially r600g, which already has a bunch of optimizations like CSE running in their own driver already.

We have CSE in the i965 backend as well, but it doesn't handle texturing operations at the moment. Those are obviously the most expensive operations, so it's important to handle. Of course, most people don't write redundant texture lookups, either.

According to I965Todo, Unigine Tropics has a texturing operation in a loop which is actually loop-invariant. The core compiler doesn't yet implement decent loop-invariant code motion techniques, so it just goes ahead and unrolls the loop, duplicating the texture lookup many times.

If r600g has support for CSE on texturing operations, then it might already recover from this problem in the core compiler. Otherwise, it'll probably benefit too.

[curaga]

Why are drivers working around the GLSL compiler, instead of things being fixed in one place?

[bridgman]

Why are drivers working around the GLSL compiler, instead of things being fixed in one place?

AFAIK Eric did implement this at the GLSL compiler level, ie as an additional optimization performed on GLSL IR before being passed to the drivers.

[curaga]

Aye, but it's been in r600sb for months.

[smitty3268]

Why are drivers working around the GLSL compiler, instead of things being fixed in one place?

The GLSL compiler isn't the only place generating code that the drivers might want to optimize. It's certainly an important one, but for example, the OpenCL code completely bypasses it. Do you want optimizations like this in every API front end? Or in every hardware backend? I'm not entirely sure, but if you can put it in the driver backend there's probably a good chance it will help you out somewhere, sometime.

[curaga]

That's a good argument for having it in both places. Still, it means there's two places, and each will have optimizations the other will not, because people only work on one.