[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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>