Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Leo Liu]

Hi Nayan,

This quick hack was just to prove Christian's idea, and for your reference.
I don't have multi GPU system, and only had a very brief test on single 
GPU,

so it might be some difference on your multi GPU system.
we have to dig more into it.

Regards,
Leo


On 09/05/2016 03:51 AM, Nayan Deshmukh wrote:

Hi Leo,

I have tested your patch with my mplayer and it gives error when I try to
increase the size of the window. It gives the following error:-

X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadDrawable (invalid Pixmap or Window parameter)
X11 error: BadPixmap (invalid Pixmap parameter)

Also when I made the back buffer linear instead of the providing the 
handle myself,

it was working fine in my system.

Regards,
Nayan

On Fri, Sep 2, 2016 at 8:51 PM, Leo Liu > wrote:




On 09/02/2016 10:48 AM, Christian König wrote:

Am 02.09.2016 um 16:10 schrieb Leo Liu:



On 09/02/2016 09:50 AM, Christian König wrote:

Am 02.09.2016 um 15:27 schrieb Leo Liu:



On 09/02/2016 02:11 AM, Christian König wrote:

Am 02.09.2016 um 04:03 schrieb Michel Dänzer:

On 02/09/16 10:17 AM, Michel Dänzer wrote:

On 02/09/16 12:58 AM, Leo Liu wrote:

On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:

I saw the code in dri3_glx.c and I could somewhat relate
some basic
code structure to the vl_winsys_dri3.c. But I am new to
this and not aware of the
terminology that you used about the buffers. Could you
please explain what needs
to be done in more detail or point me to where I can read
about it.

I believe it's from loader_dri3_helper.c with
"is_different_gpu"
condition true, that will include back buffer and front
buffer case.
you could try only back buffer case for now.

 From a high level, PRIME mainly affects presentation, not
so much the
video decoding / rendering. The important thing is that the
buffer used
for presentation via the Present extension is linear, not
tiled. I'm not
sure whether it makes more sense to allocate a separate
linear buffer
for this purpose, as is done for GLX, or for the vl code to
make the
corresponding back (or front?) buffer linear in the first
place.

A separate linear buffer is probably better, actually, since
it will
also be pinned to system memory while it's being shared with
another GPU.


Yes, I agree. Nayan should also work on avoiding the extra
copy which currently occur because we can't allocate output
buffers directly in the format needed for presentation.

The general idea should be to to check during presentation if
the format in the output surface is displayable directly.


Also we have to consider drawable resized case.


Actually we don't. Take a look at the VDPAU spec the output
surface should be send for displaying without considering it's
size.

E.g. when the window is 256x256 pixels, but the application
allocated an output surface of 1024x768 we should still send
the whole surface to the X server.

It's the job of the application to resize the output surfaces
not the one of the VDPAU state tracker.


I thought this get done by vl compositor from presentation,
scaling up or down from output surface to back buffer based on
the resize.


No, that is incorrect. Take a look at the VDPAU spec:


Applications may choose to allow resizing of the presentation
queue target (which may be e.g. a regular Window when using an
X11-based implementation).

*clip_width* and *clip_height* may be used to limit the size of
the displayed region of a surface, in order to match the
specific region that was rendered to.

In turn, this allows the application to allocate over-sized
(e.g. screen-sized) surfaces, but render to a region that
matches the current size of the video window.

Using this technique, an application's response to window
resizing may simply be to render to, and display, a different
region of the surface, rather than de-/re-allocation of surfaces
to match the updated window size.



This means that we should send the original output surface size
to X, no matter what size it has or what size the window has it
is displayed in.

That wasn't possible with DRI2, that's why we have that
workaround with the delayed rendering in the mixer.


I did a quick hack on single GPU, and tested, this proves the
whole idea is working including resizing.
Linear is still displayable, just looks kind of sluggish when
playback.

Here is the hack for reference including remove back buffer
creating, and presentation rendering, use output surface handle for X

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..908ec3a 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Nayan Deshmukh]

Hi Leo,

I thought so. As Michel suggested present extension needs
a linear buffer and he and Christian agreed that we should have
a separate linear buffer for this. But I still don't understand the code
in vl_winsys_dri3.c so I am not sure how this could be implemented.

Regards,
Nayan.

On Tue, Sep 6, 2016 at 7:08 PM, Leo Liu  wrote:

