Discussion:
[PATCH] va/x11: Require synchronisation to vblank with DRI2SwapBuffers
(too old to reply)
Chris Wilson
2015-12-24 15:42:37 UTC
Permalink
By passing divisor=0, we imply we do not care about synchronisation of
this request to the vertical refresh - the spec says that if we miss the
target frame, the swap will be presented as quickly as possible and may
forgo waiting until the next vblank. By using divisor=1, we request that
the swap be presented upon the vertical refresh immediately following
recipe, enforcing the synchronisation to vblank and avoiding tearing.

Reported-and-tested-by: Lukas Hejtmanek <***@ics.muni.cz>
Signed-off-by: Chris Wilson <***@chris-wilson.co.uk>
---
va/x11/dri2_util.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/va/x11/dri2_util.c b/va/x11/dri2_util.c
index d076fb3..9ff5e95 100644
--- a/va/x11/dri2_util.c
+++ b/va/x11/dri2_util.c
@@ -95,8 +95,9 @@ dri2SwapBuffer(VADriverContextP ctx, struct dri_drawable *dri_drawable)
if (dri2_drawable->has_backbuffer) {
if (gsDRI2SwapAvailable) {
CARD64 ret;
- VA_DRI2SwapBuffers(ctx->native_dpy, dri_drawable->x_drawable, 0, 0,
- 0, &ret);
+ VA_DRI2SwapBuffers(ctx->native_dpy, dri_drawable->x_drawable,
+ 0, 1, 0,
+ &ret);
} else {
xrect.x = 0;
xrect.y = 0;
--
2.6.4
Chris Wilson
2015-12-24 15:48:07 UTC
Permalink
Post by Chris Wilson
By passing divisor=0, we imply we do not care about synchronisation of
this request to the vertical refresh - the spec says that if we miss the
target frame, the swap will be presented as quickly as possible and may
forgo waiting until the next vblank. By using divisor=1, we request that
the swap be presented upon the vertical refresh immediately following
recipe, enforcing the synchronisation to vblank and avoiding tearing.
^receipt
-Chris with his mind on other things.
--
Chris Wilson, Intel Open Source Technology Centre
Chris Wilson
2016-11-16 09:35:43 UTC
Permalink
Post by Chris Wilson
Post by Chris Wilson
By passing divisor=0, we imply we do not care about synchronisation of
this request to the vertical refresh - the spec says that if we miss the
target frame, the swap will be presented as quickly as possible and may
forgo waiting until the next vblank. By using divisor=1, we request that
the swap be presented upon the vertical refresh immediately following
recipe, enforcing the synchronisation to vblank and avoiding tearing.
^receipt
Ping.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Sean V Kelley
2016-11-16 18:08:49 UTC
Permalink
Post by Chris Wilson
Post by Chris Wilson
Post by Chris Wilson
By passing divisor=0, we imply we do not care about synchronisation of
this request to the vertical refresh - the spec says that if we miss the
target frame, the swap will be presented as quickly as possible and may
forgo waiting until the next vblank. By using divisor=1, we request that
the swap be presented upon the vertical refresh immediately following
recipe, enforcing the synchronisation to vblank and avoiding tearing.
^receipt
Ping.
-Chris
This fell through, this is fine.

lgtm, applied.

Sean
Post by Chris Wilson
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Libva mailing list
https://lists.freedesktop.org/mailman/listinfo/libva
--
Sean V. Kelley <***@intel.com>
Open Source Technology Center / SSG
Intel Corp.
Xiang, Haihao
2016-11-17 01:22:28 UTC
Permalink
Hi,

Someone got lockup with this patch and I don't see the issue is
resolved, please check the thread below

https://lists.freedesktop.org/archives/intel-gfx/2015-December/083572.h
tml  ([Intel-gfx] vsync + vaapi question).

and this is the last response:

https://lists.freedesktop.org/archives/intel-gfx/2015-December/083862.h
tml

I will revert this patch until we root the cause.

Thanks
Haihao
Post by Sean V Kelley
Post by Chris Wilson
Post by Chris Wilson
By passing divisor=0, we imply we do not care about
synchronisation of
this request to the vertical refresh - the spec says that if we miss the
target frame, the swap will be presented as quickly as possible and may
forgo waiting until the next vblank. By using divisor=1, we request that
the swap be presented upon the vertical refresh immediately following
recipe, enforcing the synchronisation to vblank and avoiding tearing.
  ^receipt
Ping.
-Chris
This fell through, this is fine.
lgtm, applied.
Sean
Post by Chris Wilson
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Libva mailing list
https://lists.freedesktop.org/mailman/listinfo/libva
Sean V Kelley
2016-11-17 01:38:22 UTC
Permalink
Post by Xiang, Haihao
Hi,
Someone got lockup with this patch and I don't see the issue is
resolved, please check the thread below
https://lists.freedesktop.org/archives/intel-gfx/2015-December/083572
.h
tml  ([Intel-gfx] vsync + vaapi question).
https://lists.freedesktop.org/archives/intel-gfx/2015-December/083862
.h
tml
I will revert this patch until we root the cause.
Good catch Haihao, I had assumed it was resolved.

Sean
Post by Xiang, Haihao
Thanks
Haihao
Post by Sean V Kelley
o.
Post by Chris Wilson
Post by Chris Wilson
By passing divisor=0, we imply we do not care about
synchronisation of
this request to the vertical refresh - the spec says that if
we
miss the
target frame, the swap will be presented as quickly as
possible
and may
forgo waiting until the next vblank. By using divisor=1, we request that
the swap be presented upon the vertical refresh immediately following
recipe, enforcing the synchronisation to vblank and avoiding tearing.
  ^receipt
Ping.
-Chris
This fell through, this is fine.
lgtm, applied.
Sean
Post by Chris Wilson
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Libva mailing list
https://lists.freedesktop.org/mailman/listinfo/libva
_______________________________________________
Libva mailing list
https://lists.freedesktop.org/mailman/listinfo/libva
c***@chris-wilson.co.uk
2016-11-17 07:42:35 UTC
Permalink
Post by Xiang, Haihao
Hi,
Someone got lockup with this patch and I don't see the issue is
resolved, please check the thread below
https://lists.freedesktop.org/archives/intel-gfx/2015-December/083572.h
tml  ([Intel-gfx] vsync + vaapi question).
https://lists.freedesktop.org/archives/intel-gfx/2015-December/083862.h
tml
I will revert this patch until we root the cause.
This is not the cause of the lockup.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Xiang, Haihao
2016-11-17 08:15:34 UTC
Permalink
But in Lukas's comment:

"Had to revert it because of number of hard lockups."

Did you have other patch to fix the lockup issue in other component or
does the issue has gone away? If not, We have to revert the patch
otherwise user will suffer lockup issue with libva.

Thanks
Haihao
Post by c***@chris-wilson.co.uk
Post by Xiang, Haihao
Hi,
Someone got lockup with this patch and I don't see the issue is
resolved, please check the thread below
https://lists.freedesktop.org/archives/intel-gfx/2015-December/0835
72.h
tml  ([Intel-gfx] vsync + vaapi question).
https://lists.freedesktop.org/archives/intel-gfx/2015-December/0838
62.h
tml
I will revert this patch until we root the cause.
This is not the cause of the lockup.
-Chris
Sean V Kelley
2016-11-17 16:45:11 UTC
Permalink
"Had to revert it because of number of hard lockups."
Did you have other patch to fix the lockup issue in other component or
does the issue has gone away? If not, We have to revert the
patch
otherwise user will suffer lockup issue with libva.
+Focus

You are making too many assumptions here. I don't have a problem with
the patch per se and if it will alleviate your concern we can run some
smoke tests on it. Ambiguous and unreproduced error reports from a
patch does not a revert make...So ask Focus to run some tests.


Thanks,

Sean
Thanks
Haihao
Post by c***@chris-wilson.co.uk
Post by Xiang, Haihao
Hi,
Someone got lockup with this patch and I don't see the issue is
resolved, please check the thread below
https://lists.freedesktop.org/archives/intel-gfx/2015-December/08
35
72.h
tml  ([Intel-gfx] vsync + vaapi question).
https://lists.freedesktop.org/archives/intel-gfx/2015-December/08
38
62.h
tml
I will revert this patch until we root the cause.
This is not the cause of the lockup.
-Chris
_______________________________________________
Libva mailing list
https://lists.freedesktop.org/mailman/listinfo/libva
Xiang, Haihao
2016-11-18 02:00:37 UTC
Permalink
Post by Sean V Kelley
Post by Xiang, Haihao
"Had to revert it because of number of hard lockups."
Did you have other patch to fix the lockup issue in other component or
does the issue has gone away? If not, We have to revert the
 patch
otherwise user will suffer lockup issue with libva.
+Focus
You are making too many assumptions here.  I don't have a problem
with
the patch per se and if it will alleviate your concern we can run some
smoke tests on it.  Ambiguous and unreproduced error reports from a
patch does not a revert make...So ask Focus to run some tests.
The patch enforces synchronization now, so we should make sure it works
in a normal usage. I don't think the report is ambiguous as the
reporter said lockups are gone after reverting the patch. However many
things are changed since last year, I agree we can run some tests to
verify it.
Post by Sean V Kelley
Thanks,
Sean
Post by Xiang, Haihao
Thanks
Haihao
Post by c***@chris-wilson.co.uk
Post by Xiang, Haihao
Hi,
Someone got lockup with this patch and I don't see the issue is
resolved, please check the thread below
https://lists.freedesktop.org/archives/intel-gfx/2015-December/
08
35
72.h
tml  ([Intel-gfx] vsync + vaapi question).
https://lists.freedesktop.org/archives/intel-gfx/2015-December/
08
38
62.h
tml
I will revert this patch until we root the cause.
This is not the cause of the lockup.
-Chris
_______________________________________________
Libva mailing list
https://lists.freedesktop.org/mailman/listinfo/libva
Xiang, Haihao
2016-11-18 08:12:33 UTC
Permalink
Thanks Focus, so the lockup issue should be gone. 
Hi Sean and all,
QA side had tried the H264 playback(Three resolutions: 1080P, 480P,
CIF, each resolution was playbacked with 10 times ) by using the
yamidecoder as the test tool on the latest libva driver (master
branch). The kernel version which I used is 4.8 RC3 mainline kernel.
Both of BDW and HSW platforms were covered.
It worked well, and without any issue found.
Thanks
Focus
-----Original Message-----
Sent: Friday, November 18, 2016 12:45 AM
Subject: Re: [Libva] [PATCH] va/x11: Require synchronisation to
vblank with DRI2SwapBuffers
Post by Xiang, Haihao
"Had to revert it because of number of hard lockups."
Did you have other patch to fix the lockup issue in other component or
does the issue has gone away? If not, We have to revert the  patch
otherwise user will suffer lockup issue with libva.
+Focus
You are making too many assumptions here.  I don't have a problem
with the patch per se and if it will alleviate your concern we can
run some smoke tests on it.  Ambiguous and unreproduced error reports
from a patch does not a revert make...So ask Focus to run some tests.
Thanks,
Sean
Post by Xiang, Haihao
Thanks
Haihao
Post by c***@chris-wilson.co.uk
Post by Xiang, Haihao
Hi,
Someone got lockup with this patch and I don't see the issue is
resolved, please check the thread below
https://lists.freedesktop.org/archives/intel-gfx/2015-December/
08
35
72.h
tml  ([Intel-gfx] vsync + vaapi question).
https://lists.freedesktop.org/archives/intel-gfx/2015-December/
08
38
62.h
tml
I will revert this patch until we root the cause.
This is not the cause of the lockup.
-Chris
_______________________________________________
Libva mailing list
https://lists.freedesktop.org/mailman/listinfo/libva
Loading...