i915: video questions.

2010-07-24 Thread Krzysztof Halasa
Hi,

I wonder how should I do the "video sync" on i915+ hw properly. Should I
expect Xvideo (with XV_SYNC_TO_VBLANK activated) to actually sync to the
vertical refresh (i.e., Xvideo wouldn't be playing more frames than
Vsync), or should it only eliminate the tearing problems (screen data
not altered when displayed)?

For now, XV_SYNC_TO_VBLANK means the processing is halted with
MI_WAIT_FOR_PIPEx_SCAN_LINE_WINDOW. This IMHO means multiple frames can
be processed (= displayed) as long as the CRTC is scanning outside the
video window region. It doesn't mean there will be exactly a single
video frame displayed for a single CRTC output frame.
This is great for e.g. games, but not exactly for video. Should it stay
this way?


Also, there is this DRM_IOCTL_WAIT_VBLANK which can be used to wait for
actual Vsync IRQ. Should I use this for doing Xvideo - refresh sync?
The problem is this approach requires messing with /dev/dri*, perhaps
a Xvideo-only solution is better? DRM_IOCTL_WAIT_VBLANK can be used with
GLX applications, though.

Perhaps we should create a different Xvideo attribute for the actual
tearing avoidance (or just forget the attribute and always avoid the
tearing with MI_WAIT_FOR_PIPEx_SCAN_LINE_WINDOW)? Then the
XV_SYNC_TO_VBLANK could be used for syncing (using IRQ?) with the actual
vblank.

Opinions?
-- 
Krzysztof Halasa
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com


Re: i915: video questions.

2010-07-26 Thread Jesse Barnes
On Sat, 24 Jul 2010 14:04:55 +0200
Krzysztof Halasa  wrote:

> Hi,
> 
> I wonder how should I do the "video sync" on i915+ hw properly. Should I
> expect Xvideo (with XV_SYNC_TO_VBLANK activated) to actually sync to the
> vertical refresh (i.e., Xvideo wouldn't be playing more frames than
> Vsync), or should it only eliminate the tearing problems (screen data
> not altered when displayed)?

Video is usually encoded at a frame rate less than the refresh rate, so
avoiding tearing is the most important part.
 
> For now, XV_SYNC_TO_VBLANK means the processing is halted with
> MI_WAIT_FOR_PIPEx_SCAN_LINE_WINDOW. This IMHO means multiple frames can
> be processed (= displayed) as long as the CRTC is scanning outside the
> video window region. It doesn't mean there will be exactly a single
> video frame displayed for a single CRTC output frame.
> This is great for e.g. games, but not exactly for video. Should it stay
> this way?

Correct, many frames could be generated and displayed but never shown
due to the way we wait for the scanline window.

> Also, there is this DRM_IOCTL_WAIT_VBLANK which can be used to wait for
> actual Vsync IRQ. Should I use this for doing Xvideo - refresh sync?
> The problem is this approach requires messing with /dev/dri*, perhaps
> a Xvideo-only solution is better? DRM_IOCTL_WAIT_VBLANK can be used with
> GLX applications, though.

That will only help you throttle your drawing, it won't guarantee
you'll avoid tearing, especially on LCDs where the blank time can be
very short.

> Perhaps we should create a different Xvideo attribute for the actual
> tearing avoidance (or just forget the attribute and always avoid the
> tearing with MI_WAIT_FOR_PIPEx_SCAN_LINE_WINDOW)? Then the
> XV_SYNC_TO_VBLANK could be used for syncing (using IRQ?) with the actual
> vblank.
> 
> Opinions?

I think XV_SYNC_TO_VBLANK is intended for that.  If you need something
else (like throttling to refresh) as well, we should add a new
attribute for that.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com


Re: i915: video questions.

2010-07-27 Thread Krzysztof Halasa
Jesse Barnes  writes:

> I think XV_SYNC_TO_VBLANK is intended for that.  If you need something
> else (like throttling to refresh) as well, we should add a new
> attribute for that.

Right. I will try to have something like that "shortly", thanks.
-- 
Krzysztof Halasa
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com