With Unigine OilRush now officially shipping, there's now a popular multi-platform game using the Unigine Engine so handling the engine by Mesa/Gallium3D is now a bit more important than to just ensure the Linux drivers can run a couple tech demos (Unigine Sanctuary, Tropics, and Heaven).
Some enthusiasts have had mild success getting the more-demanding Tropics and Heaven demos running on Mesa when enabling the patented Mesa floating-point support, using the external S3TC texture compression library, and making other changes. However, the performance is still sub-par and not nearly as good as the binary graphics drivers from AMD and NVIDIA, which are even extensively stressed using this impressive game engine.
Earlier this week support for Mesa to handle application workarounds was brought up by the open-source graphics developers. Besides putting the infrastructure in place to handle application-specific overrides within Mesa, Intel developers did this support so they could workaround a Unigine Engine bug.
When Unigine OilRush v1.0 shipped the Mesa support wasn't good and the Unigine Corp developers were aware of the situation. It was brought up on the Mesa mailing list to decide what should be done about the broken Unigine support in regards to its GL_ARB_draw_instanced usage. After seeing this, I personally brought the issue up with Unigine Corp to see it would be properly resolved.
In time for anyone wishing to do some weekend gaming, Unigine Corp released version 1.01 of OilRush. Besides addressing some memory leaks, level loading speed, and a couple of other fixes, there is also "Better compatibility with Mesa on Linux (improved support of open source video drivers)."
For a separate issue, Eric Anholt on Friday published an Intel Mesa DRI patch that fixes some corrupted rendering within Unigine Tropics on their Sandy Bridge hardware. There's also other work going on too for seeing that Unigine plays on Mesa.
While running the Unigine Engine on Mesa is becoming more viable at least with the lowest quality settings, the OpenGL frame-rate performance will still be a big problem. You can see the many Linux GPU driver benchmarks on Phoronix to see how the hardware/driver combinations are currently performing for some of the common Linux-native OpenGL workloads.