[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.8.0

[Ben Gamari]

On Mon, Aug 03, 2009 at 05:27:46AM -0400, Clemens Eisserer wrote:
> > Unfortunately real games are still not playable, way slower than the proprietary windows drivers.
> I wonder why there's always immediate slience by intel-devs when this
> topic comes up.

Because unfortunately there are still more pressing matters than OpenGL
games. There are still stability and correctness issues with even basic
OpenGL usage, so expecting great performance is a little unrealistic.
Indeed, even 2d acceleration could use a lot of work at this point.

> The current opengl implementation is hardly useable for anything but
> composition and clutter ;)

Yep, quite true. I would argue that even for these it's pretty pathetic.
Unfortunately, it's a matter of developer time. Keep in mind that we
have just barely finished a massive architectural rework of the graphics
stack (on that note, thanks for your patience).

Now that we have for the most part finished, however, more and more
brain cycles are being spent on thinking about performance. Chris Wilson
has done an amazing job implementing some performance monitoring
functionality in the kernel, which should certainly help pinpoint
issues. Furthermore, Carl Worth has been doing some great work on
looking at cairo performance. As I said earlier, 2d still has some
performance issues which will generally take priority over 3d issues.
There have also recently been discussions on putting infrastructure in
place for automatic performance characterization. This should help us
better understand driver performance trends and avoid many performance
regressions.

> 
> If it would help I could compile and endless long list of OpenGL
> applications that perform at least twice as good on Windows, or file
> bug reports app by app?

A list wouldn't really help too much except for making developers feel
bad. ;) We'd need at very least a set of profiles.

Are these applications mostly closed-source games running in Wine? These
might be slightly harder to optimize for: For one, the presence of an
emulation layer could make things significantly harder.  Secondly,
closed source is always more of a challenge --- it makes it far easier
when you can see exactly what the application is asking the driver to do
and add instrumentation as needed. 

The easiest place to start would be with pure OpenGL open-source games
running natively. There is a good chance that fixing performance issues
on these applications will also improve performance on your closed
source games and they would be significantly easier to analyze.

When you find a performance issue, you should first determine whether
CPU usage is high. If it is, that means we have found a driver
inefficiency on the CPU side (perhaps a fallback or something along
those lines). If CPU usage is low, then we are GPU-bound, which could be
a bit trickier to identify (unfortunately, we don't have much
infrastructure in place yet for GPU performance monitoring).

If the application is CPU-bound, you should include a profile for both
user- and kernel-mode with your bug report (sysprof from git works well
for this).

In the event that we're GPU bound, I don't even know what other
information you could include. Anyone have any ideas? GPU-bound cases
would require more in-depth analysis of exactly how we're using the
hardware. Unfortunately, I don't think we have any mechanisms for
profiling on the GPU (right?). If we begin running into GPU-bound issues, we're
going to need to start thinking about this.

Anyways, I hope this helps. Sorry that it has taken so long to get to
where we are today, but things are looking up. We're finally through
most of the restructuring and now we can finally begin focusing on
optimization.

Cheers,

- Ben