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

[Ben Gamari]

On Mon, Aug 03, 2009 at 04:12:22PM +0100, Barry Scott wrote:
> We think that the problem is that the GPU is basically serially
> reused. Only one window at a time gets GPU resources. This means that
> when the compositor creates the next frame and uses glxSwapBuffers to
> draw to screen the GPU goes idle waiting for the scan out line to be
> outside the visible area before doing the swap.  All others windows
> block in X waiting for the GPU resource to be free.

I believe you could test this by disabling vblank synchronization in
driconf. Would definitely be a worthwhile thing to try.

> 
> What we think needs to happen is the Intel driver/X11 needs to be able
> to allow some parallel execution on the GPU. For example a movie
> player should be able to use XV to write out the next frame of video
> in parallel with compositing writing the composited frame. And we have
> applications that want to composite 9 movie players on to the screen,
> so would like all 9 in parallel if the hardware can do it.

Yeah, sync to vblank seems to be pretty tricky. I don't know much about
the intel driver's implementation of it, but from what I understand, we
definitely aren't using the hardware optimally. I know that the hardware
does have multiple context support, but
  a) I'm not sure whether that would help solve the vblank issues.
     It seems that the only way to change contexts is with the
     MI_SET_CONTEXT command. This means that the GPU would still need to block
     before a flip.

  b) It would take quite a while to hack such support into the drm

Unfortunately, jbarnes seems to know the most about the vblank situation
(he wrote most of the code IIRC) but is on vacation until Friday (I
think). Try disabling vblank sync as I suggested above and see if things
improve at all.

Cheers,

- Ben