[PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Marek Olšák]

From: Marek Olšák <marek.olsak@amd.com>

---
 amdgpu/amdgpu_bo.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index c0f42e81..81f8a5f7 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -22,20 +22,21 @@
  *
  */
 
 #include <stdlib.h>
 #include <stdio.h>
 #include <stdint.h>
 #include <string.h>
 #include <errno.h>
 #include <fcntl.h>
 #include <unistd.h>
+#include <limits.h>
 #include <sys/ioctl.h>
 #include <sys/mman.h>
 #include <sys/time.h>
 
 #include "libdrm_macros.h"
 #include "xf86drm.h"
 #include "amdgpu_drm.h"
 #include "amdgpu_internal.h"
 #include "util_math.h"
 
@@ -442,21 +443,29 @@ drm_public int amdgpu_bo_cpu_map(amdgpu_bo_handle bo, void **cpu)
 {
 	union drm_amdgpu_gem_mmap args;
 	void *ptr;
 	int r;
 
 	pthread_mutex_lock(&bo->cpu_access_mutex);
 
 	if (bo->cpu_ptr) {
 		/* already mapped */
 		assert(bo->cpu_map_count > 0);
-		bo->cpu_map_count++;
+
+		/* If the counter has already reached INT_MAX, don't increment
+		 * it and assume that the buffer will be mapped indefinitely.
+		 * The buffer is pretty unlikely to get unmapped by the user
+		 * at this point.
+		 */
+		if (bo->cpu_map_count != INT_MAX)
+			bo->cpu_map_count++;
+
 		*cpu = bo->cpu_ptr;
 		pthread_mutex_unlock(&bo->cpu_access_mutex);
 		return 0;
 	}
 
 	assert(bo->cpu_map_count == 0);
 
 	memset(&args, 0, sizeof(args));
 
 	/* Query the buffer address (args.addr_ptr).
@@ -492,21 +501,27 @@ drm_public int amdgpu_bo_cpu_unmap(amdgpu_bo_handle bo)
 
 	pthread_mutex_lock(&bo->cpu_access_mutex);
 	assert(bo->cpu_map_count >= 0);
 
 	if (bo->cpu_map_count == 0) {
 		/* not mapped */
 		pthread_mutex_unlock(&bo->cpu_access_mutex);
 		return -EINVAL;
 	}
 
-	bo->cpu_map_count--;
+	/* If the counter has already reached INT_MAX, don't decrement it.
+	 * This is because amdgpu_bo_cpu_map doesn't increment it past
+	 * INT_MAX.
+	 */
+	if (bo->cpu_map_count != INT_MAX)
+		bo->cpu_map_count--;
+
 	if (bo->cpu_map_count > 0) {
 		/* mapped multiple times */
 		pthread_mutex_unlock(&bo->cpu_access_mutex);
 		return 0;
 	}
 
 	r = drm_munmap(bo->cpu_ptr, bo->alloc_size) == 0 ? 0 : -errno;
 	bo->cpu_ptr = NULL;
 	pthread_mutex_unlock(&bo->cpu_access_mutex);
 	return r;
-- 
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH libdrm 2/2] amdgpu: don't track handles for non-memory allocations

[Marek Olšák]

From: Marek Olšák <marek.olsak@amd.com>