> Hi Nayan,
>
> This quick hack was just to prove Christian's idea, and for your reference.
> I don't have multi GPU system, and only had a very brief test on single
> GPU,
> so it might be some difference on your multi GPU system.
> we have to dig more into it.
>
> Regards,
> Leo
>
>
>
> On 09/05/2016 03:51 AM, Nayan Deshmukh wrote:
>
> Hi Leo,
>
> I have tested your patch with my mplayer and it gives error when I try to
> increase the size of the window. It gives the following error:-
>
> X11 error: BadAlloc (insufficient resources for operation)
> X11 error: BadDrawable (invalid Pixmap or Window parameter)
> X11 error: BadPixmap (invalid Pixmap parameter)
>
> Also when I made the back buffer linear instead of the providing the
> handle myself,
> it was working fine in my system.
>
> Regards,
> Nayan
>
> On Fri, Sep 2, 2016 at 8:51 PM, Leo Liu  wrote:
>
>>
>>
>> On 09/02/2016 10:48 AM, Christian König wrote:
>>
>> Am 02.09.2016 um 16:10 schrieb Leo Liu:
>>
>>
>>
>> On 09/02/2016 09:50 AM, Christian König wrote:
>>
>> Am 02.09.2016 um 15:27 schrieb Leo Liu:
>>
>>
>>
>> On 09/02/2016 02:11 AM, Christian König wrote:
>>
>> Am 02.09.2016 um 04:03 schrieb Michel Dänzer:
>>
>> On 02/09/16 10:17 AM, Michel Dänzer wrote:
>>
>> On 02/09/16 12:58 AM, Leo Liu wrote:
>>
>> On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:
>>
>> I saw the code in dri3_glx.c and I could somewhat relate some basic
>> code structure to the vl_winsys_dri3.c. But I am new to this and not
>> aware of the
>> terminology that you used about the buffers. Could you please explain
>> what needs
>> to be done in more detail or point me to where I can read about it.
>>
>> I believe it's from loader_dri3_helper.c with "is_different_gpu"
>> condition true, that will include back buffer and front buffer case.
>> you could try only back buffer case for now.
>>
>>  From a high level, PRIME mainly affects presentation, not so much the
>> video decoding / rendering. The important thing is that the buffer used
>> for presentation via the Present extension is linear, not tiled. I'm not
>> sure whether it makes more sense to allocate a separate linear buffer
>> for this purpose, as is done for GLX, or for the vl code to make the
>> corresponding back (or front?) buffer linear in the first place.
>>
>> A separate linear buffer is probably better, actually, since it will
>> also be pinned to system memory while it's being shared with another GPU.
>>
>>
>> Yes, I agree. Nayan should also work on avoiding the extra copy which
>> currently occur because we can't allocate output buffers directly in the
>> format needed for presentation.
>>
>> The general idea should be to to check during presentation if the format
>> in the output surface is displayable directly.
>>
>>
>> Also we have to consider drawable resized case.
>>
>>
>> Actually we don't. Take a look at the VDPAU spec the output surface
>> should be send for displaying without considering it's size.
>>
>> E.g. when the window is 256x256 pixels, but the application allocated an
>> output surface of 1024x768 we should still send the whole surface to the X
>> server.
>>
>> It's the job of the application to resize the output surfaces not the one
>> of the VDPAU state tracker.
>>
>>
>> I thought this get done by vl compositor from presentation, scaling up or
>> down from output surface to back buffer based on the resize.
>>
>>
>> No, that is incorrect. Take a look at the VDPAU spec:
>>
>> Applications may choose to allow resizing of the presentation queue
>> target (which may be e.g. a regular Window when using an X11-based
>> implementation).
>>
>> *clip_width* and *clip_height* may be used to limit the size of the
>> displayed region of a surface, in order to match the specific region that
>> was rendered to.
>>
>> In turn, this allows the application to allocate over-sized (e.g.
>> screen-sized) surfaces, but render to a region that matches the current
>> size of the video window.
>>
>> Using this technique, an application's response to window resizing may
>> simply be to render to, and display, a different region of the surface,
>> rather than de-/re-allocation of surfaces to match the updated window size.
>>
>>
>> This means that we should send the original output surface size to X, no
>> matter what size it has or what size the window has it is displayed in.
>>
>> That wasn't possible with DRI2, that's why we have that workaround with
>> the delayed rendering in the mixer.
>>
>>
>> I did a quick hack on single GPU, and tested, this proves the whole idea
>> is working including resizing.
>> Linear is still displayable, just looks kind of sluggish when playback.
>>
>> Here is

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Nayan Deshmukh]

Hi Leo,

I have tested your patch with my mplayer and it gives error when I try to
increase the size of the window. It gives the following error:-

X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadDrawable (invalid Pixmap or Window parameter)
X11 error: BadPixmap (invalid Pixmap parameter)

Also when I made the back buffer linear instead of the providing the handle
myself,
it was working fine in my system.

Regards,
Nayan

On Fri, Sep 2, 2016 at 8:51 PM, Leo Liu  wrote:

