On Wed, 29 Mar 2017 at 13:04 Michel Dänzer <michel@xxxxxxxxxxx> wrote:
On 29/03/17 09:27 AM, raof@xxxxxxxxxx wrote:
> From: Christopher James Halse Rogers <christopher.halse.rogers@xxxxxxxxxxxxx>
>
> 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@xxxxxxxxxxxxx>
> CC: amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> ---
> 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 for scanout */
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) {Ta. v2 incoming.
> + dev_err(&dev->pdev->dev, "Cannot create framebuffer from imported dma_buf\n");
This should probably be something like DRM_DEBUG, so userspace can't
spam dmesg by default. Same for patch 5.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel