On 12/01/17 12:09 AM, Cheng, Tony wrote:
> Vblank interrupt fires as soon as the last line of active region is
> scanned out.
> VSync interrupt fires at the vsync.
> VUpdate interrupt fires HW is ready to scan out a new frame, this include
> latch on double buffer registers, starting memory
On 11/01/17 08:41 PM, Andy Furniss wrote:
>
> Pure luck noticing this because I haven't tested modesetting driver for
> ages, but -
>
> These patches also break full screen vdpau playback when using that.
>
> Result is a screen of mostly junk with a hint of the vid - looks like
> when direct
On 2017-01-11 12:50 AM, Michel Dänzer wrote:
On 10/01/17 09:07 PM, Andy Furniss wrote:
Andy Furniss wrote:
Though recent testing shows this is not true with DAL/DC on 3.7 -
todo test DC on new drm-next branch.
todo done, DC for some reason on both amd-staging-4.7 and
amd-staging-drm-next is
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying
v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename
On Wed, Jan 11, 2017 at 9:25 PM, Andy Furniss wrote:
> Nayan Deshmukh wrote:
>>
>> Hi Andy,
>>
>> Can you try this patch? This should help with the tearing.
>
>
> Patch seems to be good - I get page flipping again so DC, modesetting
> and "normal" setup all work OK.
>
Great.
Nayan Deshmukh wrote:
Hi Andy,
Can you try this patch? This should help with the tearing.
Patch seems to be good - I get page flipping again so DC, modesetting
and "normal" setup all work OK.
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
To: Michel Dänzer <mic...@daenzer.net>; Andy Furniss <adf.li...@gmail.com>;
Nayan Deshmukh <nayan26deshm...@gmail.com>
Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>; Cheng, Tony
<tony.ch...@amd.com>
Subject: Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back
Hi Andy,
Can you try this patch? This should help with the tearing.
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index 48e3133..98a8011 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@
Michel Dänzer wrote:
On 11/01/17 05:13 PM, Nayan Deshmukh wrote:
On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer wrote:
On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer wrote:
On 06/01/17 05:50 AM, Andy
On 11/01/17 05:13 PM, Nayan Deshmukh wrote:
> On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer wrote:
>> On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>>> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer wrote:
On 06/01/17 05:50 AM, Andy Furniss wrote:
On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer wrote:
> On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer wrote:
>>> On 06/01/17 05:50 AM, Andy Furniss wrote:
Christian König wrote:
> Am 04.01.2017 um
On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer wrote:
>> On 06/01/17 05:50 AM, Andy Furniss wrote:
>>> Christian König wrote:
Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
> dri3 allows us to send handle of a texture
On 10/01/17 09:07 PM, Andy Furniss wrote:
> Andy Furniss wrote:
>
>> Though recent testing shows this is not true with DAL/DC on 3.7 -
>> todo test DC on new drm-next branch.
>
> todo done, DC for some reason on both amd-staging-4.7 and
> amd-staging-drm-next is "slower" = the tear region is 2
On Tue, Jan 10, 2017 at 12:56 PM, Andy Furniss wrote:
> Alex Deucher wrote:
>>
>> On Tue, Jan 10, 2017 at 4:50 AM, Nayan Deshmukh
>> wrote:
>>>
>>> On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss wrote:
Christian König
Alex Deucher wrote:
On Tue, Jan 10, 2017 at 4:50 AM, Nayan Deshmukh
wrote:
On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss wrote:
Christian König wrote:
Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
dri3 allows us to send handle of a texture
On Tue, Jan 10, 2017 at 4:50 AM, Nayan Deshmukh
wrote:
> On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss wrote:
>> Christian König wrote:
>>>
>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
dri3 allows us to send handle of a texture
Andy Furniss wrote:
Though recent testing shows this is not true with DAL/DC on 3.7 -
todo test DC on new drm-next branch.
todo done, DC for some reason on both amd-staging-4.7 and
amd-staging-drm-next is "slower" = the tear region is 2 to 3 times
larger than non DC kernel with powerplay
Nayan Deshmukh wrote:
On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss wrote:
Christian König wrote:
Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to
On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer wrote:
> On 06/01/17 05:50 AM, Andy Furniss wrote:
>> Christian König wrote:
>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
dri3 allows us to send handle of a texture directly to X
so this patch allows a state
On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss wrote:
> Christian König wrote:
>>
>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>>
>>> dri3 allows us to send handle of a texture directly to X
>>> so this patch allows a state tracker to directly send its
>>> texture to X to
On 06/01/17 05:50 AM, Andy Furniss wrote:
> Christian König wrote:
>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>> dri3 allows us to send handle of a texture directly to X
>>> so this patch allows a state tracker to directly send its
>>> texture to X to be used as back buffer and avoids
Christian König wrote:
Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying
v2: use clip width/height to display a
On 01/05/2017 05:21 AM, Christian König wrote:
Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying
v2: use clip
Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying
v2: use clip width/height to display a portion of the surface
v3:
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying
v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename
On 11/04/2016 01:24 PM, Nayan Deshmukh wrote:
On Fri, Nov 04, 2016 at 12:20:51PM -0400, Leo Liu wrote:
Hi Nayan,
With this patch, the resizing corruption is fixed, thanks for that.
Still a few comments below.
On 11/04/2016 03:08 AM, Nayan Deshmukh wrote:
dri3 allows us to send handle of
On Fri, Nov 04, 2016 at 12:20:51PM -0400, Leo Liu wrote:
> Hi Nayan,
>
> With this patch, the resizing corruption is fixed, thanks for that.
>
> Still a few comments below.
>
>
> On 11/04/2016 03:08 AM, Nayan Deshmukh wrote:
> > dri3 allows us to send handle of a texture directly to X
> > so
Hi Nayan,
With this patch, the resizing corruption is fixed, thanks for that.
Still a few comments below.
On 11/04/2016 03:08 AM, Nayan Deshmukh wrote:
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying
v2: use clip width/height to display a portion of the surface
Suggested-by: Leo Liu
Signed-off-by:
Regarding to xcb_present_pixmap client call, you might have to check
xserver present/present.c on how xserver deal with it.
Regards,
Leo
On 11/02/2016 10:55 AM, Nayan Deshmukh wrote:
Hi Leo,
To support clipping of the output texture I was trying to send a
xcb_xfixes_region as the fifth
Hi Leo,
To support clipping of the output texture I was trying to send a
xcb_xfixes_region as the fifth argument (i.e valid-area) to
xcb_present_pixmap but it still displays the entire surface. Am I missing
something?
Regards,
Nayan
___
mesa-dev
Michel Dänzer wrote:
On 28/10/16 08:19 PM, Andy Furniss wrote:
Michel Dänzer wrote:
On 27/10/16 07:52 PM, Andy Furniss wrote:
Andy Furniss wrote:
Michel Dänzer wrote:
On 26/10/16 08:07 PM, Andy Furniss wrote:
The bad = Starting with DRI3 (which is default) I still get trashed
rendering
On 28/10/16 08:19 PM, Andy Furniss wrote:
> Michel Dänzer wrote:
>> On 27/10/16 07:52 PM, Andy Furniss wrote:
>>> Andy Furniss wrote:
Michel Dänzer wrote:
> On 26/10/16 08:07 PM, Andy Furniss wrote:
>>
>> The bad = Starting with DRI3 (which is default) I still get trashed
>>
Michel Dänzer wrote:
On 27/10/16 07:52 PM, Andy Furniss wrote:
Andy Furniss wrote:
Michel Dänzer wrote:
On 26/10/16 08:07 PM, Andy Furniss wrote:
The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.
I use Fluxbox
On 27/10/16 07:52 PM, Andy Furniss wrote:
> Andy Furniss wrote:
>> Michel Dänzer wrote:
>>> On 26/10/16 08:07 PM, Andy Furniss wrote:
The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.
I use
On Thu, Oct 27, 2016 at 11:07 PM, Leo Liu wrote:
>
>
> On 10/27/2016 01:20 PM, Nayan Deshmukh wrote:
>
>
>
> On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu wrote:
>
>>
>>
>> On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
>>
>>> On Thu, Oct 27, 2016 at 10:38:30AM
On 10/27/2016 01:20 PM, Nayan Deshmukh wrote:
On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu > wrote:
On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
On 10/24/2016 09:55
On Thu, Oct 27, 2016 at 10:50 PM, Nayan Deshmukh
wrote:
>
>
> On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu wrote:
>
>>
>>
>> On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
>>
>>> On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
>>>
On
On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu wrote:
>
>
> On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
>
>> On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
>>
>>>
>>> On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:
>>>
Suggested-by: Leo Liu
On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:
Suggested-by: Leo Liu
Signed-off-by: Nayan Deshmukh
---
src/gallium/auxiliary/vl/vl_winsys.h
On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
>
>
> On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:
> > Suggested-by: Leo Liu
> > Signed-off-by: Nayan Deshmukh
> > ---
> > src/gallium/auxiliary/vl/vl_winsys.h | 4 ++
> >
On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:
Suggested-by: Leo Liu
Signed-off-by: Nayan Deshmukh
---
src/gallium/auxiliary/vl/vl_winsys.h | 4 ++
src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89 +++
2 files
Nayan Deshmukh wrote:
On Thu, Oct 27, 2016 at 11:52:13AM +0100, Andy Furniss wrote:
Andy Furniss wrote:
Michel Dänzer wrote:
On 26/10/16 08:07 PM, Andy Furniss wrote:
The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing
On Thu, Oct 27, 2016 at 11:52:13AM +0100, Andy Furniss wrote:
> Andy Furniss wrote:
> > Michel Dänzer wrote:
> > > On 26/10/16 08:07 PM, Andy Furniss wrote:
> > > >
> > > > The bad = Starting with DRI3 (which is default) I still get trashed
> > > > rendering full screen. Windowed including
Andy Furniss wrote:
Michel Dänzer wrote:
On 26/10/16 08:07 PM, Andy Furniss wrote:
The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.
I use Fluxbox window manager, which does not use compositing -
IIRC this has
Michel Dänzer wrote:
On 26/10/16 08:07 PM, Andy Furniss wrote:
The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.
I use Fluxbox window manager, which does not use compositing -
IIRC this has historically shown some
s/runs/null/
On Wed, Oct 26, 2016 at 01:57:12AM +0530, Nayan Deshmukh wrote:
> Hi Andy,
>
> It seems that you have compiled mesa with DRI3 enabled but
> vl_dri3_screen_create returns
> runs when called in device.c and hence VDPAU fallbacks to using DRI2.
>
> BTW I have sent in the v1.1 for
On Tue, Oct 25, 2016 at 11:11:13PM +0100, Andy Furniss wrote:
> Nayan Deshmukh wrote:
> > Hi Andy,
> >
> > It seems that you have compiled mesa with DRI3 enabled but
> > vl_dri3_screen_create returns
> > runs when called in device.c and hence VDPAU fallbacks to using DRI2.
> >
> > BTW I have
On 26/10/16 08:07 PM, Andy Furniss wrote:
>
> The bad = Starting with DRI3 (which is default) I still get trashed
> rendering full screen. Windowed including re-sizing seems OK.
>
> I use Fluxbox window manager, which does not use compositing -
> IIRC this has historically shown some ddx DRI2/3
Nayan Deshmukh wrote:
On Tue, Oct 25, 2016 at 11:11:13PM +0100, Andy Furniss wrote:
Nayan Deshmukh wrote:
Hi Andy,
It seems that you have compiled mesa with DRI3 enabled but
vl_dri3_screen_create returns
runs when called in device.c and hence VDPAU fallbacks to using DRI2.
BTW I have sent
Nayan Deshmukh wrote:
Hi Andy,
It seems that you have compiled mesa with DRI3 enabled but
vl_dri3_screen_create returns
runs when called in device.c and hence VDPAU fallbacks to using DRI2.
BTW I have sent in the v1.1 for patch 2 which play the video using dri2 in case
of a
fallback.
Patch
Hi Andy,
It seems that you have compiled mesa with DRI3 enabled but
vl_dri3_screen_create returns
runs when called in device.c and hence VDPAU fallbacks to using DRI2.
BTW I have sent in the v1.1 for patch 2 which play the video using dri2 in case
of a
fallback.
Regards,
Nayan.
Leo Liu wrote:
On 10/25/2016 02:42 PM, Andy Furniss wrote:
Christian König wrote:
Nice work, have you been able to fix all the issues you mentioned on
your last mail?
Additional to that make sure that this set also keeps DRI2 working, in
patch #2 it looks like you call the new function
On 10/25/2016 02:42 PM, Andy Furniss wrote:
Christian König wrote:
Nice work, have you been able to fix all the issues you mentioned on
your last mail?
Additional to that make sure that this set also keeps DRI2 working, in
patch #2 it looks like you call the new function without checking if
Christian König wrote:
Nice work, have you been able to fix all the issues you mentioned on
your last mail?
Additional to that make sure that this set also keeps DRI2 working, in
patch #2 it looks like you call the new function without checking if
it's available or not.
Keep in mind that we
On Tue, Oct 25, 2016 at 11:08:12AM -0400, Leo Liu wrote:
>
>
> On 10/25/2016 02:01 AM, Nayan Deshmukh wrote:
> > Hi Leo,
> >
> > On Mon, Oct 24, 2016 at 03:18:19PM -0400, Leo Liu wrote:
> > > There are a couple of other issues from a brief test:
> > >
> > > 1. Compile warnings for
On 10/25/2016 02:01 AM, Nayan Deshmukh wrote:
Hi Leo,
On Mon, Oct 24, 2016 at 03:18:19PM -0400, Leo Liu wrote:
There are a couple of other issues from a brief test:
1. Compile warnings for presentation.c.
I will fix this in v2 with the changes that christian suggested, it might be
because
Hi Leo,
On Mon, Oct 24, 2016 at 03:18:19PM -0400, Leo Liu wrote:
> There are a couple of other issues from a brief test:
>
> 1. Compile warnings for presentation.c.
I will fix this in v2 with the changes that christian suggested, it might be
because of the use of #if which would anyway be
There are a couple of other issues from a brief test:
1. Compile warnings for presentation.c.
2. When window resized, it's showing corruption, and sometimes
corruption will stay.
Regards,
Leo
On 10/24/2016 11:27 AM, Nayan Deshmukh wrote:
On Mon, Oct 24, 2016 at 8:48 PM, Christian König
On Mon, Oct 24, 2016 at 8:48 PM, Christian König
wrote:
> Nice work, have you been able to fix all the issues you mentioned on your
> last mail?
>
> Yes, it fixes all the known issues. But I have only tested it on my
system.
> Additional to that make sure that this set
Nice work, have you been able to fix all the issues you mentioned on
your last mail?
Additional to that make sure that this set also keeps DRI2 working, in
patch #2 it looks like you call the new function without checking if
it's available or not.
Keep in mind that we possible compile both
Suggested-by: Leo Liu
Signed-off-by: Nayan Deshmukh
---
src/gallium/auxiliary/vl/vl_winsys.h | 4 ++
src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89 +++
2 files changed, 83 insertions(+), 10 deletions(-)
diff --git
62 matches
Mail list logo