Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

Hi Christian,

I have a sent a patch which deals with the order in which filter are applied.
I will send a patch probably by tomorrow which we use temporary surfaces.

Regards,
Nayan.

On Wed, Aug 10, 2016 at 12:49 AM, Christian König
 wrote:
> Am 09.08.2016 um 19:21 schrieb Nayan Deshmukh:
>
> Hi Christian,
>
> A few questions.
>
>
>
> On Tue, Aug 9, 2016 at 5:10 PM, Christian König 
> wrote:
>>
>> I am more than happy to solve these problems, the Lanczos filtering was
>> getting a little stale
>> anyway because I was not able to reproduce the problems Andy was facing.
>>
>> Yeah thought so, the reason is probably that you don't have the necessary
>> hardware.
>>
>> Is that why I need to add a PIPE_BIND_LINEAR to a surface?
>>
>> Yes exactly.
>>
>> So I need to use maybe a couple of surfaces alternatively to read and
>> write with the filters. This approach should work I guess.
>>
>> Allocate a temporary surface for each step, apply the necessary filters
>> using it and then use the temporary buffer as input for the next step.
>>
>> See how the deinterlacing filter does this, you should use the same
>> approach here.
>>
>> I would use this order for doing things:
>> 1. Median filter for noise reduction.
>> 2. Sharpening/blur filter.
>> 3. Deinterlacing.
>> 4. Compositioning and CC conversion.
>> 5. Advanced scaling.
>>
>
> I need to provide the median filter and the blur filter with a sampler view
> and the deint filter requires a pipe_video_buffer. I am not sure how to
> acheive this. Any suggestions?
>
>
> video buffers are basically just a collection of sampler views and render
> targets (up to six). You just need to apply each filter to each plane
> separately.
>
>
> Also right now deinterlacing is the first step and the other steps follow.
> But if we perform median and sharpening filter before then we also need to
> apply them on the past and the future surfaces that we require for
> deinterlacing. Am I right?
>
>
> Oh, good point. Might be that we need to change the order to 1)
> Deinterlacing, 2) Median 3) Sharpening.
>
> Otherwise the calculation overhead/memory bandwidth probably start to hit
> some limits on low end hardware.
>
> Regards,
> Christian.
>
>
>
> Regards,
> Nayan.
>
>> Regards,
>> Christian.
>>
>>
>> Am 08.08.2016 um 16:32 schrieb Nayan Deshmukh:
>>
>> Hi Christian,
>>
>> I am more than happy to solve these problems, the Lanczos filtering was
>> getting a little stale
>> anyway because I was not able to reproduce the problems Andy was facing.
>>
>> On Mon, Aug 8, 2016 at 6:24 PM, Christian König 
>> wrote:
>>>
>>> Hi Nayan,
>>>
>>> ok let's take a step back and put the lanczos filtering aside for a
>>> moment. I have another task for you which is more urgent right now.
>>>
>>> The order we do things in vlVdpVideoMixerRender() was never 100% correct,
>>> so we have at least three problems here which needs fixing:
>>>
>>> 1) The noise reduction and sharpness filter read and write to the same
>>> surface at the same time. That only works because we use a linear layout.
>>>
>> Is that why I need to add a PIPE_BIND_LINEAR to a surface? So I need to
>> use maybe a couple of surfaces alternatively to read and write with the
>> filters. This approach should work I guess.
>>
>>> 2) We apply the noise reduction and sharpness filter after the
>>> composition. That is rather odd and should be fixed so that we apply those
>>> filters on the original video frame instead.
>>>
>>  So we need to apply the filter before the CSC conversion.
>>>
>>> 3) We use delayed rendering to render into output surfaces directly. We
>>> should rather use the DRI3 capabilities to allocate multiple output surfaces
>>> instead.
>>>
>>> Could you take care of some of those issues? Especially #1 has become a
>>> problem recently.
>>>
>> Surely, I will start working on the first 2 problem for now and look at
>> the third problem a little later.
>>
>> Regards,
>> Nayan.
>>
>>>
>>> Regards,
>>> Christian.
>>>
>>>
>>> Am 04.08.2016 um 19:22 schrieb Nayan Deshmukh:
>>>
>>> Hi Andy,
>>>
>>>
>>> On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss  wrote:

 Nayan Deshmukh wrote:
>
> Hi Andy,
>
> Thanks for testing my patches.


 NP


>> The scaling happens after CSC.


 OK, thanks.


> I believe there is some misunderstanding here, I was able to see the
> artifacts in the video that you sent me previously. But I was not
> able to replicate them


 Yea, I got that - just thought you may want to see how they had changed.

> with the pendulum video on my system. Same case this time the
> pendulum video plays fine this time too. I am attacing a video of it
> here
>
>
> https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E/view?usp=sharing


 Hmm, that's interesting for a few reasons.

 Though my 

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Christian König]

Am 09.08.2016 um 19:21 schrieb Nayan Deshmukh:

Hi Christian,

A few questions.



On Tue, Aug 9, 2016 at 5:10 PM, Christian König 
> wrote:



I am more than happy to solve these problems, the
Lanczos filtering was getting a little stale
anyway because I was not able to reproduce the problems Andy was
facing.

Yeah thought so, the reason is probably that you don't have the
necessary hardware.


Is that why I need to add a PIPE_BIND_LINEAR to a surface?

Yes exactly.


So I need to use maybe a couple of surfaces alternatively to read
and write with the filters. This approach should work I guess.

Allocate a temporary surface for each step, apply the necessary
filters using it and then use the temporary buffer as input for
the next step.

See how the deinterlacing filter does this, you should use the
same approach here.

I would use this order for doing things:
1. Median filter for noise reduction.
2. Sharpening/blur filter.
3. Deinterlacing.
4. Compositioning and CC conversion.
5. Advanced scaling.