---
 amdgpu/amdgpu_bo.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 81f8a5f7..00b9b54a 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -91,26 +91,29 @@ drm_public int amdgpu_bo_alloc(amdgpu_device_handle dev,
 	if (r)
 		goto out;
 
 	r = amdgpu_bo_create(dev, alloc_buffer->alloc_size, args.out.handle,
 			     buf_handle);
 	if (r) {
 		amdgpu_close_kms_handle(dev, args.out.handle);
 		goto out;
 	}
 
-	pthread_mutex_lock(&dev->bo_table_mutex);
-	r = handle_table_insert(&dev->bo_handles, (*buf_handle)->handle,
-				*buf_handle);
-	pthread_mutex_unlock(&dev->bo_table_mutex);
-	if (r)
-		amdgpu_bo_free(*buf_handle);
+	if (alloc_buffer->preferred_heap &
+	    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {
+		pthread_mutex_lock(&dev->bo_table_mutex);
+		r = handle_table_insert(&dev->bo_handles, (*buf_handle)->handle,
+					*buf_handle);
+		pthread_mutex_unlock(&dev->bo_table_mutex);
+		if (r)
+			amdgpu_bo_free(*buf_handle);
+	}
 out:
 	return r;
 }
 
 drm_public int amdgpu_bo_set_metadata(amdgpu_bo_handle bo,
 				      struct amdgpu_bo_metadata *info)
 {
 	struct drm_amdgpu_gem_metadata args = {};
 
 	args.handle = bo->handle;
-- 
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Zhang, Jerry(Junwei)]

On 10/24/18 3:07 AM, Marek Olšák wrote:
> From: Marek Olšák <marek.olsak@amd.com>

We need commit log and sign-off here.

BTW, have you encounter any issue about that?

>
> ---
>   amdgpu/amdgpu_bo.c | 19 +++++++++++++++++--
>   1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> index c0f42e81..81f8a5f7 100644
> --- a/amdgpu/amdgpu_bo.c
> +++ b/amdgpu/amdgpu_bo.c
> @@ -22,20 +22,21 @@
>    *
>    */
>   
>   #include <stdlib.h>
>   #include <stdio.h>
>   #include <stdint.h>
>   #include <string.h>
>   #include <errno.h>
>   #include <fcntl.h>
>   #include <unistd.h>
> +#include <limits.h>
>   #include <sys/ioctl.h>
>   #include <sys/mman.h>
>   #include <sys/time.h>
>   
>   #include "libdrm_macros.h"
>   #include "xf86drm.h"
>   #include "amdgpu_drm.h"
>   #include "amdgpu_internal.h"
>   #include "util_math.h"
>   
> @@ -442,21 +443,29 @@ drm_public int amdgpu_bo_cpu_map(amdgpu_bo_handle bo, void **cpu)
>   {
>   	union drm_amdgpu_gem_mmap args;
>   	void *ptr;
>   	int r;
>   
>   	pthread_mutex_lock(&bo->cpu_access_mutex);
>   
>   	if (bo->cpu_ptr) {
>   		/* already mapped */
>   		assert(bo->cpu_map_count > 0);
> -		bo->cpu_map_count++;
> +
> +		/* If the counter has already reached INT_MAX, don't increment
> +		 * it and assume that the buffer will be mapped indefinitely.
> +		 * The buffer is pretty unlikely to get unmapped by the user
> +		 * at this point.
> +		 */
> +		if (bo->cpu_map_count != INT_MAX)
> +			bo->cpu_map_count++;

If so, shall we print some error here to notice that indefinite mappings 
come up.

Regards,
Jerry
> +
>   		*cpu = bo->cpu_ptr;
>   		pthread_mutex_unlock(&bo->cpu_access_mutex);
>   		return 0;
>   	}
>   
>   	assert(bo->cpu_map_count == 0);
>   
>   	memset(&args, 0, sizeof(args));
>   
>   	/* Query the buffer address (args.addr_ptr).
> @@ -492,21 +501,27 @@ drm_public int amdgpu_bo_cpu_unmap(amdgpu_bo_handle bo)
>   
>   	pthread_mutex_lock(&bo->cpu_access_mutex);
>   	assert(bo->cpu_map_count >= 0);
>   
>   	if (bo->cpu_map_count == 0) {
>   		/* not mapped */
>   		pthread_mutex_unlock(&bo->cpu_access_mutex);
>   		return -EINVAL;
>   	}
>   
> -	bo->cpu_map_count--;
> +	/* If the counter has already reached INT_MAX, don't decrement it.
> +	 * This is because amdgpu_bo_cpu_map doesn't increment it past
> +	 * INT_MAX.
> +	 */
> +	if (bo->cpu_map_count != INT_MAX)
> +		bo->cpu_map_count--;
> +
>   	if (bo->cpu_map_count > 0) {
>   		/* mapped multiple times */
>   		pthread_mutex_unlock(&bo->cpu_access_mutex);
>   		return 0;
>   	}
>   
>   	r = drm_munmap(bo->cpu_ptr, bo->alloc_size) == 0 ? 0 : -errno;
>   	bo->cpu_ptr = NULL;
>   	pthread_mutex_unlock(&bo->cpu_access_mutex);
>   	return r;

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 2/2] amdgpu: don't track handles for non-memory allocations

[Zhang, Jerry(Junwei)]

On 10/24/18 3:07 AM, Marek Olšák wrote:
> From: Marek Olšák <marek.olsak@amd.com>

commit log and sign-off here as well.
And any reason for that?

Regards,
Jerry

