[Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

[Christian König]

Am 15.09.2016 um 21:43 schrieb Dave Airlie:
> On 15 September 2016 at 17:43, Christian König <deathsimple at vodafone.de> wrote:
>> Am 15.09.2016 um 06:00 schrieb Ilia Mirkin:
>>> On Wed, Sep 14, 2016 at 11:58 PM, Dave Airlie <airlied at gmail.com> wrote:
>>>> From: Dave Airlie <airlied at redhat.com>
>>>>
>>>> This reverts commit d180de35320eafa3df3d76f0e82b332656530126.
>>>>
>>>> This is a radeon specific hack that causes problems on nouveau
>>>> when combined with the SHARED flag later. If radeonsi needs a fix
>>>> for this, please fix it in the driver.
>>
>> Actually it isn't radeon specific. Using linear surfaces for this makes
>> sense because tilling isn't beneficial and the surfaces can potentially be
>> shared with other GPUs using the VDPAU OpenGL interop.
> Who says tiling isn't beneficial though? Maybe on other GPUs tiling might be, it
> still seems like a radeon centric view to me.

Tiling helps with the memory throughput because it makes pixels which 
are rendered together appear near to each other in the memory layout as 
well.

Since multimedia as well as compute applications usually always render 
to the whole texture/array/matrix it usually makes no sense at all to 
enable it for those tasks.

I disabled tilling/shuffling on other hardware for multimedia/compute 
intensive tasks long before I started working on radeon.

> I don't think the API should be dictating that, possibly the backend should get
> more info to decide if it wants to use LINEAR.

As I wrote before the issue here is that the exporting API doesn't has 
the slightest idea if the buffer is to be used by the same hardware 
device or another one. I think that is a rather common problem and 
applies to a bunch of other use cases as well (e.g. 
EGL_EXT_image_dma_buf_import etc...),

So the only doable option I can see is the capability of the kernel 
driver to migrate the buffer object from VRAM to system memory and back 
on demand and that is exactly what radeon/amdgpu is doing here.

When nouveau is pinning the buffers to the GPUs VRAM for some reason 
than that sounds like a design problem in this driver to me.

> it would be good if you guys can smoketest this at least, esp if we cc
> it for stable.

I will try it when I have time, but that may take a while.

Christian.

>
> Dave.