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

[Barry Scott]

Ben Gamari wrote:
> 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.
>   
Rather then do this what we did was use XRender instead of OpenGL to 
composite
and we turned off XV tear free feature via the XV attribute. Then we use
DRM VBLANK ioctl to time the frames for compositing.

This allows us to composite at 60 frames/second and be almost always
tear free. (Almost because of the well know problem with intel graphics
chips not having an accurate vblank interrupt).

>   
>> 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.
As we understand it sync to vblank is old tech, new tech is the scan 
line based
methods. The tear free XV video and glxSwapBuffers being examples in
the intel driver.
>  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
>   
We reached a similar conclusion.

Barry