>
> ---
>   amdgpu/amdgpu_bo.c | 15 +++++++++------
>   1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> index 81f8a5f7..00b9b54a 100644
> --- a/amdgpu/amdgpu_bo.c
> +++ b/amdgpu/amdgpu_bo.c
> @@ -91,26 +91,29 @@ drm_public int amdgpu_bo_alloc(amdgpu_device_handle dev,
>   	if (r)
>   		goto out;
>   
>   	r = amdgpu_bo_create(dev, alloc_buffer->alloc_size, args.out.handle,
>   			     buf_handle);
>   	if (r) {
>   		amdgpu_close_kms_handle(dev, args.out.handle);
>   		goto out;
>   	}
>   
> -	pthread_mutex_lock(&dev->bo_table_mutex);
> -	r = handle_table_insert(&dev->bo_handles, (*buf_handle)->handle,
> -				*buf_handle);
> -	pthread_mutex_unlock(&dev->bo_table_mutex);
> -	if (r)
> -		amdgpu_bo_free(*buf_handle);
> +	if (alloc_buffer->preferred_heap &
> +	    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {
> +		pthread_mutex_lock(&dev->bo_table_mutex);
> +		r = handle_table_insert(&dev->bo_handles, (*buf_handle)->handle,
> +					*buf_handle);
> +		pthread_mutex_unlock(&dev->bo_table_mutex);
> +		if (r)
> +			amdgpu_bo_free(*buf_handle);
> +	}
>   out:
>   	return r;
>   }
>   
>   drm_public int amdgpu_bo_set_metadata(amdgpu_bo_handle bo,
>   				      struct amdgpu_bo_metadata *info)
>   {
>   	struct drm_amdgpu_gem_metadata args = {};
>   
>   	args.handle = bo->handle;

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Christian König]

That looks really ugly to me. Mapping the same BO so often is illegal 
and should be handled as error.

Otherwise we will never be able to cleanly recover from a GPU lockup 
with lost state by reloading the client library.

Christian.

Am 23.10.18 um 21:07 schrieb Marek Olšák:
> From: Marek Olšák <marek.olsak@amd.com>
>
> ---
>   amdgpu/amdgpu_bo.c | 19 +++++++++++++++++--
>   1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> index c0f42e81..81f8a5f7 100644
> --- a/amdgpu/amdgpu_bo.c
> +++ b/amdgpu/amdgpu_bo.c
> @@ -22,20 +22,21 @@
>    *
>    */
>   
>   #include <stdlib.h>
>   #include <stdio.h>
>   #include <stdint.h>
>   #include <string.h>
>   #include <errno.h>
>   #include <fcntl.h>
>   #include <unistd.h>
> +#include <limits.h>
>   #include <sys/ioctl.h>
>   #include <sys/mman.h>
>   #include <sys/time.h>
>   
>   #include "libdrm_macros.h"
>   #include "xf86drm.h"
>   #include "amdgpu_drm.h"
>   #include "amdgpu_internal.h"
>   #include "util_math.h"
>   
> @@ -442,21 +443,29 @@ drm_public int amdgpu_bo_cpu_map(amdgpu_bo_handle bo, void **cpu)
>   {
>   	union drm_amdgpu_gem_mmap args;
>   	void *ptr;
>   	int r;
>   
>   	pthread_mutex_lock(&bo->cpu_access_mutex);
>   
>   	if (bo->cpu_ptr) {
>   		/* already mapped */
>   		assert(bo->cpu_map_count > 0);
> -		bo->cpu_map_count++;
> +
> +		/* If the counter has already reached INT_MAX, don't increment
> +		 * it and assume that the buffer will be mapped indefinitely.
> +		 * The buffer is pretty unlikely to get unmapped by the user
> +		 * at this point.
> +		 */
> +		if (bo->cpu_map_count != INT_MAX)
> +			bo->cpu_map_count++;
> +
>   		*cpu = bo->cpu_ptr;
>   		pthread_mutex_unlock(&bo->cpu_access_mutex);
>   		return 0;
>   	}
>   
>   	assert(bo->cpu_map_count == 0);
>   
>   	memset(&args, 0, sizeof(args));
>   
>   	/* Query the buffer address (args.addr_ptr).
> @@ -492,21 +501,27 @@ drm_public int amdgpu_bo_cpu_unmap(amdgpu_bo_handle bo)
>   
>   	pthread_mutex_lock(&bo->cpu_access_mutex);
>   	assert(bo->cpu_map_count >= 0);
>   
>   	if (bo->cpu_map_count == 0) {
>   		/* not mapped */
>   		pthread_mutex_unlock(&bo->cpu_access_mutex);
>   		return -EINVAL;
>   	}
>   
> -	bo->cpu_map_count--;
> +	/* If the counter has already reached INT_MAX, don't decrement it.
> +	 * This is because amdgpu_bo_cpu_map doesn't increment it past
> +	 * INT_MAX.
> +	 */
> +	if (bo->cpu_map_count != INT_MAX)
> +		bo->cpu_map_count--;
> +
>   	if (bo->cpu_map_count > 0) {
>   		/* mapped multiple times */
>   		pthread_mutex_unlock(&bo->cpu_access_mutex);
>   		return 0;
>   	}
>   
>   	r = drm_munmap(bo->cpu_ptr, bo->alloc_size) == 0 ? 0 : -errno;
>   	bo->cpu_ptr = NULL;
>   	pthread_mutex_unlock(&bo->cpu_access_mutex);
>   	return r;

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 2/2] amdgpu: don't track handles for non-memory allocations

[Michel Dänzer]

