[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

2014-08-05 Thread Michel Dänzer 
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

[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

2014-08-05 Thread Marek Olšák 
No, it doesn't.

Marek

On Tue, Aug 5, 2014 at 10:55 AM, Michel D?nzer  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

[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

2014-08-05 Thread Marek Olšák 
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  wrote:
> From: Michel D?nzer 
>
> The HDP cache only applies to CPU access to VRAM.
>
> Signed-off-by: Michel D?nzer 
> ---
>  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, _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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

2014-08-01 Thread Michel Dänzer 
From: Michel D?nzer 

The HDP cache only applies to CPU access to VRAM.

Signed-off-by: Michel D?nzer 
---
 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, _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

[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

2014-08-01 Thread Christian König 
Am 01.08.2014 um 10:22 schrieb Michel D?nzer:
> From: Michel D?nzer 
>
> The HDP cache only applies to CPU access to VRAM.
>
> Signed-off-by: Michel D?nzer 

Wanted to suggest the same thing already, looks like a valid 
optimization to me.

Patch is Reviewed-by: Christian K?nig 

> ---
>   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, _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);

[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

2014-08-01 Thread Alex Deucher 
On Fri, Aug 1, 2014 at 4:22 AM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> The HDP cache only applies to CPU access to VRAM.
>
> Signed-off-by: Michel D?nzer 

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, _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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel