Am 15.09.2016 um 21:43 schrieb Dave Airlie:
On 15 September 2016 at 17:43, Christian König <deathsim...@vodafone.de> wrote:
Am 15.09.2016 um 06:00 schrieb Ilia Mirkin:
On Wed, Sep 14, 2016 at 11:58 PM, Dave Airlie <airl...@gmail.com> wrote:
From: Dave Airlie <airl...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