>
>
> On 09/02/2016 10:48 AM, Christian König wrote:
>
> Am 02.09.2016 um 16:10 schrieb Leo Liu:
>
>
>
> On 09/02/2016 09:50 AM, Christian König wrote:
>
> Am 02.09.2016 um 15:27 schrieb Leo Liu:
>
>
>
> On 09/02/2016 02:11 AM, Christian König wrote:
>
> Am 02.09.2016 um 04:03 schrieb Michel Dänzer:
>
> On 02/09/16 10:17 AM, Michel Dänzer wrote:
>
> On 02/09/16 12:58 AM, Leo Liu wrote:
>
> On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:
>
> I saw the code in dri3_glx.c and I could somewhat relate some basic
> code structure to the vl_winsys_dri3.c. But I am new to this and not aware
> of the
> terminology that you used about the buffers. Could you please explain what
> needs
> to be done in more detail or point me to where I can read about it.
>
> I believe it's from loader_dri3_helper.c with "is_different_gpu"
> condition true, that will include back buffer and front buffer case.
> you could try only back buffer case for now.
>
>  From a high level, PRIME mainly affects presentation, not so much the
> video decoding / rendering. The important thing is that the buffer used
> for presentation via the Present extension is linear, not tiled. I'm not
> sure whether it makes more sense to allocate a separate linear buffer
> for this purpose, as is done for GLX, or for the vl code to make the
> corresponding back (or front?) buffer linear in the first place.
>
> A separate linear buffer is probably better, actually, since it will
> also be pinned to system memory while it's being shared with another GPU.
>
>
> Yes, I agree. Nayan should also work on avoiding the extra copy which
> currently occur because we can't allocate output buffers directly in the
> format needed for presentation.
>
> The general idea should be to to check during presentation if the format
> in the output surface is displayable directly.
>
>
> Also we have to consider drawable resized case.
>
>
> Actually we don't. Take a look at the VDPAU spec the output surface should
> be send for displaying without considering it's size.
>
> E.g. when the window is 256x256 pixels, but the application allocated an
> output surface of 1024x768 we should still send the whole surface to the X
> server.
>
> It's the job of the application to resize the output surfaces not the one
> of the VDPAU state tracker.
>
>
> I thought this get done by vl compositor from presentation, scaling up or
> down from output surface to back buffer based on the resize.
>
>
> No, that is incorrect. Take a look at the VDPAU spec:
>
> Applications may choose to allow resizing of the presentation queue target
> (which may be e.g. a regular Window when using an X11-based implementation).
>
> *clip_width* and *clip_height* may be used to limit the size of the
> displayed region of a surface, in order to match the specific region that
> was rendered to.
>
> In turn, this allows the application to allocate over-sized (e.g.
> screen-sized) surfaces, but render to a region that matches the current
> size of the video window.
>
> Using this technique, an application's response to window resizing may
> simply be to render to, and display, a different region of the surface,
> rather than de-/re-allocation of surfaces to match the updated window size.
>
>
> This means that we should send the original output surface size to X, no
> matter what size it has or what size the window has it is displayed in.
>
> That wasn't possible with DRI2, that's why we have that workaround with
> the delayed rendering in the mixer.
>
>
> I did a quick hack on single GPU, and tested, this proves the whole idea
> is working including resizing.
> Linear is still displayable, just looks kind of sluggish when playback.
>
> Here is the hack for reference including remove back buffer creating, and
> presentation rendering, use output surface handle for X
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
> b/src/gallium/auxiliary/vl/vl_winsys.h
> index 26db9f2..908ec3a 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys.h
> +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> @@ -59,6 +59,9 @@ struct vl_screen
> void *
> (*get_private)(struct vl_screen *vscreen);
>
> +   void *
> +   (*set_output_handle)(struct vl_screen *vscreen, struct winsys_handle
> whandle);
> +
> struct pipe_screen *pscreen;
> struct pipe_loader_device *dev;
>  };
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 3d596a6..4908699 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Leo Liu]

On 09/02/2016 10:48 AM, Christian König wrote:

Am 02.09.2016 um 16:10 schrieb Leo Liu:



On 09/02/2016 09:50 AM, Christian König wrote:

Am 02.09.2016 um 15:27 schrieb Leo Liu:



On 09/02/2016 02:11 AM, Christian König wrote:

Am 02.09.2016 um 04:03 schrieb Michel Dänzer:

On 02/09/16 10:17 AM, Michel Dänzer wrote:

On 02/09/16 12:58 AM, Leo Liu wrote:

On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:
I saw the code in dri3_glx.c and I could somewhat relate some 
basic
code structure to the vl_winsys_dri3.c. But I am new to this 
and not aware of the
terminology that you used about the buffers. Could you please 
explain what needs
to be done in more detail or point me to where I can read 
about it.

I believe it's from loader_dri3_helper.c with "is_different_gpu"
condition true, that will include back buffer and front buffer 
case.

you could try only back buffer case for now.
 From a high level, PRIME mainly affects presentation, not so 
much the
video decoding / rendering. The important thing is that the 
buffer used
for presentation via the Present extension is linear, not tiled. 
I'm not
sure whether it makes more sense to allocate a separate linear 
buffer
for this purpose, as is done for GLX, or for the vl code to make 
the

corresponding back (or front?) buffer linear in the first place.

A separate linear buffer is probably better, actually, since it will
also be pinned to system memory while it's being shared with 
another GPU.


Yes, I agree. Nayan should also work on avoiding the extra copy 
which currently occur because we can't allocate output buffers 
directly in the format needed for presentation.


The general idea should be to to check during presentation if the 
format in the output surface is displayable directly.


Also we have to consider drawable resized case.


Actually we don't. Take a look at the VDPAU spec the output surface 
should be send for displaying without considering it's size.


E.g. when the window is 256x256 pixels, but the application 
allocated an output surface of 1024x768 we should still send the 
whole surface to the X server.


It's the job of the application to resize the output surfaces not 
the one of the VDPAU state tracker.


I thought this get done by vl compositor from presentation, scaling 
up or down from output surface to back buffer based on the resize.


No, that is incorrect. Take a look at the VDPAU spec:

Applications may choose to allow resizing of the presentation queue 
target (which may be e.g. a regular Window when using an X11-based 
implementation).


*clip_width* and *clip_height* may be used to limit the size of the 
displayed region of a surface, in order to match the specific region 
that was rendered to.


In turn, this allows the application to allocate over-sized (e.g. 
screen-sized) surfaces, but render to a region that matches the 
current size of the video window.


Using this technique, an application's response to window resizing 
may simply be to render to, and display, a different region of the 
surface, rather than de-/re-allocation of surfaces to match the 
updated window size.




This means that we should send the original output surface size to X, 
no matter what size it has or what size the window has it is displayed in.


That wasn't possible with DRI2, that's why we have that workaround 
with the delayed rendering in the mixer.


I did a quick hack on single GPU, and tested, this proves the whole idea 
is working including resizing.

Linear is still displayable, just looks kind of sluggish when playback.

Here is the hack for reference including remove back buffer creating, 
and presentation rendering, use output surface handle for X


diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h

index 26db9f2..908ec3a 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,9 @@ struct vl_screen
void *
(*get_private)(struct vl_screen *vscreen);

