On Wed, 29 Mar 2017 at 13:04 Michel Dänzer michel@daenzer.net wrote:
On 29/03/17 09:27 AM, raof@ubuntu.com wrote:
From: Christopher James Halse Rogers <
christopher.halse.rogers@canonical.com>
Any use of the framebuffer will migrate it to VRAM, which is not
sensible for
an imported dma-buf.
Signed-off-by: Christopher James Halse Rogers <
christopher.halse.rogers@canonical.com>
CC: amd-gfx@lists.freedesktop.org
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 39fc388f222a..e7c3cc5b7d62 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c @@ -612,6 +612,12 @@ amdgpu_user_framebuffer_create(struct drm_device
*dev,
return ERR_PTR(-ENOENT); }
/* Handle is imported dma-buf, so cannot be migrated to VRAM forscanout */
Newer APUs support scanout from GTT, though they still impose some restrictions which will probably not be satisfied in general by BOs imported from other drivers. So this is probably okay for now.
As far as I can tell amdgpu unconditionally migrates to VRAM when trying to scanout at the moment. When that changes, so can this check :).
if (obj->import_attach) {dev_err(&dev->pdev->dev, "Cannot create framebuffer fromimported dma_buf\n");
This should probably be something like DRM_DEBUG, so userspace can't spam dmesg by default. Same for patch 5.
Ta. v2 incoming.