On Wed, 29 Mar 2017 at 13:04 Michel Dänzer <michel at daenzer.net> wrote:
> On 29/03/17 09:27 AM, raof at ubuntu.com wrote:
> > From: Christopher James Halse Rogers <
> christopher.halse.rogers at 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 at canonical.com>
> > CC: amd-gfx at 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 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) {
> > + 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.
>
> Ta. v2 incoming.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170329/591e45d9/attachment.html>