I need to provide the median filter and the blur filter with a sampler 
view and the deint filter requires a pipe_video_buffer. I am not sure 
how to acheive this. Any suggestions?


video buffers are basically just a collection of sampler views and 
render targets (up to six). You just need to apply each filter to each 
plane separately.




Also right now deinterlacing is the first step and the other steps 
follow. But if we perform median and sharpening filter before then we 
also need to apply them on the past and the future surfaces that we 
require for deinterlacing. Am I right?


Oh, good point. Might be that we need to change the order to 1) 
Deinterlacing, 2) Median 3) Sharpening.


Otherwise the calculation overhead/memory bandwidth probably start to 
hit some limits on low end hardware.


Regards,
Christian.



Regards,
Nayan.

Regards,
Christian.


Am 08.08.2016 um 16:32 schrieb Nayan Deshmukh:

Hi Christian,

I am more than happy to solve these problems, the
Lanczos filtering was getting a little stale
anyway because I was not able to reproduce the problems Andy was
facing.

On Mon, Aug 8, 2016 at 6:24 PM, Christian König
> wrote:

Hi Nayan,

ok let's take a step back and put the lanczos filtering aside
for a moment. I have another task for you which is more
urgent right now.

The order we do things in vlVdpVideoMixerRender() was never
100% correct, so we have at least three problems here which
needs fixing:

1) The noise reduction and sharpness filter read and write to
the same surface at the same time. That only works because we
use a linear layout.

Is that why I need to add a PIPE_BIND_LINEAR to a surface? So I
need to use maybe a couple of surfaces alternatively to read and
write with the filters. This approach should work I guess.

2) We apply the noise reduction and sharpness filter after
the composition. That is rather odd and should be fixed so
that we apply those filters on the original video frame instead.

 So we need to apply the filter before the CSC conversion.

3) We use delayed rendering to render into output surfaces
directly. We should rather use the DRI3 capabilities to
allocate multiple output surfaces instead.

Could you take care of some of those issues? Especially #1
has become a problem recently.

Surely, I will start working on the first 2 problem for now and
look at the third problem a little later.

Regards,
Nayan.

Regards,
Christian.


Am 04.08.2016 um 19:22 schrieb Nayan Deshmukh:

Hi Andy,


On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss
> wrote:

Nayan Deshmukh wrote:

Hi Andy,

Thanks for testing my patches.


NP


The scaling happens after CSC.


OK, thanks.


I believe there is some misunderstanding here, I was
able to see the
artifacts in the video that you sent me previously.
But I was not
able to replicate them


Yea, I got that - just thought you may want to see how
they had changed.

with the pendulum video on my system. Same case this
time the
pendulum video plays fine this time too. I am
attacing a video of it
here


https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E/view?usp=sharing

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

Hi Christian,

A few questions.



On Tue, Aug 9, 2016 at 5:10 PM, Christian König 
wrote:

> I am more than happy to solve these problems, the Lanczos filtering was
> getting a little stale
> anyway because I was not able to reproduce the problems Andy was facing.
>
> Yeah thought so, the reason is probably that you don't have the necessary
> hardware.
>
> Is that why I need to add a PIPE_BIND_LINEAR to a surface?
>
> Yes exactly.
>
> So I need to use maybe a couple of surfaces alternatively to read and
> write with the filters. This approach should work I guess.
>
> Allocate a temporary surface for each step, apply the necessary filters
> using it and then use the temporary buffer as input for the next step.
>
> See how the deinterlacing filter does this, you should use the same
> approach here.
>
> I would use this order for doing things:
> 1. Median filter for noise reduction.
> 2. Sharpening/blur filter.
> 3. Deinterlacing.
> 4. Compositioning and CC conversion.
> 5. Advanced scaling.
>
>
I need to provide the median filter and the blur filter with a sampler view
and the deint filter requires a pipe_video_buffer. I am not sure how to
acheive this. Any suggestions?

Also right now deinterlacing is the first step and the other steps follow.
But if we perform median and sharpening filter before then we also need to
apply them on the past and the future surfaces that we require for
deinterlacing. Am I right?

Regards,
Nayan.

Regards,
> Christian.
>
>
> Am 08.08.2016 um 16:32 schrieb Nayan Deshmukh:
>
> Hi Christian,
>
> I am more than happy to solve these problems, the Lanczos filtering was
> getting a little stale
> anyway because I was not able to reproduce the problems Andy was facing.
>
> On Mon, Aug 8, 2016 at 6:24 PM, Christian König 
> wrote:
>
>> Hi Nayan,
>>
>> ok let's take a step back and put the lanczos filtering aside for a
>> moment. I have another task for you which is more urgent right now.
>>
>> The order we do things in vlVdpVideoMixerRender() was never 100% correct,
>> so we have at least three problems here which needs fixing:
>>
>> 1) The noise reduction and sharpness filter read and write to the same
>> surface at the same time. That only works because we use a linear layout.
>>
>> Is that why I need to add a PIPE_BIND_LINEAR to a surface? So I need to
> use maybe a couple of surfaces alternatively to read and write with the
> filters. This approach should work I guess.
>
> 2) We apply the noise reduction and sharpness filter after the
>> composition. That is rather odd and should be fixed so that we apply those
>> filters on the original video frame instead.
>>
>>  So we need to apply the filter before the CSC conversion.
>
>> 3) We use delayed rendering to render into output surfaces directly. We
>> should rather use the DRI3 capabilities to allocate multiple output
>> surfaces instead.
>>
>> Could you take care of some of those issues? Especially #1 has become a
>> problem recently.
>>
>> Surely, I will start working on the first 2 problem for now and look at
> the third problem a little later.
>
> Regards,
> Nayan.
>
>
>> Regards,
>> Christian.
>>
>>
>> Am 04.08.2016 um 19:22 schrieb Nayan Deshmukh:
>>
>> Hi Andy,
>>
>>
>> On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss  wrote:
>>
>>> Nayan Deshmukh wrote:
>>>
 Hi Andy,

 Thanks for testing my patches.