+   void *
+   (*set_output_handle)(struct vl_screen *vscreen, struct winsys_handle 
whandle);

+
struct pipe_screen *pscreen;
struct pipe_loader_device *dev;
 };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c

index 3d596a6..4908699 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -64,6 +64,9 @@ struct vl_dri3_screen
xcb_connection_t *conn;
xcb_drawable_t drawable;

+   unsigned output_handle;
+   unsigned output_stride;
+
uint32_t width, height, depth;

xcb_present_event_t eid;
@@ -225,6 +228,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
if (!shm_fence)
   goto close_fd;

+#if 0
memset(&templ, 0, sizeof(templ));
templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW |
 PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
@@ -248,6 +252,11 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
   

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Christian König]

Am 02.09.2016 um 16:10 schrieb Leo Liu:



On 09/02/2016 09:50 AM, Christian König wrote:

Am 02.09.2016 um 15:27 schrieb Leo Liu:



On 09/02/2016 02:11 AM, Christian König wrote:

Am 02.09.2016 um 04:03 schrieb Michel Dänzer:

On 02/09/16 10:17 AM, Michel Dänzer wrote:

On 02/09/16 12:58 AM, Leo Liu wrote:

On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:
I saw the code in dri3_glx.c and I could somewhat relate some 
basic
code structure to the vl_winsys_dri3.c. But I am new to this 
and not aware of the
terminology that you used about the buffers. Could you please 
explain what needs
to be done in more detail or point me to where I can read about 
it.

I believe it's from loader_dri3_helper.c with "is_different_gpu"
condition true, that will include back buffer and front buffer 
case.

you could try only back buffer case for now.
 From a high level, PRIME mainly affects presentation, not so 
much the
video decoding / rendering. The important thing is that the 
buffer used
for presentation via the Present extension is linear, not tiled. 
I'm not
sure whether it makes more sense to allocate a separate linear 
buffer

for this purpose, as is done for GLX, or for the vl code to make the
corresponding back (or front?) buffer linear in the first place.

A separate linear buffer is probably better, actually, since it will
also be pinned to system memory while it's being shared with 
another GPU.


Yes, I agree. Nayan should also work on avoiding the extra copy 
which currently occur because we can't allocate output buffers 
directly in the format needed for presentation.


The general idea should be to to check during presentation if the 
format in the output surface is displayable directly.


Also we have to consider drawable resized case.


Actually we don't. Take a look at the VDPAU spec the output surface 
should be send for displaying without considering it's size.


E.g. when the window is 256x256 pixels, but the application allocated 
an output surface of 1024x768 we should still send the whole surface 
to the X server.


It's the job of the application to resize the output surfaces not the 
one of the VDPAU state tracker.


I thought this get done by vl compositor from presentation, scaling up 
or down from output surface to back buffer based on the resize.


No, that is incorrect. Take a look at the VDPAU spec:

Applications may choose to allow resizing of the presentation queue 
target (which may be e.g. a regular Window when using an X11-based 
implementation).


*clip_width* and *clip_height* may be used to limit the size of the 
displayed region of a surface, in order to match the specific region 
that was rendered to.


In turn, this allows the application to allocate over-sized (e.g. 
screen-sized) surfaces, but render to a region that matches the 
current size of the video window.


Using this technique, an application's response to window resizing may 
simply be to render to, and display, a different region of the 
surface, rather than de-/re-allocation of surfaces to match the 
updated window size.




This means that we should send the original output surface size to X, no 
matter what size it has or what size the window has it is displayed in.


That wasn't possible with DRI2, that's why we have that workaround with 
the delayed rendering in the mixer.


But no worry it's only a minor issue and a good task for Nayan to get 
deeper into the graphics stack.


Regards,
Christian.



Regards,
Leo



Regards,
Christian.



Regards,
Leo

If that is the case then handle of that surface should be send 
directly to X.
If that isn't the case we reallocate the backing buffer, copy the 
content of the output surface into it and then send the new handle 
to X.


Regards,
Christian.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev







___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Leo Liu]

On 09/02/2016 09:50 AM, Christian König wrote:

Am 02.09.2016 um 15:27 schrieb Leo Liu:



On 09/02/2016 02:11 AM, Christian König wrote:

Am 02.09.2016 um 04:03 schrieb Michel Dänzer:

On 02/09/16 10:17 AM, Michel Dänzer wrote:

On 02/09/16 12:58 AM, Leo Liu wrote:

On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:

I saw the code in dri3_glx.c and I could somewhat relate some basic
code structure to the vl_winsys_dri3.c. But I am new to this and 
not aware of the
terminology that you used about the buffers. Could you please 
explain what needs

to be done in more detail or point me to where I can read about it.

I believe it's from loader_dri3_helper.c with "is_different_gpu"
condition true, that will include back buffer and front buffer case.
you could try only back buffer case for now.
 From a high level, PRIME mainly affects presentation, not so much 
the
video decoding / rendering. The important thing is that the buffer 
used
for presentation via the Present extension is linear, not tiled. 
I'm not

sure whether it makes more sense to allocate a separate linear buffer
for this purpose, as is done for GLX, or for the vl code to make the
corresponding back (or front?) buffer linear in the first place.

A separate linear buffer is probably better, actually, since it will
also be pinned to system memory while it's being shared with 
another GPU.


Yes, I agree. Nayan should also work on avoiding the extra copy 
which currently occur because we can't allocate output buffers 
directly in the format needed for presentation.


The general idea should be to to check during presentation if the 
format in the output surface is displayable directly.


Also we have to consider drawable resized case.


Actually we don't. Take a look at the VDPAU spec the output surface 
should be send for displaying without considering it's size.


E.g. when the window is 256x256 pixels, but the application allocated 
an output surface of 1024x768 we should still send the whole surface 
to the X server.


It's the job of the application to resize the output surfaces not the 
one of the VDPAU state tracker.


I thought this get done by vl compositor from presentation, scaling up 
or down from output surface to back buffer based on the resize.


Regards,
Leo



Regards,
Christian.



Regards,
Leo

If that is the case then handle of that surface should be send 
directly to X.
If that isn't the case we reallocate the backing buffer, copy the 
content of the output surface into it and then send the new handle 
to X.


Regards,
Christian.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev





___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Christian König]

Am 02.09.2016 um 15:27 schrieb Leo Liu:



On 09/02/2016 02:11 AM, Christian König wrote:

Am 02.09.2016 um 04:03 schrieb Michel Dänzer:

On 02/09/16 10:17 AM, Michel Dänzer wrote:

On 02/09/16 12:58 AM, Leo Liu wrote:

On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:

I saw the code in dri3_glx.c and I could somewhat relate some basic
code structure to the vl_winsys_dri3.c. But I am new to this and 
not aware of the
terminology that you used about the buffers. Could you please 
explain what needs

to be done in more detail or point me to where I can read about it.

I believe it's from loader_dri3_helper.c with "is_different_gpu"
condition true, that will include back buffer and front buffer case.
you could try only back buffer case for now.

 From a high level, PRIME mainly affects presentation, not so much the
video decoding / rendering. The important thing is that the buffer 
used
for presentation via the Present extension is linear, not tiled. 
I'm not

sure whether it makes more sense to allocate a separate linear buffer
for this purpose, as is done for GLX, or for the vl code to make the
corresponding back (or front?) buffer linear in the first place.

A separate linear buffer is probably better, actually, since it will
also be pinned to system memory while it's being shared with another 
GPU.


Yes, I agree. Nayan should also work on avoiding the extra copy which 
currently occur because we can't allocate output buffers directly in 
the format needed for presentation.


The general idea should be to to check during presentation if the 
format in the output surface is displayable directly.


Also we have to consider drawable resized case.


Actually we don't. Take a look at the VDPAU spec the output surface 
should be send for displaying without considering it's size.


E.g. when the window is 256x256 pixels, but the application allocated an 
output surface of 1024x768 we should still send the whole surface to the 
X server.


It's the job of the application to resize the output surfaces not the 
one of the VDPAU state tracker.


Regards,
Christian.



Regards,
Leo

If that is the case then handle of that surface should be send 
directly to X.
If that isn't the case we reallocate the backing buffer, copy the 
content of the output surface into it and then send the new handle to X.


Regards,
Christian.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Leo Liu]

On 09/02/2016 02:11 AM, Christian König wrote:

Am 02.09.2016 um 04:03 schrieb Michel Dänzer:

On 02/09/16 10:17 AM, Michel Dänzer wrote:

On 02/09/16 12:58 AM, Leo Liu wrote:

On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:

I saw the code in dri3_glx.c and I could somewhat relate some basic
code structure to the vl_winsys_dri3.c. But I am new to this and 
not aware of the
terminology that you used about the buffers. Could you please 
explain what needs

to be done in more detail or point me to where I can read about it.

I believe it's from loader_dri3_helper.c with "is_different_gpu"
condition true, that will include back buffer and front buffer case.
you could try only back buffer case for now.

 From a high level, PRIME mainly affects presentation, not so much the
video decoding / rendering. The important thing is that the buffer used
for presentation via the Present extension is linear, not tiled. I'm 
not

sure whether it makes more sense to allocate a separate linear buffer
for this purpose, as is done for GLX, or for the vl code to make the
corresponding back (or front?) buffer linear in the first place.

A separate linear buffer is probably better, actually, since it will
also be pinned to system memory while it's being shared with another 
GPU.


Yes, I agree. Nayan should also work on avoiding the extra copy which 
currently occur because we can't allocate output buffers directly in 
the format needed for presentation.


The general idea should be to to check during presentation if the 
format in the output surface is displayable directly.


Also we have to consider drawable resized case.

Regards,
Leo

If that is the case then handle of that surface should be send 
directly to X.
If that isn't the case we reallocate the backing buffer, copy the 
content of the output surface into it and then send the new handle to X.


Regards,
Christian.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Christian König]

Am 02.09.2016 um 04:03 schrieb Michel Dänzer:

On 02/09/16 10:17 AM, Michel Dänzer wrote:

On 02/09/16 12:58 AM, Leo Liu wrote:

On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:

I saw the code in dri3_glx.c and I could somewhat relate some basic
code structure to the vl_winsys_dri3.c. But I am new to this and not aware of 
the
terminology that you used about the buffers. Could you please explain what needs
to be done in more detail or point me to where I can read about it.

I believe it's from loader_dri3_helper.c with "is_different_gpu"
condition true, that will include back buffer and front buffer case.
you could try only back buffer case for now.

 From a high level, PRIME mainly affects presentation, not so much the
video decoding / rendering. The important thing is that the buffer used
for presentation via the Present extension is linear, not tiled. I'm not
sure whether it makes more sense to allocate a separate linear buffer
for this purpose, as is done for GLX, or for the vl code to make the
corresponding back (or front?) buffer linear in the first place.

A separate linear buffer is probably better, actually, since it will
also be pinned to system memory while it's being shared with another GPU.


Yes, I agree. Nayan should also work on avoiding the extra copy which 
currently occur because we can't allocate output buffers directly in the 
format needed for presentation.


The general idea should be to to check during presentation if the format 
in the output surface is displayable directly. If that is the case then 
handle of that surface should be send directly to X.
If that isn't the case we reallocate the backing buffer, copy the 
content of the output surface into it and then send the new handle to X.


Regards,
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Michel Dänzer]

On 02/09/16 10:17 AM, Michel Dänzer wrote:
> On 02/09/16 12:58 AM, Leo Liu wrote:
>> On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:
>>>
>>> I saw the code in dri3_glx.c and I could somewhat relate some basic
>>> code structure to the vl_winsys_dri3.c. But I am new to this and not aware 
>>> of the
>>> terminology that you used about the buffers. Could you please explain what 
>>> needs
>>> to be done in more detail or point me to where I can read about it.
>>
>> I believe it's from loader_dri3_helper.c with "is_different_gpu"
>> condition true, that will include back buffer and front buffer case.
>> you could try only back buffer case for now.
> 
> From a high level, PRIME mainly affects presentation, not so much the
> video decoding / rendering. The important thing is that the buffer used
> for presentation via the Present extension is linear, not tiled. I'm not
> sure whether it makes more sense to allocate a separate linear buffer
> for this purpose, as is done for GLX, or for the vl code to make the
> corresponding back (or front?) buffer linear in the first place.

A separate linear buffer is probably better, actually, since it will
also be pinned to system memory while it's being shared with another GPU.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Michel Dänzer]

On 02/09/16 12:58 AM, Leo Liu wrote:
> On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:
>> Hi Leo,
>>
>> I saw the code in dri3_glx.c and I could somewhat relate some basic
>> code structure to the vl_winsys_dri3.c. But I am new to this and not aware 
>> of the
>> terminology that you used about the buffers. Could you please explain what 
>> needs
>> to be done in more detail or point me to where I can read about it.
> 
> I believe it's from loader_dri3_helper.c with "is_different_gpu"
> condition true, that will include back buffer and front buffer case.
> you could try only back buffer case for now.

From a high level, PRIME mainly affects presentation, not so much the
video decoding / rendering. The important thing is that the buffer used
for presentation via the Present extension is linear, not tiled. I'm not
sure whether it makes more sense to allocate a separate linear buffer
for this purpose, as is done for GLX, or for the vl code to make the
corresponding back (or front?) buffer linear in the first place.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Leo Liu]

On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:

Hi Leo,

I saw the code in dri3_glx.c and I could somewhat relate some basic 
code structure
to the vl_winsys_dri3.c. But I am new to this and not aware of the 
terminology
that you used about the buffers. Could you please explain what needs 
to be done

in more detail or point me to where I can read about it.


I believe it's from loader_dri3_helper.c with "is_different_gpu" 
condition true, that will include back buffer and front buffer case.

you could try only back buffer case for now.

Regards,
Leo




Regards,
Nayan.

On Thu, Sep 1, 2016 at 7:08 PM, Leo Liu > wrote:


Hi Nayan,

About the Prime, I think you have to do is to separate decoder
render buffer and presentation back buffer,
and copy back and forth between them for presentation and update.
You might refer to similar implement
in glx and egl from loader_dri3_helper.c by grep "is_different_gpu"


Regards,
Leo



On 09/01/2016 05:18 AM, Nayan Deshmukh wrote:

Thanks, Michel you saved a lot of my time.

Christian, I will get in touch with Leo and get started on this
task.

Regards,
Nayan.

On Thu, Sep 1, 2016 at 2:08 PM, Christian König
mailto:christian.koe...@amd.com>> wrote:

Am 01.09.2016 um 05:28 schrieb Michel Dänzer:

On 31/08/16 06:53 PM, Nayan Deshmukh wrote:

Hi Christian,

You missed a few things in the merge. I will send in
the updated patch.

I looked at the code in vl_winsys.c and vl_winsys3.c
and also
at the code in presentation.c where delayed rendering
is used. I was trying
to compile using vl_dri3_screen_create() but its
giving me some error. I
will look into the error tonight. My hardware has
PRIME configuration. So
is my hardware suitable for it?

The code in vl_winsys_dri3.c doesn't support PRIME yet.
Might not be too
hard to add though. Grep for "is_different_gpu". Leo
might have done
some work on this, so coordinate with him before spending
too much
effort on this.

Thanks for the note, I assumed Leo already implemented that,
but wasn't 100% sure.

Nayan since you are one of the few contributors with a prime
configuration I think it would make sense for you to hack on
this first.

Would also help getting you into the code and a bit more into
the stack in general.

Regards,
Christian.




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/mesa-dev



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Nayan Deshmukh]

Hi Leo,

I saw the code in dri3_glx.c and I could somewhat relate some basic code
structure
to the vl_winsys_dri3.c. But I am new to this and not aware of the
terminology
that you used about the buffers. Could you please explain what needs to be
done
in more detail or point me to where I can read about it.

Regards,
Nayan.

On Thu, Sep 1, 2016 at 7:08 PM, Leo Liu  wrote:

> Hi Nayan,
>
> About the Prime, I think you have to do is to separate decoder render
> buffer and presentation back buffer,
> and copy back and forth between them for presentation and update. You
> might refer to similar implement
> in glx and egl from loader_dri3_helper.c by grep "is_different_gpu"
>
>
> Regards,
> Leo
>
>
>
> On 09/01/2016 05:18 AM, Nayan Deshmukh wrote:
>
> Thanks, Michel you saved a lot of my time.
>
> Christian, I will get in touch with Leo and get started on this task.
>
> Regards,
> Nayan.
>
> On Thu, Sep 1, 2016 at 2:08 PM, Christian König 
> wrote:
>
>> Am 01.09.2016 um 05:28 schrieb Michel Dänzer:
>>
>>> On 31/08/16 06:53 PM, Nayan Deshmukh wrote:
>>>
 Hi Christian,

 You missed a few things in the merge. I will send in the updated patch.

 I looked at the code in vl_winsys.c and vl_winsys3.c and also
 at the code in presentation.c where delayed rendering is used. I was
 trying
 to compile using vl_dri3_screen_create() but its giving me some error. I
 will look into the error tonight. My hardware has PRIME configuration.
 So
 is my hardware suitable for it?

>>> The code in vl_winsys_dri3.c doesn't support PRIME yet. Might not be too
>>> hard to add though. Grep for "is_different_gpu". Leo might have done
>>> some work on this, so coordinate with him before spending too much
>>> effort on this.
>>>
>>> Thanks for the note, I assumed Leo already implemented that, but wasn't
>> 100% sure.
>>
>> Nayan since you are one of the few contributors with a prime
>> configuration I think it would make sense for you to hack on this first.
>>
>> Would also help getting you into the code and a bit more into the stack
>> in general.
>>
>> Regards,
>> Christian.
>>
>
>
>
> ___
> mesa-dev mailing 
> listmesa-dev@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Leo Liu]

Hi Nayan,

About the Prime, I think you have to do is to separate decoder render 
buffer and presentation back buffer,
and copy back and forth between them for presentation and update. You 
might refer to similar implement

in glx and egl from loader_dri3_helper.c by grep "is_different_gpu"


Regards,
Leo


On 09/01/2016 05:18 AM, Nayan Deshmukh wrote:

Thanks, Michel you saved a lot of my time.

Christian, I will get in touch with Leo and get started on this task.

Regards,
Nayan.

On Thu, Sep 1, 2016 at 2:08 PM, Christian König 
mailto:christian.koe...@amd.com>> wrote:


Am 01.09.2016 um 05:28 schrieb Michel Dänzer:

On 31/08/16 06:53 PM, Nayan Deshmukh wrote:

Hi Christian,

You missed a few things in the merge. I will send in the
updated patch.

I looked at the code in vl_winsys.c and vl_winsys3.c and also
at the code in presentation.c where delayed rendering is
used. I was trying
to compile using vl_dri3_screen_create() but its giving me
some error. I
will look into the error tonight. My hardware has PRIME
configuration. So
is my hardware suitable for it?

The code in vl_winsys_dri3.c doesn't support PRIME yet. Might
not be too
hard to add though. Grep for "is_different_gpu". Leo might
have done
some work on this, so coordinate with him before spending too much
effort on this.

Thanks for the note, I assumed Leo already implemented that, but
wasn't 100% sure.

Nayan since you are one of the few contributors with a prime
configuration I think it would make sense for you to hack on this
first.

Would also help getting you into the code and a bit more into the
stack in general.

Regards,
Christian.




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Nayan Deshmukh]

Thanks, Michel you saved a lot of my time.

Christian, I will get in touch with Leo and get started on this task.

Regards,
Nayan.

On Thu, Sep 1, 2016 at 2:08 PM, Christian König 
wrote:

> Am 01.09.2016 um 05:28 schrieb Michel Dänzer:
>
>> On 31/08/16 06:53 PM, Nayan Deshmukh wrote:
>>
>>> Hi Christian,
>>>
>>> You missed a few things in the merge. I will send in the updated patch.
>>>
>>> I looked at the code in vl_winsys.c and vl_winsys3.c and also
>>> at the code in presentation.c where delayed rendering is used. I was
>>> trying
>>> to compile using vl_dri3_screen_create() but its giving me some error. I
>>> will look into the error tonight. My hardware has PRIME configuration. So
>>> is my hardware suitable for it?
>>>
>> The code in vl_winsys_dri3.c doesn't support PRIME yet. Might not be too
>> hard to add though. Grep for "is_different_gpu". Leo might have done
>> some work on this, so coordinate with him before spending too much
>> effort on this.
>>
>> Thanks for the note, I assumed Leo already implemented that, but wasn't
> 100% sure.
>
> Nayan since you are one of the few contributors with a prime configuration
> I think it would make sense for you to hack on this first.
>
> Would also help getting you into the code and a bit more into the stack in
> general.
>
> Regards,
> Christian.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Christian König]

Am 01.09.2016 um 05:28 schrieb Michel Dänzer:

On 31/08/16 06:53 PM, Nayan Deshmukh wrote:

Hi Christian,

You missed a few things in the merge. I will send in the updated patch.

I looked at the code in vl_winsys.c and vl_winsys3.c and also
at the code in presentation.c where delayed rendering is used. I was trying
to compile using vl_dri3_screen_create() but its giving me some error. I
will look into the error tonight. My hardware has PRIME configuration. So
is my hardware suitable for it?

The code in vl_winsys_dri3.c doesn't support PRIME yet. Might not be too
hard to add though. Grep for "is_different_gpu". Leo might have done
some work on this, so coordinate with him before spending too much
effort on this.

Thanks for the note, I assumed Leo already implemented that, but wasn't 
100% sure.


Nayan since you are one of the few contributors with a prime 
configuration I think it would make sense for you to hack on this first.


