| Message ID | 1406881329-1622-1-git-send-email-michel@daenzer.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Am 01.08.2014 um 10:22 schrieb Michel Dänzer: > From: Michel Dänzer <michel.daenzer@amd.com> > > The HDP cache only applies to CPU access to VRAM. > > Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Wanted to suggest the same thing already, looks like a valid optimization to me. Patch is Reviewed-by: Christian König <christian.koenig@amd.com> > --- > drivers/gpu/drm/radeon/radeon_gem.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c > index a350cf9..8f2cb58 100644 > --- a/drivers/gpu/drm/radeon/radeon_gem.c > +++ b/drivers/gpu/drm/radeon/radeon_gem.c > @@ -359,15 +359,17 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void *data, > struct drm_gem_object *gobj; > struct radeon_bo *robj; > int r; > + uint32_t cur_placement = 0; > > gobj = drm_gem_object_lookup(dev, filp, args->handle); > if (gobj == NULL) { > return -ENOENT; > } > robj = gem_to_radeon_bo(gobj); > - r = radeon_bo_wait(robj, NULL, false); > + r = radeon_bo_wait(robj, &cur_placement, false); > /* Flush HDP cache via MMIO if necessary */ > - if (rdev->asic->mmio_hdp_flush) > + if (rdev->asic->mmio_hdp_flush && > + radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM) > robj->rdev->asic->mmio_hdp_flush(rdev); > drm_gem_object_unreference_unlocked(gobj); > r = radeon_gem_handle_lockup(rdev, r);
On Fri, Aug 1, 2014 at 4:22 AM, Michel Dänzer <michel@daenzer.net> wrote: > From: Michel Dänzer <michel.daenzer@amd.com> > > The HDP cache only applies to CPU access to VRAM. > > Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Applied to my 3.17 branch. Thanks! > --- > drivers/gpu/drm/radeon/radeon_gem.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c > index a350cf9..8f2cb58 100644 > --- a/drivers/gpu/drm/radeon/radeon_gem.c > +++ b/drivers/gpu/drm/radeon/radeon_gem.c > @@ -359,15 +359,17 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void *data, > struct drm_gem_object *gobj; > struct radeon_bo *robj; > int r; > + uint32_t cur_placement = 0; > > gobj = drm_gem_object_lookup(dev, filp, args->handle); > if (gobj == NULL) { > return -ENOENT; > } > robj = gem_to_radeon_bo(gobj); > - r = radeon_bo_wait(robj, NULL, false); > + r = radeon_bo_wait(robj, &cur_placement, false); > /* Flush HDP cache via MMIO if necessary */ > - if (rdev->asic->mmio_hdp_flush) > + if (rdev->asic->mmio_hdp_flush && > + radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM) > robj->rdev->asic->mmio_hdp_flush(rdev); > drm_gem_object_unreference_unlocked(gobj); > r = radeon_gem_handle_lockup(rdev, r); > -- > 2.0.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
I'm afraid this won't always work and it can be a source of bugs. Userspace doesn't have to call GEM_WAIT_IDLE before a CPU access to a VRAM buffer. For example, consider a wait-idle request with a non-zero timeout, which is implemented as a loop which calls GEM_BUSY. Also, userspace can use fences (alright they are backed by 1-page-sized VRAM buffers at the moment) and it may use real fences in the future which are not tied to a buffer object. If the HDP flush isn't allowed in userspace IBs, I think we will have to expose it as an ioctl and call it explicitly from userspace. Marek On Fri, Aug 1, 2014 at 10:22 AM, Michel Dänzer <michel@daenzer.net> wrote: > From: Michel Dänzer <michel.daenzer@amd.com> > > The HDP cache only applies to CPU access to VRAM. > > Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> > --- > drivers/gpu/drm/radeon/radeon_gem.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c > index a350cf9..8f2cb58 100644 > --- a/drivers/gpu/drm/radeon/radeon_gem.c > +++ b/drivers/gpu/drm/radeon/radeon_gem.c > @@ -359,15 +359,17 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void *data, > struct drm_gem_object *gobj; > struct radeon_bo *robj; > int r; > + uint32_t cur_placement = 0; > > gobj = drm_gem_object_lookup(dev, filp, args->handle); > if (gobj == NULL) { > return -ENOENT; > } > robj = gem_to_radeon_bo(gobj); > - r = radeon_bo_wait(robj, NULL, false); > + r = radeon_bo_wait(robj, &cur_placement, false); > /* Flush HDP cache via MMIO if necessary */ > - if (rdev->asic->mmio_hdp_flush) > + if (rdev->asic->mmio_hdp_flush && > + radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM) > robj->rdev->asic->mmio_hdp_flush(rdev); > drm_gem_object_unreference_unlocked(gobj); > r = radeon_gem_handle_lockup(rdev, r); > -- > 2.0.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 05.08.2014 07:01, Marek Olšák wrote: > I'm afraid this won't always work and it can be a source of bugs. > > Userspace doesn't have to call GEM_WAIT_IDLE before a CPU access to a > VRAM buffer. For example, consider a wait-idle request with a non-zero > timeout, which is implemented as a loop which calls GEM_BUSY. Also, > userspace can use fences (alright they are backed by 1-page-sized VRAM > buffers at the moment) and it may use real fences in the future which > are not tied to a buffer object. > > If the HDP flush isn't allowed in userspace IBs, I think we will have > to expose it as an ioctl and call it explicitly from userspace. I understand your concerns, but my patch doesn't change anything wrt them, does it?
No, it doesn't. Marek On Tue, Aug 5, 2014 at 10:55 AM, Michel Dänzer <michel@daenzer.net> wrote: > On 05.08.2014 07:01, Marek Olšák wrote: >> I'm afraid this won't always work and it can be a source of bugs. >> >> Userspace doesn't have to call GEM_WAIT_IDLE before a CPU access to a >> VRAM buffer. For example, consider a wait-idle request with a non-zero >> timeout, which is implemented as a loop which calls GEM_BUSY. Also, >> userspace can use fences (alright they are backed by 1-page-sized VRAM >> buffers at the moment) and it may use real fences in the future which >> are not tied to a buffer object. >> >> If the HDP flush isn't allowed in userspace IBs, I think we will have >> to expose it as an ioctl and call it explicitly from userspace. > > I understand your concerns, but my patch doesn't change anything wrt > them, does it? > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index a350cf9..8f2cb58 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -359,15 +359,17 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void *data, struct drm_gem_object *gobj; struct radeon_bo *robj; int r; + uint32_t cur_placement = 0; gobj = drm_gem_object_lookup(dev, filp, args->handle); if (gobj == NULL) { return -ENOENT; } robj = gem_to_radeon_bo(gobj); - r = radeon_bo_wait(robj, NULL, false); + r = radeon_bo_wait(robj, &cur_placement, false); /* Flush HDP cache via MMIO if necessary */ - if (rdev->asic->mmio_hdp_flush) + if (rdev->asic->mmio_hdp_flush && + radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM) robj->rdev->asic->mmio_hdp_flush(rdev); drm_gem_object_unreference_unlocked(gobj); r = radeon_gem_handle_lockup(rdev, r);