>>>
>>> NP
>>>
>>>
>>> The scaling happens after CSC.
>

>>> OK, thanks.
>>>
>>>
>>> I believe there is some misunderstanding here, I was able to see the
 artifacts in the video that you sent me previously. But I was not
 able to replicate them

>>>
>>> Yea, I got that - just thought you may want to see how they had changed.
>>>
>>> with the pendulum video on my system. Same case this time the
 pendulum video plays fine this time too. I am attacing a video of it
 here

 https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E
 /view?usp=sharing

>>>
>>> Hmm, that's interesting for a few reasons.
>>>
>>> Though my monitor won't do 1366x768 I can replicate the same scale
>>> factor windowed with mplayer ... -xy 768/576 ...
>>>
>>> At first glance only level 2 is obviously artifacted (though very close
>>> inspection shows others are slightly).
>>>
>>> Levels: for some reason your vid has the black bars at 0 but the content
>>> isn't scaled - like your mplayer didn't expand tv to pc on playback.
>>> This shouldn't happen by default. Do you have some extra config
>>> somewhere like in $HOME/.mplayer, if so maybe better to test without.
>>>
>>> Most important - though the vp9 compression may be to blame I can't
>>> really see any difference between the levels in that vid.
>>>
>>> In fact closely comparing just your level 1 to my (admittedly
>>> uncompressed) level 1 and 0 output scaled the same plus unstretched
>>> levels wise it looks to me like you are getting level 0 on this test.
>>>
>>
>> You are 

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Christian König]

I am more than happy to solve these problems, the Lanczos filtering 
was getting a little stale

anyway because I was not able to reproduce the problems Andy was facing.
Yeah thought so, the reason is probably that you don't have the 
necessary hardware.



Is that why I need to add a PIPE_BIND_LINEAR to a surface?

Yes exactly.

So I need to use maybe a couple of surfaces alternatively to read and 
write with the filters. This approach should work I guess.
Allocate a temporary surface for each step, apply the necessary filters 
using it and then use the temporary buffer as input for the next step.


See how the deinterlacing filter does this, you should use the same 
approach here.


I would use this order for doing things:
1. Median filter for noise reduction.
2. Sharpening/blur filter.
3. Deinterlacing.
4. Compositioning and CC conversion.
5. Advanced scaling.

Regards,
Christian.

Am 08.08.2016 um 16:32 schrieb Nayan Deshmukh:

Hi Christian,

I am more than happy to solve these problems, the Lanczos filtering 
was getting a little stale

anyway because I was not able to reproduce the problems Andy was facing.

On Mon, Aug 8, 2016 at 6:24 PM, Christian König 
> wrote:


Hi Nayan,

ok let's take a step back and put the lanczos filtering aside for
a moment. I have another task for you which is more urgent right now.

The order we do things in vlVdpVideoMixerRender() was never 100%
correct, so we have at least three problems here which needs fixing:

1) The noise reduction and sharpness filter read and write to the
same surface at the same time. That only works because we use a
linear layout.

Is that why I need to add a PIPE_BIND_LINEAR to a surface? So I need 
to use maybe a couple of surfaces alternatively to read and write with 
the filters. This approach should work I guess.


2) We apply the noise reduction and sharpness filter after the
composition. That is rather odd and should be fixed so that we
apply those filters on the original video frame instead.

 So we need to apply the filter before the CSC conversion.

3) We use delayed rendering to render into output surfaces
directly. We should rather use the DRI3 capabilities to allocate
multiple output surfaces instead.

Could you take care of some of those issues? Especially #1 has
become a problem recently.

Surely, I will start working on the first 2 problem for now and look 
at the third problem a little later.


Regards,
Nayan.

Regards,
Christian.


Am 04.08.2016 um 19:22 schrieb Nayan Deshmukh:

Hi Andy,


On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss > wrote:

Nayan Deshmukh wrote:

Hi Andy,

Thanks for testing my patches.


NP


The scaling happens after CSC.


OK, thanks.


I believe there is some misunderstanding here, I was able
to see the
artifacts in the video that you sent me previously. But I
was not
able to replicate them


Yea, I got that - just thought you may want to see how they
had changed.

with the pendulum video on my system. Same case this time the
pendulum video plays fine this time too. I am attacing a
video of it
here


https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E/view?usp=sharing




Hmm, that's interesting for a few reasons.

Though my monitor won't do 1366x768 I can replicate the same
scale
factor windowed with mplayer ... -xy 768/576 ...

At first glance only level 2 is obviously artifacted (though
very close
inspection shows others are slightly).

Levels: for some reason your vid has the black bars at 0 but
the content
isn't scaled - like your mplayer didn't expand tv to pc on
playback.
This shouldn't happen by default. Do you have some extra config
somewhere like in $HOME/.mplayer, if so maybe better to test
without.

Most important - though the vp9 compression may be to blame I
can't
really see any difference between the levels in that vid.

In fact closely comparing just your level 1 to my (admittedly
uncompressed) level 1 and 0 output scaled the same plus
unstretched
levels wise it looks to me like you are getting level 0 on
this test.


You are right it I am getting level 0 only. I have a PRIME
configuration
and I forgot to set DRI_PRIME to 1. But for some reason, I am not
able to create
a screen recording when I use my AMD card. So, for now, I can't
reproduce the artifacts
you are having so can't debug them too :(

   

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

Hi Christian,

I am more than happy to solve these problems, the Lanczos filtering was
getting a little stale
anyway because I was not able to reproduce the problems Andy was facing.

On Mon, Aug 8, 2016 at 6:24 PM, Christian König 
wrote:

> Hi Nayan,
>
> ok let's take a step back and put the lanczos filtering aside for a
> moment. I have another task for you which is more urgent right now.
>
> The order we do things in vlVdpVideoMixerRender() was never 100% correct,
> so we have at least three problems here which needs fixing:
>
> 1) The noise reduction and sharpness filter read and write to the same
> surface at the same time. That only works because we use a linear layout.
>
> Is that why I need to add a PIPE_BIND_LINEAR to a surface? So I need to
use maybe a couple of surfaces alternatively to read and write with the
filters. This approach should work I guess.

2) We apply the noise reduction and sharpness filter after the composition.
> That is rather odd and should be fixed so that we apply those filters on
> the original video frame instead.
>
>  So we need to apply the filter before the CSC conversion.

> 3) We use delayed rendering to render into output surfaces directly. We
> should rather use the DRI3 capabilities to allocate multiple output
> surfaces instead.
>
> Could you take care of some of those issues? Especially #1 has become a
> problem recently.
>
> Surely, I will start working on the first 2 problem for now and look at
the third problem a little later.

Regards,
Nayan.


> Regards,
> Christian.
>
>
> Am 04.08.2016 um 19:22 schrieb Nayan Deshmukh:
>
> Hi Andy,
>
>
> On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss  wrote:
>
>> Nayan Deshmukh wrote:
>>
>>> Hi Andy,
>>>
>>> Thanks for testing my patches.
>>>
>>
>> NP
>>
>>
>> The scaling happens after CSC.

>>>
>> OK, thanks.
>>
>>
>> I believe there is some misunderstanding here, I was able to see the
>>> artifacts in the video that you sent me previously. But I was not
>>> able to replicate them
>>>
>>
>> Yea, I got that - just thought you may want to see how they had changed.
>>
>> with the pendulum video on my system. Same case this time the
>>> pendulum video plays fine this time too. I am attacing a video of it
>>> here
>>>
>>> https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E
>>> /view?usp=sharing
>>>
>>
>> Hmm, that's interesting for a few reasons.
>>
>> Though my monitor won't do 1366x768 I can replicate the same scale
>> factor windowed with mplayer ... -xy 768/576 ...
>>
>> At first glance only level 2 is obviously artifacted (though very close
>> inspection shows others are slightly).
>>
>> Levels: for some reason your vid has the black bars at 0 but the content
>> isn't scaled - like your mplayer didn't expand tv to pc on playback.
>> This shouldn't happen by default. Do you have some extra config
>> somewhere like in $HOME/.mplayer, if so maybe better to test without.
>>
>> Most important - though the vp9 compression may be to blame I can't
>> really see any difference between the levels in that vid.
>>
>> In fact closely comparing just your level 1 to my (admittedly
>> uncompressed) level 1 and 0 output scaled the same plus unstretched
>> levels wise it looks to me like you are getting level 0 on this test.
>>
>
> You are right it I am getting level 0 only. I have a PRIME configuration
> and I forgot to set DRI_PRIME to 1. But for some reason, I am not able to
> create
> a screen recording when I use my AMD card. So, for now, I can't reproduce
> the artifacts
> you are having so can't debug them too :(
>
> Regards,
> Nayan.
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Christian König]

Hi Nayan,

ok let's take a step back and put the lanczos filtering aside for a 
moment. I have another task for you which is more urgent right now.


The order we do things in vlVdpVideoMixerRender() was never 100% 
correct, so we have at least three problems here which needs fixing:


1) The noise reduction and sharpness filter read and write to the same 
surface at the same time. That only works because we use a linear layout.


2) We apply the noise reduction and sharpness filter after the 
composition. That is rather odd and should be fixed so that we apply 
those filters on the original video frame instead.


3) We use delayed rendering to render into output surfaces directly. We 
should rather use the DRI3 capabilities to allocate multiple output 
surfaces instead.


Could you take care of some of those issues? Especially #1 has become a 
problem recently.


Regards,
Christian.

Am 04.08.2016 um 19:22 schrieb Nayan Deshmukh:

Hi Andy,


On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss > wrote:


Nayan Deshmukh wrote:

Hi Andy,

Thanks for testing my patches.


NP


The scaling happens after CSC.


OK, thanks.


I believe there is some misunderstanding here, I was able to
see the
artifacts in the video that you sent me previously. But I was not
able to replicate them


Yea, I got that - just thought you may want to see how they had
changed.

with the pendulum video on my system. Same case this time the
pendulum video plays fine this time too. I am attacing a video
of it
here


https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E/view?usp=sharing




Hmm, that's interesting for a few reasons.

Though my monitor won't do 1366x768 I can replicate the same scale
factor windowed with mplayer ... -xy 768/576 ...

At first glance only level 2 is obviously artifacted (though very
close
inspection shows others are slightly).

Levels: for some reason your vid has the black bars at 0 but the
content
isn't scaled - like your mplayer didn't expand tv to pc on playback.
This shouldn't happen by default. Do you have some extra config
somewhere like in $HOME/.mplayer, if so maybe better to test without.

Most important - though the vp9 compression may be to blame I can't
really see any difference between the levels in that vid.

In fact closely comparing just your level 1 to my (admittedly
uncompressed) level 1 and 0 output scaled the same plus unstretched
levels wise it looks to me like you are getting level 0 on this test.


You are right it I am getting level 0 only. I have a PRIME configuration
and I forgot to set DRI_PRIME to 1. But for some reason, I am not able 
to create
a screen recording when I use my AMD card. So, for now, I can't 
reproduce the artifacts

you are having so can't debug them too :(

Regards,
Nayan.



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

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

Hi Andy,


On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss  wrote:

> Nayan Deshmukh wrote:
>
>> Hi Andy,
>>
>> Thanks for testing my patches.
>>
>
> NP
>
>
> The scaling happens after CSC.
>>>
>>
> OK, thanks.
>
>
> I believe there is some misunderstanding here, I was able to see the
>> artifacts in the video that you sent me previously. But I was not
>> able to replicate them
>>
>
> Yea, I got that - just thought you may want to see how they had changed.
>
> with the pendulum video on my system. Same case this time the
>> pendulum video plays fine this time too. I am attacing a video of it
>> here
>>
>> https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E
>> /view?usp=sharing
>>
>
> Hmm, that's interesting for a few reasons.
>
> Though my monitor won't do 1366x768 I can replicate the same scale
> factor windowed with mplayer ... -xy 768/576 ...
>
> At first glance only level 2 is obviously artifacted (though very close
> inspection shows others are slightly).
>
> Levels: for some reason your vid has the black bars at 0 but the content
> isn't scaled - like your mplayer didn't expand tv to pc on playback.
> This shouldn't happen by default. Do you have some extra config
> somewhere like in $HOME/.mplayer, if so maybe better to test without.
>
> Most important - though the vp9 compression may be to blame I can't
> really see any difference between the levels in that vid.
>
> In fact closely comparing just your level 1 to my (admittedly
> uncompressed) level 1 and 0 output scaled the same plus unstretched
> levels wise it looks to me like you are getting level 0 on this test.
>

You are right it I am getting level 0 only. I have a PRIME configuration
and I forgot to set DRI_PRIME to 1. But for some reason, I am not able to
create
a screen recording when I use my AMD card. So, for now, I can't reproduce
the artifacts
you are having so can't debug them too :(

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

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Andy Furniss]

Nayan Deshmukh wrote:

Hi Andy,

Thanks for testing my patches.


NP



The scaling happens after CSC.


OK, thanks.



I believe there is some misunderstanding here, I was able to see the
artifacts in the video that you sent me previously. But I was not
able to replicate them


Yea, I got that - just thought you may want to see how they had changed.


with the pendulum video on my system. Same case this time the
pendulum video plays fine this time too. I am attacing a video of it
here

https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E/view?usp=sharing


Hmm, that's interesting for a few reasons.

Though my monitor won't do 1366x768 I can replicate the same scale
factor windowed with mplayer ... -xy 768/576 ...

At first glance only level 2 is obviously artifacted (though very close
inspection shows others are slightly).

Levels: for some reason your vid has the black bars at 0 but the content
isn't scaled - like your mplayer didn't expand tv to pc on playback.
This shouldn't happen by default. Do you have some extra config
somewhere like in $HOME/.mplayer, if so maybe better to test without.

Most important - though the vp9 compression may be to blame I can't
really see any difference between the levels in that vid.

In fact closely comparing just your level 1 to my (admittedly
uncompressed) level 1 and 0 output scaled the same plus unstretched
levels wise it looks to me like you are getting level 0 on this test.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

Hi Andy,

Thanks for testing my patches.

On Thu, Aug 4, 2016 at 5:23 AM, Andy Furniss  wrote:

> Nayan Deshmukh wrote:
>
>> Hi Christian
>>
>> On Wed, Aug 3, 2016 at 6:16 PM, Christian König
>>  wrote:
>>
>> Sorry for the delay I've been on vacation for a week.
>>>
>>> Good to hear back from you !!
>>>
>>
>>
>> Where you able to fix the problem Andy reported? I was able to
>>> rather easily reproduce that.
>>>
>>> I have tested it on my system and my friend's system and it seems
>>> to be
>>>
>> working fine. It would be great if Andy can confirm the same.
>>
>
> I am still seeing some artifacts though not the same as last patches and
> un-scaled on first look appears OK but it isn't.
>
> Does the scaling happen before CSC? I ask as on  unscaled which doesn't
> show any line/block type artifacts, there are sometimes what look like
> gamma shifts. There is also a slight shift in image position vs default
> or bicubic.
>
> The scaling happens after CSC.

Just to really confuse me I also managed to get mpv to produce a
> different result from mplayer on one particular test, they usually look
> the same. I did already correct for their differing behaviors WRT using
> 601 and 709 CSC.
>
> That 's really wierd I haven't tested them on mpv, I was just using mplayer
for testing purposes. I will test it with mpv and see how it goes.


> Pendulum again just fullscreen this time as you can't really see
> anything wrong windowed.
>

I believe there is some misunderstanding here, I was able to see the
artifacts
in the video that you sent me previously. But I was not able to replicate
them
with the pendulum video on my system. Same case this time the pendulum video
plays fine this time too. I am attacing a video of it here

https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E/view?usp=sharing


Regards,
Nayan.

>
> https://drive.google.com/file/d/0BxP5-S1t9VEEcW02VkVYWDdZd1E
> /view?usp=sharing
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Andy Furniss]

Nayan Deshmukh wrote:

Hi Christian

On Wed, Aug 3, 2016 at 6:16 PM, Christian König
 wrote:


Sorry for the delay I've been on vacation for a week.

Good to hear back from you !!




Where you able to fix the problem Andy reported? I was able to
rather easily reproduce that.

I have tested it on my system and my friend's system and it seems
to be

working fine. It would be great if Andy can confirm the same.


I am still seeing some artifacts though not the same as last patches and
un-scaled on first look appears OK but it isn't.

Does the scaling happen before CSC? I ask as on  unscaled which doesn't
show any line/block type artifacts, there are sometimes what look like
gamma shifts. There is also a slight shift in image position vs default
or bicubic.

Just to really confuse me I also managed to get mpv to produce a
different result from mplayer on one particular test, they usually look
the same. I did already correct for their differing behaviors WRT using
601 and 709 CSC.

Pendulum again just fullscreen this time as you can't really see
anything wrong windowed.

https://drive.google.com/file/d/0BxP5-S1t9VEEcW02VkVYWDdZd1E/view?usp=sharing
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

Hi Christian

On Wed, Aug 3, 2016 at 6:16 PM, Christian König 
wrote:

> Sorry for the delay I've been on vacation for a week.
>
> Good to hear back from you !!


> Where you able to fix the problem Andy reported? I was able to rather
> easily reproduce that.
>
> I have tested it on my system and my friend's system and it seems to be
working fine. It would be great
if Andy can confirm the same.

