<div dir="ltr"><div><div>I also haven't tested it on hardware (all my hardware seems to be supported by amdgpu), but the only times we touch prime_shared_count are: </div>1) It's set to 1 in radeon_gem_prime_import_sg_table. This shouldn't be called in the self-import case (and isn't, as far as I can tell), and </div>2) It's incremented in radeon_gem_prime_pin, right after the bo is pinned to GTT, so cannot be migrated to VRAM anyway (unless there's an unmatched radeon_bo_unpin call somewhere else?). </div> <div class="gmail_quote"><div dir="ltr">On Tue, 4 Apr 2017 at 02:30 Christian König <<a href="mailto:deathsimple@vodafone.de">deathsimple@vodafone.de</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 03.04.2017 um 17:51 schrieb Alex Deucher: > On Mon, Apr 3, 2017 at 4:24 AM, Christian König <<a href="mailto:deathsimple@vodafone.de" class="gmail_msg" target="_blank">deathsimple@vodafone.de</a>> wrote: >> Am 03.04.2017 um 05:35 schrieb <a href="mailto:raof@ubuntu.com" class="gmail_msg" target="_blank">raof@ubuntu.com</a>: >>> From: Christopher James Halse Rogers >>> <<a href="mailto:christopher.halse.rogers@canonical.com" class="gmail_msg" target="_blank">christopher.halse.rogers@canonical.com</a>> >>> >>> BOs shared via dma-buf, either imported or exported, cannot sensibly be >>> migrated to VRAM >>> without breaking the dma-buf sharing. Refuse userspace requests to migrate >>> to VRAM, >>> ensure such BOs are not migrated during command submission, and refuse to >>> pin them >>> to VRAM. >>> >>> v2: Don't pin BOs in GTT. Instead, refuse to migrate BOs to VRAM. >>> >>> Signed-off-by: Christopher James Halse Rogers >>> <<a href="mailto:christopher.halse.rogers@canonical.com" class="gmail_msg" target="_blank">christopher.halse.rogers@canonical.com</a>> >> >> Patches #4, #6 and this one (#7) are Reviewed-by: Christian König >> <<a href="mailto:christian.koenig@amd.com" class="gmail_msg" target="_blank">christian.koenig@amd.com</a>>. > Will this cause any issues with self sharing? E.g., the standard use > case with a single GPU and DRI3? No, the code from amdgpu to count the number of times we really shared a BO with somebody was ported over to radeon as far as I can see. So that should work fine, but I haven't double checked or tested it. Christian. > > Alex > >> >>> --- >>> drivers/gpu/drm/radeon/radeon_cs.c | 10 ++++++++++ >>> drivers/gpu/drm/radeon/radeon_gem.c | 4 ++++ >>> drivers/gpu/drm/radeon/radeon_object.c | 5 +++++ >>> 3 files changed, 19 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c >>> b/drivers/gpu/drm/radeon/radeon_cs.c >>> index a8442f7196d6..df6b58c08544 100644 >>> --- a/drivers/gpu/drm/radeon/radeon_cs.c >>> +++ b/drivers/gpu/drm/radeon/radeon_cs.c >>> @@ -164,6 +164,16 @@ static int radeon_cs_parser_relocs(struct >>> radeon_cs_parser *p) >>> p->relocs[i].allowed_domains = domain; >>> } >>> + /* Objects shared as dma-bufs cannot be moved to VRAM */ >>> + if (p->relocs[i].robj->prime_shared_count) { >>> + p->relocs[i].allowed_domains &= >>> ~RADEON_GEM_DOMAIN_VRAM; >>> + if (!p->relocs[i].allowed_domains) { >>> + DRM_ERROR("BO associated with dma-buf >>> cannot " >>> + "be moved to VRAM\n"); >>> + return -EINVAL; >>> + } >>> + } >>> + >>> p->relocs[i].<a href="http://tv.bo" rel="noreferrer" class="gmail_msg" target="_blank">tv.bo</a> = &p->relocs[i].robj->tbo; >>> p->relocs[i].tv.shared = !r->write_domain; >>> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c >>> b/drivers/gpu/drm/radeon/radeon_gem.c >>> index 96683f5b2b1b..067ea7d7658a 100644 >>> --- a/drivers/gpu/drm/radeon/radeon_gem.c >>> +++ b/drivers/gpu/drm/radeon/radeon_gem.c >>> @@ -120,6 +120,10 @@ static int radeon_gem_set_domain(struct >>> drm_gem_object *gobj, >>> return r; >>> } >>> } >>> + if (domain == RADEON_GEM_DOMAIN_VRAM && robj->prime_shared_count) >>> { >>> + /* A BO that is associated with a dma-buf cannot be >>> sensibly migrated to VRAM */ >>> + return -EINVAL; >>> + } >>> return 0; >>> } >>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c >>> b/drivers/gpu/drm/radeon/radeon_object.c >>> index 74b276060c20..bec2ec056de4 100644 >>> --- a/drivers/gpu/drm/radeon/radeon_object.c >>> +++ b/drivers/gpu/drm/radeon/radeon_object.c >>> @@ -352,6 +352,11 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, >>> u32 domain, u64 max_offset, >>> return 0; >>> } >>> + if (bo->prime_shared_count && domain == RADEON_GEM_DOMAIN_VRAM) { >>> + /* A BO shared as a dma-buf cannot be sensibly migrated to >>> VRAM */ >>> + return -EINVAL; >>> + } >>> + >>> radeon_ttm_placement_from_domain(bo, domain); >>> for (i = 0; i < bo->placement.num_placement; i++) { >>> /* force to pin into visible video ram */ >> >> >> _______________________________________________ >> amd-gfx mailing list >> <a href="mailto:amd-gfx@lists.freedesktop.org" class="gmail_msg" target="_blank">amd-gfx@lists.freedesktop.org</a> >> <a href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.freedesktop.org/mailman/listinfo/amd-gfx</a> > _______________________________________________ > amd-gfx mailing list > <a href="mailto:amd-gfx@lists.freedesktop.org" class="gmail_msg" target="_blank">amd-gfx@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.freedesktop.org/mailman/listinfo/amd-gfx</a> </blockquote></div>