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

[Barry Scott]

Eric Anholt wrote:
> On Fri, 2009-07-31 at 16:03 +0100, Barry Scott wrote:
>   
>>
>> 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.
>>     
>
> It sounds like your problem is a little more complicated than what
> you're describing.  If you've got just one app, it can spend just under
> a frame's worth of time preparing a new frame, and just spend the
> remainder of that frame waiting for the GPU to be outside of vblank to
> do the swap.  It's working great for full-screen games.
>   

> But your environment has two applications: a compositing manager that
> just blits and waits for vblank (almost no time preparing its frame),
> and a movie player that actually needs to get some work done to prepare
> its frame.  So, depending on who wakes up when, your movie player
> doesn't get to draw its frame in time because the compositor woke up,
> drew something cheap, and sent the GPU to sleep waiting to blit it.  I'd
> expect stuttering in this environment currently.
>   

In reality we have many apps, firefox, xine, imlib2 and some custom text
scrolling apps running at the same time. Its not uncommon for us to want to
composite 20 apps output.

> We would certainly love to keep the GPU running flat out, but right now
> we have no tearing and we're going to stick with that until we get
> something better in.  jbarnes and krh at least have been working on
> adding DRI2 pageflipping support, so if your compositor uses SwapBuffers
> as opposed to CopySubBuffer (the previous recommendation for
> compositors, sorry for changing our minds), the GPU will be able to keep
> running because the page flip happens independently of the ringbuffer
> operation.  I'm guessing this will be in the 2.6.32 timeframe
Its good to hear that you want to load up the GPU. Having the page 
flipping not
block the ring will go a long way to helping our work load.

We will watch for the page flipping code to land and then optimize our
compositor against the 2.6.32 behavior.

Barry