Leave out level 8&9 is clearly a good idea and I'm rather eager to commit
> this set now if it doesn't show any more obvious problems.
>
> Me too :)

Regards,
Nayan.


> Regards,
> Christian.
>
>
> Am 01.08.2016 um 12:56 schrieb Nayan Deshmukh:
>
>> v2: avoid dividing by zero when calculating lanczos
>>
>> Signed-off-by: Nayan Deshmukh 
>> ---
>>   src/gallium/auxiliary/Makefile.sources   |   2 +
>>   src/gallium/auxiliary/vl/vl_lanczos_filter.c | 445
>> +++
>>   src/gallium/auxiliary/vl/vl_lanczos_filter.h |  63 
>>   3 files changed, 510 insertions(+)
>>   create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.c
>>   create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.h
>>
>> diff --git a/src/gallium/auxiliary/Makefile.sources
>> b/src/gallium/auxiliary/Makefile.sources
>> index e0311bf..4eb0f65 100644
>> --- a/src/gallium/auxiliary/Makefile.sources
>> +++ b/src/gallium/auxiliary/Makefile.sources
>> @@ -330,6 +330,8 @@ VL_SOURCES := \
>> vl/vl_deint_filter.h \
>> vl/vl_idct.c \
>> vl/vl_idct.h \
>> +   vl/vl_lanczos_filter.c \
>> +   vl/vl_lanczos_filter.h \
>> vl/vl_matrix_filter.c \
>> vl/vl_matrix_filter.h \
>> vl/vl_mc.c \
>> diff --git a/src/gallium/auxiliary/vl/vl_lanczos_filter.c
>> b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
>> new file mode 100644
>> index 000..0601b90
>> --- /dev/null
>> +++ b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
>> @@ -0,0 +1,445 @@
>>
>> +/**
>> + *
>> + * Copyright 2016 Nayan Deshmukh.
>> + * All Rights Reserved.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining
>> a
>> + * copy of this software and associated documentation files (the
>> + * "Software"), to deal in the Software without restriction, including
>> + * without limitation the rights to use, copy, modify, merge, publish,
>> + * distribute, sub license, and/or sell copies of the Software, and to
>> + * permit persons to whom the Software is furnished to do so, subject to
>> + * the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the
>> + * next paragraph) shall be included in all copies or substantial
>> portions
>> + * of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS
>> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> NON-INFRINGEMENT.
>> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
>> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
>> CONTRACT,
>> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
>> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>> + *
>> +
>> **/
>> +
>> +#include 
>> +
>> +#include "pipe/p_context.h"
>> +
>> +#include "tgsi/tgsi_ureg.h"
>> +
>> +#include "util/u_draw.h"
>> +#include "util/u_memory.h"
>> +#include "util/u_math.h"
>> +#include "util/u_rect.h"
>> +
>> +#include "vl_types.h"
>> +#include "vl_vertex_buffers.h"
>> +#include "vl_lanczos_filter.h"
>> +
>> +enum VS_OUTPUT
>> +{
>> +   VS_O_VPOS = 0,
>> +   VS_O_VTEX = 0
>> +};
>> +
>> +static void *
>> +create_vert_shader(struct vl_lanczos_filter *filter)
>> +{
>> +   struct ureg_program *shader;
>> +   struct ureg_src i_vpos;
>> +   struct ureg_dst o_vpos, o_vtex;
>> +
>> +   shader = ureg_create(PIPE_SHADER_VERTEX);
>> +   if (!shader)
>> +  return NULL;
>> +
>> +   i_vpos = ureg_DECL_vs_input(shader, 0);
>> +   o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
>> +   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
>> +
>> +   ureg_MOV(shader, o_vpos, i_vpos);
>> +   ureg_MOV(shader, o_vtex, i_vpos);
>> +
>> +   ureg_END(shader);
>> +
>> +   return ureg_create_shader_and_destroy(shader, filter->pipe);
>> +}
>> +
>> +static void
>> +create_frag_shader_lanczos(struct ureg_program *shader, struct ureg_src
>> a,
>> +   struct ureg_src x, struct ureg_dst o_fragment)
>> +{
>> +   struct ureg_dst temp[8];
>> +   unsigned i;
>> +
>> +   for(i = 0; i < 8; ++i)
>> +   temp[i] = ureg_DECL_temporary(shader);
>> +
>> +   /*
>> +* temp[0] = (x == 0) ? 1.0f : x
>> +* temp[7] = (sin(pi * x) * sin ((pi * x)/a)) / x^2
>> +* o_fragment = (x == 0) ? 1.0f : temp[7]
>> +*/
>> +   

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Christian König]

Sorry for the delay I've been on vacation for a week.

Where you able to fix the problem Andy reported? I was able to rather 
easily reproduce that.


Leave out level 8&9 is clearly a good idea and I'm rather eager to 
commit this set now if it doesn't show any more obvious problems.


Regards,
Christian.

Am 01.08.2016 um 12:56 schrieb Nayan Deshmukh:

v2: avoid dividing by zero when calculating lanczos

Signed-off-by: Nayan Deshmukh 
---
  src/gallium/auxiliary/Makefile.sources   |   2 +
  src/gallium/auxiliary/vl/vl_lanczos_filter.c | 445 +++
  src/gallium/auxiliary/vl/vl_lanczos_filter.h |  63 
  3 files changed, 510 insertions(+)
  create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.c
  create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index e0311bf..4eb0f65 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -330,6 +330,8 @@ VL_SOURCES := \
vl/vl_deint_filter.h \
vl/vl_idct.c \
vl/vl_idct.h \
+   vl/vl_lanczos_filter.c \
+   vl/vl_lanczos_filter.h \
vl/vl_matrix_filter.c \
vl/vl_matrix_filter.h \
vl/vl_mc.c \
diff --git a/src/gallium/auxiliary/vl/vl_lanczos_filter.c 
b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
new file mode 100644
index 000..0601b90
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
@@ -0,0 +1,445 @@
+/**
+ *
+ * Copyright 2016 Nayan Deshmukh.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include 
+
+#include "pipe/p_context.h"
+
+#include "tgsi/tgsi_ureg.h"
+
+#include "util/u_draw.h"
+#include "util/u_memory.h"
+#include "util/u_math.h"
+#include "util/u_rect.h"
+
+#include "vl_types.h"
+#include "vl_vertex_buffers.h"
+#include "vl_lanczos_filter.h"
+
+enum VS_OUTPUT
+{
+   VS_O_VPOS = 0,
+   VS_O_VTEX = 0
+};
+
+static void *
+create_vert_shader(struct vl_lanczos_filter *filter)
+{
+   struct ureg_program *shader;
+   struct ureg_src i_vpos;
+   struct ureg_dst o_vpos, o_vtex;
+
+   shader = ureg_create(PIPE_SHADER_VERTEX);
+   if (!shader)
+  return NULL;
+
+   i_vpos = ureg_DECL_vs_input(shader, 0);
+   o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
+   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
+
+   ureg_MOV(shader, o_vpos, i_vpos);
+   ureg_MOV(shader, o_vtex, i_vpos);
+
+   ureg_END(shader);
+
+   return ureg_create_shader_and_destroy(shader, filter->pipe);
+}
+
+static void
+create_frag_shader_lanczos(struct ureg_program *shader, struct ureg_src a,
+   struct ureg_src x, struct ureg_dst o_fragment)
+{
+   struct ureg_dst temp[8];
+   unsigned i;
+
+   for(i = 0; i < 8; ++i)
+   temp[i] = ureg_DECL_temporary(shader);
+
+   /*
+* temp[0] = (x == 0) ? 1.0f : x
+* temp[7] = (sin(pi * x) * sin ((pi * x)/a)) / x^2
+* o_fragment = (x == 0) ? 1.0f : temp[7]
+*/
+   ureg_MOV(shader, temp[0], x);
+   ureg_SEQ(shader, temp[1], x, ureg_imm1f(shader, 0.0f));
+
+   ureg_LRP(shader, temp[0], ureg_src(temp[1]),
+ureg_imm1f(shader, 1.0f), ureg_src(temp[0]));
+
+   ureg_MUL(shader, temp[2], x,
+ureg_imm1f(shader, 3.141592));
+   ureg_DIV(shader, temp[3], ureg_src(temp[2]), a);
+
+   ureg_SIN(shader, temp[4], ureg_src(temp[2]));
+   ureg_SIN(shader, temp[5], ureg_src(temp[3]));
+
+   ureg_MUL(shader, temp[6], ureg_src(temp[4]),
+ureg_src(temp[5]));
+   ureg_MUL(shader, temp[7], ureg_imm1f(shader,
+0.101321), a);
+   ureg_MUL(shader, temp[7], ureg_src(temp[7]),
+ureg_src(temp[6]));
+   

[Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

v2: avoid dividing by zero when calculating lanczos

Signed-off-by: Nayan Deshmukh 
---
 src/gallium/auxiliary/Makefile.sources   |   2 +
 src/gallium/auxiliary/vl/vl_lanczos_filter.c | 445 +++
 src/gallium/auxiliary/vl/vl_lanczos_filter.h |  63 
 3 files changed, 510 insertions(+)
 create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.c
 create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index e0311bf..4eb0f65 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -330,6 +330,8 @@ VL_SOURCES := \
vl/vl_deint_filter.h \
vl/vl_idct.c \
vl/vl_idct.h \
+   vl/vl_lanczos_filter.c \
+   vl/vl_lanczos_filter.h \
vl/vl_matrix_filter.c \
vl/vl_matrix_filter.h \
vl/vl_mc.c \
diff --git a/src/gallium/auxiliary/vl/vl_lanczos_filter.c 
b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
new file mode 100644
index 000..0601b90
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
@@ -0,0 +1,445 @@
+/**
+ *
+ * Copyright 2016 Nayan Deshmukh.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include 
+
+#include "pipe/p_context.h"
+
+#include "tgsi/tgsi_ureg.h"
+
+#include "util/u_draw.h"
+#include "util/u_memory.h"
+#include "util/u_math.h"
+#include "util/u_rect.h"
+
+#include "vl_types.h"
+#include "vl_vertex_buffers.h"
+#include "vl_lanczos_filter.h"
+
+enum VS_OUTPUT
+{
+   VS_O_VPOS = 0,
+   VS_O_VTEX = 0
+};
+
+static void *
+create_vert_shader(struct vl_lanczos_filter *filter)
+{
+   struct ureg_program *shader;
+   struct ureg_src i_vpos;
+   struct ureg_dst o_vpos, o_vtex;
+
+   shader = ureg_create(PIPE_SHADER_VERTEX);
+   if (!shader)
+  return NULL;
+
+   i_vpos = ureg_DECL_vs_input(shader, 0);
+   o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
+   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
+
+   ureg_MOV(shader, o_vpos, i_vpos);
+   ureg_MOV(shader, o_vtex, i_vpos);
+
+   ureg_END(shader);
+
+   return ureg_create_shader_and_destroy(shader, filter->pipe);
+}
+
+static void
+create_frag_shader_lanczos(struct ureg_program *shader, struct ureg_src a,
+   struct ureg_src x, struct ureg_dst o_fragment)
+{
+   struct ureg_dst temp[8];
+   unsigned i;
+
+   for(i = 0; i < 8; ++i)
+   temp[i] = ureg_DECL_temporary(shader);
+
+   /*
+* temp[0] = (x == 0) ? 1.0f : x
+* temp[7] = (sin(pi * x) * sin ((pi * x)/a)) / x^2
+* o_fragment = (x == 0) ? 1.0f : temp[7]
+*/
+   ureg_MOV(shader, temp[0], x);
+   ureg_SEQ(shader, temp[1], x, ureg_imm1f(shader, 0.0f));
+
+   ureg_LRP(shader, temp[0], ureg_src(temp[1]),
+ureg_imm1f(shader, 1.0f), ureg_src(temp[0]));
+
+   ureg_MUL(shader, temp[2], x,
+ureg_imm1f(shader, 3.141592));
+   ureg_DIV(shader, temp[3], ureg_src(temp[2]), a);
+
+   ureg_SIN(shader, temp[4], ureg_src(temp[2]));
+   ureg_SIN(shader, temp[5], ureg_src(temp[3]));
+
+   ureg_MUL(shader, temp[6], ureg_src(temp[4]),
+ureg_src(temp[5]));
+   ureg_MUL(shader, temp[7], ureg_imm1f(shader,
+0.101321), a);
+   ureg_MUL(shader, temp[7], ureg_src(temp[7]),
+ureg_src(temp[6]));
+   ureg_DIV(shader, temp[7], ureg_src(temp[7]),
+ureg_src(temp[0]));
+   ureg_DIV(shader, o_fragment,
+   ureg_src(temp[7]), ureg_src(temp[0]));
+
+   ureg_LRP(shader, o_fragment, ureg_src(temp[1]),
+ureg_imm1f(shader, 1.0f), ureg_src(o_fragment));
+
+   for(i = 0; i < 8; ++i)
+   ureg_release_temporary(shader, temp[i]);
+}
+
+static void *

[Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

v2: avoiding dividing by zero when calculating lanczos
v3: make range of vtex 0..width instead of 0..1 (Christian)

Signed-off-by: Nayan Deshmukh 
---
 src/gallium/auxiliary/Makefile.sources   |   2 +
 src/gallium/auxiliary/vl/vl_lanczos_filter.c | 445 +++
 src/gallium/auxiliary/vl/vl_lanczos_filter.h |  63 
 3 files changed, 510 insertions(+)
 create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.c
 create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index e0311bf..4eb0f65 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -330,6 +330,8 @@ VL_SOURCES := \
vl/vl_deint_filter.h \
vl/vl_idct.c \
vl/vl_idct.h \
+   vl/vl_lanczos_filter.c \
+   vl/vl_lanczos_filter.h \
vl/vl_matrix_filter.c \
vl/vl_matrix_filter.h \
vl/vl_mc.c \
diff --git a/src/gallium/auxiliary/vl/vl_lanczos_filter.c 
b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
new file mode 100644
index 000..0c7d162
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
@@ -0,0 +1,445 @@
+/**
+ *
+ * Copyright 2016 Nayan Deshmukh.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include 
+
+#include "pipe/p_context.h"
+
+#include "tgsi/tgsi_ureg.h"
+
+#include "util/u_draw.h"
+#include "util/u_memory.h"
+#include "util/u_math.h"
+#include "util/u_rect.h"
+
+#include "vl_types.h"
+#include "vl_vertex_buffers.h"
+#include "vl_lanczos_filter.h"
+
+enum VS_OUTPUT
+{
+   VS_O_VPOS = 0,
+   VS_O_VTEX = 0
+};
+
+static void *
+create_vert_shader(struct vl_lanczos_filter *filter, unsigned width, unsigned 
height)
+{
+   struct ureg_program *shader;
+   struct ureg_src i_vpos;
+   struct ureg_dst o_vpos, o_vtex;
+
+   shader = ureg_create(PIPE_SHADER_VERTEX);
+   if (!shader)
+  return NULL;
+
+   i_vpos = ureg_DECL_vs_input(shader, 0);
+   o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
+   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
+   /*
+* o_vpos = i_vpos
+* o_vtex = i_vpos * i_size
+*/
+
+   ureg_MOV(shader, o_vpos, i_vpos);
+   ureg_MUL(shader, o_vtex, i_vpos, ureg_imm2f(shader, width, height));
+
+   ureg_END(shader);
+
+   return ureg_create_shader_and_destroy(shader, filter->pipe);
+}
+
+static void
+create_frag_shader_lanczos(struct ureg_program *shader, struct ureg_src a,
+   struct ureg_src x, struct ureg_dst o_fragment)
+{
+   struct ureg_dst temp[8];
+   unsigned i;
+
+   for(i = 0; i < 8; ++i)
+   temp[i] = ureg_DECL_temporary(shader);
+
+   /*
+* temp[0] = (x == 0) ? 1.0f : x
+* temp[7] = (sin(pi * x) * sin ((pi * x)/a)) / x^2
+* o_fragment = (x == 0) ? 1.0f : temp[7]
+*/
+   ureg_MOV(shader, temp[0], x);
+   ureg_SEQ(shader, temp[1], x, ureg_imm1f(shader, 0.0f));
+
+   ureg_LRP(shader, temp[0], ureg_src(temp[1]),
+ureg_imm1f(shader, 1.0f), ureg_src(temp[0]));
+
+   ureg_MUL(shader, temp[2], x,
+ureg_imm1f(shader, 3.141592));
+   ureg_DIV(shader, temp[3], ureg_src(temp[2]), a);
+
+   ureg_SIN(shader, temp[4], ureg_src(temp[2]));
+   ureg_SIN(shader, temp[5], ureg_src(temp[3]));
+
+   ureg_MUL(shader, temp[6], ureg_src(temp[4]),
+ureg_src(temp[5]));
+   ureg_MUL(shader, temp[7], ureg_imm1f(shader,
+0.101321), a);
+   ureg_MUL(shader, temp[7], ureg_src(temp[7]),
+ureg_src(temp[6]));
+   ureg_DIV(shader, temp[7], ureg_src(temp[7]),
+ureg_src(temp[0]));
+   ureg_DIV(shader, o_fragment,
+   ureg_src(temp[7]), ureg_src(temp[0]));
+
+