Would also help getting you into the code and a bit more into the stack 
in general.


Regards,
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Michel Dänzer]

On 31/08/16 06:53 PM, Nayan Deshmukh wrote:
> Hi Christian,
> 
> You missed a few things in the merge. I will send in the updated patch.
> 
> I looked at the code in vl_winsys.c and vl_winsys3.c and also 
> at the code in presentation.c where delayed rendering is used. I was trying
> to compile using vl_dri3_screen_create() but its giving me some error. I
> will look into the error tonight. My hardware has PRIME configuration. So 
> is my hardware suitable for it?

The code in vl_winsys_dri3.c doesn't support PRIME yet. Might not be too
hard to add though. Grep for "is_different_gpu". Leo might have done
some work on this, so coordinate with him before spending too much
effort on this.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Nayan Deshmukh]

Hi Christian,

You missed a few things in the merge. I will send in the updated patch.

I looked at the code in vl_winsys.c and vl_winsys3.c and also
at the code in presentation.c where delayed rendering is used. I was trying
to compile using vl_dri3_screen_create() but its giving me some error. I
will
look into the error tonight. My hardware has PRIME configuration. So
is my hardware suitable for it? Just wanted to make sure.

Regards,
Nayan.

On Wed, Aug 31, 2016 at 2:22 PM, Christian König 
wrote:
> From: Nayan Deshmukh 
>
> HIGH_QUALITY_SCALING_L2 to HIGH_QUALTIY_SCALING_L7
> uses lanczos filter with number representing the size
> of the sinc window.
>
> v3: avoid L8 and L9 to allow for other scaling algrithms
> v4 (chk): rebased on master
>
> Signed-off-by: Nayan Deshmukh 
> ---
>  src/gallium/state_trackers/vdpau/mixer.c | 101
+--
>  src/gallium/state_trackers/vdpau/query.c |   8 ++
>  src/gallium/state_trackers/vdpau/vdpau_private.h |   7 ++
>  3 files changed, 90 insertions(+), 26 deletions(-)
>
> diff --git a/src/gallium/state_trackers/vdpau/mixer.c
b/src/gallium/state_trackers/vdpau/mixer.c
> index c205427..5484ca0 100644
> --- a/src/gallium/state_trackers/vdpau/mixer.c
> +++ b/src/gallium/state_trackers/vdpau/mixer.c
> @@ -82,12 +82,6 @@ vlVdpVideoMixerCreate(VdpDevice device,
>switch (features[i]) {
>/* they are valid, but we doesn't support them */
>case VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL:
> -  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L2:
> -  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L3:
> -  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L4:
> -  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L5:
> -  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L6:
> -  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L7:
>case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L8:
>case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L9:
>case VDP_VIDEO_MIXER_FEATURE_INVERSE_TELECINE:
> @@ -112,6 +106,15 @@ vlVdpVideoMixerCreate(VdpDevice device,
>case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
>   vmixer->bicubic.supported = true;
>   break;
> +
> +  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L2:
> +  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L3:
> +  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L4:
> +  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L5:
> +  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L6:
> +  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L7:
> + vmixer->lanczos.supported = true;
> + break;
>default: goto no_params;
>}
> }
> @@ -209,6 +212,10 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer)
>vl_bicubic_filter_cleanup(vmixer->bicubic.filter);
>FREE(vmixer->bicubic.filter);
> }
> +   if (vmixer->lanczos.filter) {
> +  vl_lanczos_filter_cleanup(vmixer->lanczos.filter);
> +  FREE(vmixer->lanczos.filter);
> +   }
> pipe_mutex_unlock(vmixer->device->mutex);
> DeviceReference(&vmixer->device, NULL);
>
> @@ -337,7 +344,8 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
> }
> vl_compositor_set_buffer_layer(&vmixer->cstate, compositor, layer,
video_buffer, prect, NULL, deinterlace);
>
> -   if (vmixer->bicubic.filter || vmixer->sharpness.filter ||
vmixer->noise_reduction.filter) {
> +   if (vmixer->bicubic.filter || vmixer->sharpness.filter ||
> +   vmixer->noise_reduction.filter || vmixer->lanczos.filter) {
>pipe = vmixer->device->context;
>memset(&res_tmpl, 0, sizeof(res_tmpl));
>
> @@ -394,7 +402,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
>++layers;
> }
>
> -   if (!vmixer->noise_reduction.filter && !vmixer->sharpness.filter &&
!vmixer->bicubic.filter)
> +   if (!vmixer->noise_reduction.filter && !vmixer->sharpness.filter &&
!vmixer->bicubic.filter && !vmixer->lanczos.filter)
>vlVdpSave4DelayedRendering(vmixer->device, destination_surface,
&vmixer->cstate);
> else {
>vl_compositor_render(&vmixer->cstate, compositor, surface,
&dirty_area, true);
> @@ -447,6 +455,12 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
>   RectToPipe(destination_video_rect,
&rect),
>   RectToPipe(destination_rect, &clip));
>
> +  if (vmixer->lanczos.filter)
> + vl_lanczos_filter_render(vmixer->lanczos.filter,
> +  sampler_view, dst->surface,
> +  RectToPipe(destination_video_rect,
&rect),
> +  RectToPipe(destination_rect, &clip));
> +
>if(surface != dst->surface) {
>   pipe_sampler_view_reference(&sampler_view, NULL);
>   pipe_surface_reference(&surface, NULL);
> @@ -575,6 +589,29 @@ vlVdpVideoMixerUpdateBicubicFilter(vlVdpVideoMixer
*vmixer