On 2018-10-23 9:07 p.m., Marek Olšák wrote:
> From: Marek Olšák <marek.olsak@amd.com>
> 
> ---
>  amdgpu/amdgpu_bo.c | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> index 81f8a5f7..00b9b54a 100644
> --- a/amdgpu/amdgpu_bo.c
> +++ b/amdgpu/amdgpu_bo.c
> @@ -91,26 +91,29 @@ drm_public int amdgpu_bo_alloc(amdgpu_device_handle dev,
>  	if (r)
>  		goto out;
>  
>  	r = amdgpu_bo_create(dev, alloc_buffer->alloc_size, args.out.handle,
>  			     buf_handle);
>  	if (r) {
>  		amdgpu_close_kms_handle(dev, args.out.handle);
>  		goto out;
>  	}
>  
> -	pthread_mutex_lock(&dev->bo_table_mutex);
> -	r = handle_table_insert(&dev->bo_handles, (*buf_handle)->handle,
> -				*buf_handle);
> -	pthread_mutex_unlock(&dev->bo_table_mutex);
> -	if (r)
> -		amdgpu_bo_free(*buf_handle);
> +	if (alloc_buffer->preferred_heap &
> +	    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {

What about AMDGPU_GEM_DOMAIN_CPU? I mean, that's unlikely to actually be
used here, but if it were, exporting and importing the resulting BO
should work fine?

Instead of white-listing the domains which can be shared, it might be
better to black-list those which can't, i.e. GDS/GWS/OA.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 2/2] amdgpu: don't track handles for non-memory allocations

[Christian König]

Am 24.10.18 um 10:04 schrieb Michel Dänzer:
> On 2018-10-23 9:07 p.m., Marek Olšák wrote:
>> From: Marek Olšák <marek.olsak@amd.com>
>>
>> ---
>>   amdgpu/amdgpu_bo.c | 15 +++++++++------
>>   1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
>> index 81f8a5f7..00b9b54a 100644
>> --- a/amdgpu/amdgpu_bo.c
>> +++ b/amdgpu/amdgpu_bo.c
>> @@ -91,26 +91,29 @@ drm_public int amdgpu_bo_alloc(amdgpu_device_handle dev,
>>   	if (r)
>>   		goto out;
>>   
>>   	r = amdgpu_bo_create(dev, alloc_buffer->alloc_size, args.out.handle,
>>   			     buf_handle);
>>   	if (r) {
>>   		amdgpu_close_kms_handle(dev, args.out.handle);
>>   		goto out;
>>   	}
>>   
>> -	pthread_mutex_lock(&dev->bo_table_mutex);
>> -	r = handle_table_insert(&dev->bo_handles, (*buf_handle)->handle,
>> -				*buf_handle);
>> -	pthread_mutex_unlock(&dev->bo_table_mutex);
>> -	if (r)
>> -		amdgpu_bo_free(*buf_handle);
>> +	if (alloc_buffer->preferred_heap &
>> +	    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {
> What about AMDGPU_GEM_DOMAIN_CPU? I mean, that's unlikely to actually be
> used here, but if it were, exporting and importing the resulting BO
> should work fine?
>
> Instead of white-listing the domains which can be shared, it might be
> better to black-list those which can't, i.e. GDS/GWS/OA.

Well first of all GDS can be shared between applications.

Then adding a BO to the tracking doesn't add much overhead (only 8 bytes 
and only if it was the last allocated).

So I don't really see a reason why we should do this?

Christian.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 2190 bytes --]

On Tue, Oct 23, 2018 at 10:38 PM Zhang, Jerry(Junwei) <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
wrote:

> On 10/24/18 3:07 AM, Marek Olšák wrote:
> > From: Marek Olšák <marek.olsak-5C7GfCeVMHo@public.gmane.org>
>
> We need commit log and sign-off here.
>
> BTW, have you encounter any issue about that?
>

I don't know what you mean. I'm pretty sure that a sign-off is not needed
for libdrm.


>
> >
> > ---
> >   amdgpu/amdgpu_bo.c | 19 +++++++++++++++++--
> >   1 file changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> > index c0f42e81..81f8a5f7 100644
> > --- a/amdgpu/amdgpu_bo.c
> > +++ b/amdgpu/amdgpu_bo.c
> > @@ -22,20 +22,21 @@
> >    *
> >    */
> >
> >   #include <stdlib.h>
> >   #include <stdio.h>
> >   #include <stdint.h>
> >   #include <string.h>
> >   #include <errno.h>
> >   #include <fcntl.h>
> >   #include <unistd.h>
> > +#include <limits.h>
> >   #include <sys/ioctl.h>
> >   #include <sys/mman.h>
> >   #include <sys/time.h>
> >
> >   #include "libdrm_macros.h"
> >   #include "xf86drm.h"
> >   #include "amdgpu_drm.h"
> >   #include "amdgpu_internal.h"
> >   #include "util_math.h"
> >
> > @@ -442,21 +443,29 @@ drm_public int amdgpu_bo_cpu_map(amdgpu_bo_handle
> bo, void **cpu)
> >   {
> >       union drm_amdgpu_gem_mmap args;
> >       void *ptr;
> >       int r;
> >
> >       pthread_mutex_lock(&bo->cpu_access_mutex);
> >
> >       if (bo->cpu_ptr) {
> >               /* already mapped */
> >               assert(bo->cpu_map_count > 0);
> > -             bo->cpu_map_count++;
> > +
> > +             /* If the counter has already reached INT_MAX, don't
> increment
> > +              * it and assume that the buffer will be mapped
> indefinitely.
> > +              * The buffer is pretty unlikely to get unmapped by the
> user
> > +              * at this point.
> > +              */
> > +             if (bo->cpu_map_count != INT_MAX)
> > +                     bo->cpu_map_count++;
>
> If so, shall we print some error here to notice that indefinite mappings
> come up.
>

No error. This is expected usage.

Marek

[-- Attachment #1.2: Type: text/html, Size: 3276 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 3683 bytes --]

You and I discussed this extensively internally a while ago. It's expected
and correct behavior. Mesa doesn't unmap some buffers and never will.

Marek

On Wed, Oct 24, 2018 at 3:45 AM Christian König <
ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> That looks really ugly to me. Mapping the same BO so often is illegal
> and should be handled as error.
>
> Otherwise we will never be able to cleanly recover from a GPU lockup
> with lost state by reloading the client library.
>
> Christian.
>
> Am 23.10.18 um 21:07 schrieb Marek Olšák:
> > From: Marek Olšák <marek.olsak-5C7GfCeVMHo@public.gmane.org>
> >
> > ---
> >   amdgpu/amdgpu_bo.c | 19 +++++++++++++++++--
> >   1 file changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> > index c0f42e81..81f8a5f7 100644
> > --- a/amdgpu/amdgpu_bo.c
> > +++ b/amdgpu/amdgpu_bo.c
> > @@ -22,20 +22,21 @@
> >    *
> >    */
> >
> >   #include <stdlib.h>
> >   #include <stdio.h>
> >   #include <stdint.h>
> >   #include <string.h>
> >   #include <errno.h>
> >   #include <fcntl.h>
> >   #include <unistd.h>
> > +#include <limits.h>
> >   #include <sys/ioctl.h>
> >   #include <sys/mman.h>
> >   #include <sys/time.h>
> >
> >   #include "libdrm_macros.h"
> >   #include "xf86drm.h"
> >   #include "amdgpu_drm.h"
> >   #include "amdgpu_internal.h"
> >   #include "util_math.h"
> >
> > @@ -442,21 +443,29 @@ drm_public int amdgpu_bo_cpu_map(amdgpu_bo_handle
> bo, void **cpu)
> >   {
> >       union drm_amdgpu_gem_mmap args;
> >       void *ptr;
> >       int r;
> >
> >       pthread_mutex_lock(&bo->cpu_access_mutex);
> >
> >       if (bo->cpu_ptr) {
> >               /* already mapped */
> >               assert(bo->cpu_map_count > 0);
> > -             bo->cpu_map_count++;
> > +
> > +             /* If the counter has already reached INT_MAX, don't
> increment
> > +              * it and assume that the buffer will be mapped
> indefinitely.
> > +              * The buffer is pretty unlikely to get unmapped by the
> user
> > +              * at this point.
> > +              */
> > +             if (bo->cpu_map_count != INT_MAX)
> > +                     bo->cpu_map_count++;
> > +
> >               *cpu = bo->cpu_ptr;
> >               pthread_mutex_unlock(&bo->cpu_access_mutex);
> >               return 0;
> >       }
> >
> >       assert(bo->cpu_map_count == 0);
> >
> >       memset(&args, 0, sizeof(args));
> >
> >       /* Query the buffer address (args.addr_ptr).
> > @@ -492,21 +501,27 @@ drm_public int
> amdgpu_bo_cpu_unmap(amdgpu_bo_handle bo)
> >
> >       pthread_mutex_lock(&bo->cpu_access_mutex);
> >       assert(bo->cpu_map_count >= 0);
> >
> >       if (bo->cpu_map_count == 0) {
> >               /* not mapped */
> >               pthread_mutex_unlock(&bo->cpu_access_mutex);
> >               return -EINVAL;
> >       }
> >
> > -     bo->cpu_map_count--;
> > +     /* If the counter has already reached INT_MAX, don't decrement it.
> > +      * This is because amdgpu_bo_cpu_map doesn't increment it past
> > +      * INT_MAX.
> > +      */
> > +     if (bo->cpu_map_count != INT_MAX)
> > +             bo->cpu_map_count--;
> > +
> >       if (bo->cpu_map_count > 0) {
> >               /* mapped multiple times */
> >               pthread_mutex_unlock(&bo->cpu_access_mutex);
> >               return 0;
> >       }
> >
> >       r = drm_munmap(bo->cpu_ptr, bo->alloc_size) == 0 ? 0 : -errno;
> >       bo->cpu_ptr = NULL;
> >       pthread_mutex_unlock(&bo->cpu_access_mutex);
> >       return r;
>
>

[-- Attachment #1.2: Type: text/html, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 2/2] amdgpu: don't track handles for non-memory allocations

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 2012 bytes --]

OK. I'll drop this patch.

Marek

On Wed, Oct 24, 2018 at 4:14 AM Christian König <
ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Am 24.10.18 um 10:04 schrieb Michel Dänzer:
> > On 2018-10-23 9:07 p.m., Marek Olšák wrote:
> >> From: Marek Olšák <marek.olsak-5C7GfCeVMHo@public.gmane.org>
> >>
> >> ---
> >>   amdgpu/amdgpu_bo.c | 15 +++++++++------
> >>   1 file changed, 9 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> >> index 81f8a5f7..00b9b54a 100644
> >> --- a/amdgpu/amdgpu_bo.c
> >> +++ b/amdgpu/amdgpu_bo.c
> >> @@ -91,26 +91,29 @@ drm_public int amdgpu_bo_alloc(amdgpu_device_handle
> dev,
> >>      if (r)
> >>              goto out;
> >>
> >>      r = amdgpu_bo_create(dev, alloc_buffer->alloc_size,
> args.out.handle,
> >>                           buf_handle);
> >>      if (r) {
> >>              amdgpu_close_kms_handle(dev, args.out.handle);
> >>              goto out;
> >>      }
> >>
> >> -    pthread_mutex_lock(&dev->bo_table_mutex);
> >> -    r = handle_table_insert(&dev->bo_handles, (*buf_handle)->handle,
> >> -                            *buf_handle);
> >> -    pthread_mutex_unlock(&dev->bo_table_mutex);
> >> -    if (r)
> >> -            amdgpu_bo_free(*buf_handle);
> >> +    if (alloc_buffer->preferred_heap &
> >> +        (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {
> > What about AMDGPU_GEM_DOMAIN_CPU? I mean, that's unlikely to actually be
> > used here, but if it were, exporting and importing the resulting BO
> > should work fine?
> >
> > Instead of white-listing the domains which can be shared, it might be
> > better to black-list those which can't, i.e. GDS/GWS/OA.
>
> Well first of all GDS can be shared between applications.
>
> Then adding a BO to the tracking doesn't add much overhead (only 8 bytes
> and only if it was the last allocated).
>
> So I don't really see a reason why we should do this?
>
> Christian.
>

[-- Attachment #1.2: Type: text/html, Size: 2833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Michel Dänzer]

On 2018-10-29 10:15 p.m., Marek Olšák wrote:
> You and I discussed this extensively internally a while ago. It's expected
> and correct behavior. Mesa doesn't unmap some buffers and never will.

It doesn't need to keep mapping the same buffer over and over again
though, does it?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Koenig, Christian]

Am 30.10.18 um 09:20 schrieb Michel Dänzer:
> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
>> You and I discussed this extensively internally a while ago. It's expected
>> and correct behavior. Mesa doesn't unmap some buffers and never will.

Ah! Now I at least remember what issue that one was good for.

> It doesn't need to keep mapping the same buffer over and over again
> though, does it?

Yeah, that's a bit unclear to me as well.

Christian.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 729 bytes --]

On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org> wrote:

> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
> > You and I discussed this extensively internally a while ago. It's
> expected
> > and correct behavior. Mesa doesn't unmap some buffers and never will.
>
> It doesn't need to keep mapping the same buffer over and over again
> though, does it?
>

It doesnt map it again. It just doesnt unmap. So the next map call just
returns the pointer. It's correct to stop the counter wraparound.

Marek


>
> --
> Earthling Michel Dänzer               |               http://www.amd.com
> Libre software enthusiast             |             Mesa and X developer
>

[-- Attachment #1.2: Type: text/html, Size: 1439 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 1054 bytes --]

On Tue, Oct 30, 2018, 11:49 AM Marek Olšák <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

>
>
> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org> wrote:
>
>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
>> > You and I discussed this extensively internally a while ago. It's
>> expected
>> > and correct behavior. Mesa doesn't unmap some buffers and never will.
>>
>> It doesn't need to keep mapping the same buffer over and over again
>> though, does it?
>>
>
> It doesnt map it again. It just doesnt unmap. So the next map call just
> returns the pointer. It's correct to stop the counter wraparound.
>

Mesa doesn't track whether a buffer is already mapped. Libdrm tracks that.
It's a feature of libdrm to return the same pointer and expect infinite
number of map calls.

Marek


> Marek
>
>
>>
>> --
>> Earthling Michel Dänzer               |               http://www.amd.com
>> Libre software enthusiast             |             Mesa and X developer
>>
>

[-- Attachment #1.2: Type: text/html, Size: 2335 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 1345 bytes --]

On Tue, Oct 30, 2018, 11:52 AM Marek Olšák <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

>
>
> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>>
>>
>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org> wrote:
>>
>>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
>>> > You and I discussed this extensively internally a while ago. It's
>>> expected
>>> > and correct behavior. Mesa doesn't unmap some buffers and never will.
>>>
>>> It doesn't need to keep mapping the same buffer over and over again
>>> though, does it?
>>>
>>
>> It doesnt map it again. It just doesnt unmap. So the next map call just
>> returns the pointer. It's correct to stop the counter wraparound.
>>
>
> Mesa doesn't track whether a buffer is already mapped. Libdrm tracks that.
> It's a feature of libdrm to return the same pointer and expect infinite
> number of map calls.
>

Mesa has been having this optimization for 8 years. (since the radeon
winsys). It's surprising that it surprises you now.

Marek



> Marek
>
>
>> Marek
>>
>>
>>>
>>> --
>>> Earthling Michel Dänzer               |               http://www.amd.com
>>> Libre software enthusiast             |             Mesa and X developer
>>>
>>

[-- Attachment #1.2: Type: text/html, Size: 3216 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Michel Dänzer]

On 2018-10-30 4:52 p.m., Marek Olšák wrote:
> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák <maraeo@gmail.com> wrote:
>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel@daenzer.net> wrote:
>>
>>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
>>>> You and I discussed this extensively internally a while ago. It's
>>> expected
>>>> and correct behavior. Mesa doesn't unmap some buffers and never will.
>>>
>>> It doesn't need to keep mapping the same buffer over and over again
>>> though, does it?
>>>
>>
>> It doesnt map it again. It just doesnt unmap. So the next map call just
>> returns the pointer. It's correct to stop the counter wraparound.
>>
> 
> Mesa doesn't track whether a buffer is already mapped. Libdrm tracks that.
> It's a feature of libdrm to return the same pointer and expect infinite
> number of map calls.

That's not what the reference counting in libdrm is intended for. It's
for keeping track of how many independent callers have mapped the
buffer. Mesa should remember that it mapped a buffer and not map it again.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Koenig, Christian]

Am 30.10.18 um 16:59 schrieb Michel Dänzer:
> On 2018-10-30 4:52 p.m., Marek Olšák wrote:
>> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák <maraeo@gmail.com> wrote:
>>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel@daenzer.net> wrote:
>>>
>>>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
>>>>> You and I discussed this extensively internally a while ago. It's
>>>> expected
>>>>> and correct behavior. Mesa doesn't unmap some buffers and never will.
>>>> It doesn't need to keep mapping the same buffer over and over again
>>>> though, does it?
>>>>
>>> It doesnt map it again. It just doesnt unmap. So the next map call just
>>> returns the pointer. It's correct to stop the counter wraparound.
>>>
>> Mesa doesn't track whether a buffer is already mapped. Libdrm tracks that.
>> It's a feature of libdrm to return the same pointer and expect infinite
>> number of map calls.
> That's not what the reference counting in libdrm is intended for. It's
> for keeping track of how many independent callers have mapped the
> buffer. Mesa should remember that it mapped a buffer and not map it again.

Well if Mesa just wants to query the existing mapping then why not add a 
amdgpu_bo_get_cpu_ptr() which just queries if a CPU mapping exists and 
if yes returns the appropriate pointer or NULL otherwise?

I mean when we want to abstract everything in libdrm then we just need 
to add the functions we need to use this abstraction.

Christian.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 1835 bytes --]

On Wed, Oct 31, 2018 at 3:59 AM Koenig, Christian <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
wrote:

> Am 30.10.18 um 16:59 schrieb Michel Dänzer:
> > On 2018-10-30 4:52 p.m., Marek Olšák wrote:
> >> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org>
> wrote:
> >>>
> >>>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
> >>>>> You and I discussed this extensively internally a while ago. It's
> >>>> expected
> >>>>> and correct behavior. Mesa doesn't unmap some buffers and never will.
> >>>> It doesn't need to keep mapping the same buffer over and over again
> >>>> though, does it?
> >>>>
> >>> It doesnt map it again. It just doesnt unmap. So the next map call just
> >>> returns the pointer. It's correct to stop the counter wraparound.
> >>>
> >> Mesa doesn't track whether a buffer is already mapped. Libdrm tracks
> that.
> >> It's a feature of libdrm to return the same pointer and expect infinite
> >> number of map calls.
> > That's not what the reference counting in libdrm is intended for. It's
> > for keeping track of how many independent callers have mapped the
> > buffer. Mesa should remember that it mapped a buffer and not map it
> again.
>
> Well if Mesa just wants to query the existing mapping then why not add a
> amdgpu_bo_get_cpu_ptr() which just queries if a CPU mapping exists and
> if yes returns the appropriate pointer or NULL otherwise?
>
> I mean when we want to abstract everything in libdrm then we just need
> to add the functions we need to use this abstraction.
>

That can be future work for the sake of cleanliness and clarity, but it
would be a waste of time and wouldn't help old Mesa.

Marek

[-- Attachment #1.2: Type: text/html, Size: 2557 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Koenig, Christian]

[-- Attachment #1.1: Type: text/plain, Size: 2046 bytes --]

Am 31.10.18 um 23:12 schrieb Marek Olšák:
On Wed, Oct 31, 2018 at 3:59 AM Koenig, Christian <Christian.Koenig@amd.com<mailto:Christian.Koenig@amd.com>> wrote:
Am 30.10.18 um 16:59 schrieb Michel Dänzer:
> On 2018-10-30 4:52 p.m., Marek Olšák wrote:
>> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák <maraeo@gmail.com<mailto:maraeo@gmail.com>> wrote:
>>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel@daenzer.net<mailto:michel@daenzer.net>> wrote:
>>>
>>>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
>>>>> You and I discussed this extensively internally a while ago. It's
>>>> expected
>>>>> and correct behavior. Mesa doesn't unmap some buffers and never will.
>>>> It doesn't need to keep mapping the same buffer over and over again
>>>> though, does it?
>>>>
>>> It doesnt map it again. It just doesnt unmap. So the next map call just
>>> returns the pointer. It's correct to stop the counter wraparound.
>>>
>> Mesa doesn't track whether a buffer is already mapped. Libdrm tracks that.
>> It's a feature of libdrm to return the same pointer and expect infinite
>> number of map calls.
> That's not what the reference counting in libdrm is intended for. It's
> for keeping track of how many independent callers have mapped the
> buffer. Mesa should remember that it mapped a buffer and not map it again.

Well if Mesa just wants to query the existing mapping then why not add a
amdgpu_bo_get_cpu_ptr() which just queries if a CPU mapping exists and
if yes returns the appropriate pointer or NULL otherwise?

I mean when we want to abstract everything in libdrm then we just need
to add the functions we need to use this abstraction.

That can be future work for the sake of cleanliness and clarity, but it would be a waste of time and wouldn't help old Mesa.

That it doesn't help old Mesa is unfortunate, but this is clearly a bug in Mesa.

If old Mesa is broken then we should fix it by updating it and not add workarounds for specific clients in libdrm.

Regards,
Christian.


Marek


[-- Attachment #1.2: Type: text/html, Size: 3299 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 2707 bytes --]

On Fri, Nov 2, 2018 at 3:39 AM Koenig, Christian <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
wrote:

> Am 31.10.18 um 23:12 schrieb Marek Olšák:
>
> On Wed, Oct 31, 2018 at 3:59 AM Koenig, Christian <
> Christian.Koenig-5C7GfCeVMHo@public.gmane.org> wrote:
>
>> Am 30.10.18 um 16:59 schrieb Michel Dänzer:
>> > On 2018-10-30 4:52 p.m., Marek Olšák wrote:
>> >> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák <maraeo-Re5JQEeQqe8@public.gmane.orgm> wrote:
>> >>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org>
>> wrote:
>> >>>
>> >>>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
>> >>>>> You and I discussed this extensively internally a while ago. It's
>> >>>> expected
>> >>>>> and correct behavior. Mesa doesn't unmap some buffers and never
>> will.
>> >>>> It doesn't need to keep mapping the same buffer over and over again
>> >>>> though, does it?
>> >>>>
>> >>> It doesnt map it again. It just doesnt unmap. So the next map call
>> just
>> >>> returns the pointer. It's correct to stop the counter wraparound.
>> >>>
>> >> Mesa doesn't track whether a buffer is already mapped. Libdrm tracks
>> that.
>> >> It's a feature of libdrm to return the same pointer and expect infinite
>> >> number of map calls.
>> > That's not what the reference counting in libdrm is intended for. It's
>> > for keeping track of how many independent callers have mapped the
>> > buffer. Mesa should remember that it mapped a buffer and not map it
>> again.
>>
>> Well if Mesa just wants to query the existing mapping then why not add a
>> amdgpu_bo_get_cpu_ptr() which just queries if a CPU mapping exists and
>> if yes returns the appropriate pointer or NULL otherwise?
>>
>> I mean when we want to abstract everything in libdrm then we just need
>> to add the functions we need to use this abstraction.
>>
>
> That can be future work for the sake of cleanliness and clarity, but it
> would be a waste of time and wouldn't help old Mesa.
>
>
> That it doesn't help old Mesa is unfortunate, but this is clearly a bug in
> Mesa.
>
> If old Mesa is broken then we should fix it by updating it and not add
> workarounds for specific clients in libdrm.
>

It's not a workaround. We made a decision with amdgpu to share code by
moving portions of the Mesa winsys into libdrm. The map_count is part of
that. It's highly desirable to continue with code sharing. There is nothing
broken with Mesa. Mesa won't check whether a buffer is already mapped.
That's the responsibility of libdrm as part of code sharing and we don't
want to duplicate the same logic in Mesa. It's all part of the intended
design.

Marek

[-- Attachment #1.2: Type: text/html, Size: 3863 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx