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

Nayan Deshmukh nayan26deshmukh at gmail.com
Mon Aug 8 14:32:45 UTC 2016


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 <christian.koenig at amd.com>
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 <adf.lists at gmail.com> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160808/22c9660f/attachment-0001.html>


More information about the mesa-dev mailing list