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

[Barry Scott]

Carl Worth wrote:
> On Fri, 2009-07-31 at 10:10 +0300, Timo Jyrinki wrote:
>   
>> Hi. Thanks for the release. It seems to be now quite stable after all
>> the KMS/GEM/DRI2/UXA hassle, I'm happy to say (and so are / will be
>> the other users).
>>     
>
> You're quite welcome. I'm happy to hear that the driver is performing
> well for you.
>
>   
>> However, Intel is getting its worth of bad publicity because of all
>> the stability problems (now addressed) and performance problems (only
>> getting worse). Could there be at least some blog post analysis about
>> what's going to be done about performance?
>>     
>
> I did recently make a blog post about performance measurement at least:
>
> 	http://cworth.org/intel/performance_measurement/
>
> The point I make there is that microbenchmarks like gtkperf don't really
> tell us what happens with real applications.
>
>   
>> Newest Phoronix numbers just in:
>> http://www.phoronix.com/scan.php?page=article&item=intel_q309_flakes&num=2
>> - Ubuntu 9.10 (2.6.31, 2.8.0, 7.5) is much slower, even double in some
>> tests, than Ubuntu 9.04 (2.6.28, 2.6.x (EXA), 7.4). And Ubuntu 9.04,
>> where GEM was introduced, was already 2x slower than Ubuntu 8.10/8.04
>> (intel 2.2-2.4 / EXA / no GEM) in many important areas.
>>     
>
> What I see there is lots of gtkperf microbenchmarks, which as I put
> forth in the blog report, don't capture realistic application behavior.
> So there may or may not be any real performance problem based on those
> numbers. It's really hard to know.
>
> I'm not really familiar with Qgears nor JXRenderMark but they also sound
> like microbenchmarks, (with names like "Transformed Blit Bilinear").
>
> I do appreciate that people are performing benchmark measurements on our
> various releases, but I'd much rather see a result like:
>
> 	"Firefox is 20% slower with 2.8.0 compared to 2.6.3" or so.
>
> That's something that would indicate an actually significant performance
> problem and would be much more compelling to result in work to fix it.
> And the cairo-perf-trace tool I describe in the blog post above provides
> results exactly like that, (for firefox, gnome-terminal, evince, etc.
> and anyone can generate traces for any other cairo-based applications).
>
> And of course, I'd even much rather see reports from cairo-perf-trace
> showing performance improvements rather than slowdowns. :-)
>
> Either way, I will look forward to measurements based on real-world
> loads. And I can say that with the huge architectural reworks behind us,
> and some serious stabilization done, performance issues are very near
> the top of the list for several of us working on Intel graphics drivers.
>
>   
What we see is glxSwapBuffers cannot run at 60 frames a second in the 
real world.
It drops between 30% and 50% of frames, making smooth animation impossible
in a compositing environment.

 From what we can see this is down to the GPU being throttled and not lack
of CPU or GPU resources.

What we think is the cause is this: The GPU will be programmed to wait until
the scan out is outside of the viewable area before the glxSwapBuffers 
can complete.
Because the GPU is doing this any drawing to other windows are blocked until
the swap completed. Now if what has been blocked is the creation of the 
next frame
it leaves a very small amount of time before the next frame needs to be 
drawn.

You see the same problem with the XV "tear free movie" feature. The GPU 
spends
most of the time waiting for the scan line to get outside of the 
viewable area.

As yet we have not finished reading the GPU docs to be sure of what the 
hardware
can do to avoid this single threading GPU use. However it seems that the 
hardware
can be programmed to run batch buffers in parallel. It would seem that 
something
like this is required to fix the class of performance problem that we see.

Barry