Skip to contentSkip to conversation

tests/gem_ring_sync_copy: reduce memory usage

RFC In review [email protected] 5 participants 11 messages Nov 28, 2014

lore
Share & tools
lore

[email protected]

author
#0 lore raw

RFC 1/1 tests/gem_ring_sync_copy: reduce memory usage

From: Tim Gore <[email protected]>

gem_ring_sync_copy uses a lot of memory and gets OOM killed on smaller systems (eg android devices). Most of the allocation is for "busy work" to keep the render rings busy and for this we can just re-use the same few buffers over and over. This enables the test to be run on low end devices.

Signed-off-by Tim Gore <[email protected]>
---
 tests/gem_ring_sync_copy.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)
tests/gem_ring_sync_copy.c +15 -10
index 4a732d2..7257188 100644
@@ -57,6 +57,7 @@
 
 #define WIDTH	512
 #define HEIGHT	512
+#define NUM_BUSY_BUFFERS 32
 
 typedef struct {
 	int drm_fd;

@@ -163,11 +164,13 @@ static void render_busy(data_t *data)
 	size_t array_size;
 	int i;
 
-	array_size = data->n_buffers_load * sizeof(struct igt_buf);
+	/* allocate 32 buffer objects and re-use them as needed */
+	array_size = NUM_BUSY_BUFFERS * sizeof(struct igt_buf);
+
 	data->render.srcs = malloc(array_size);
 	data->render.dsts = malloc(array_size);
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		scratch_buf_init(data, &data->render.srcs[i], WIDTH, HEIGHT,
 				 0xdeadbeef);
 		scratch_buf_init(data, &data->render.dsts[i], WIDTH, HEIGHT,

@@ -177,10 +180,10 @@ static void render_busy(data_t *data)
 	for (i = 0; i < data->n_buffers_load; i++) {
 		data->render.copy(data->batch,
 				  NULL,			/* context */
-				  &data->render.srcs[i],
+				  &data->render.srcs[i % NUM_BUSY_BUFFERS],
 				  0, 0,			/* src_x, src_y */
 				  WIDTH, HEIGHT,
-				  &data->render.dsts[i],
+				  &data->render.dsts[i % NUM_BUSY_BUFFERS],
 				  0, 0			/* dst_x, dst_y */);
 	}
 }

@@ -189,7 +192,7 @@ static void render_busy_fini(data_t *data)
 {
 	int i;
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		drm_intel_bo_unreference(data->render.srcs[i].bo);
 		drm_intel_bo_unreference(data->render.dsts[i].bo);
 	}

@@ -225,11 +228,13 @@ static void blitter_busy(data_t *data)
 	size_t array_size;
 	int i;
 
-	array_size = data->n_buffers_load * sizeof(drm_intel_bo *);
+	/* allocate 32 buffer objects and re-use them as needed */
+	array_size = NUM_BUSY_BUFFERS * sizeof(drm_intel_bo *);
+
 	data->blitter.srcs = malloc(array_size);
 	data->blitter.dsts = malloc(array_size);
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		data->blitter.srcs[i] = bo_create(data,
 						  WIDTH, HEIGHT,
 						  0xdeadbeef);

@@ -240,8 +245,8 @@ static void blitter_busy(data_t *data)
 
 	for (i = 0; i < data->n_buffers_load; i++) {
 		intel_copy_bo(data->batch,
-			      data->blitter.srcs[i],
-			      data->blitter.dsts[i],
+			      data->blitter.srcs[i % NUM_BUSY_BUFFERS],
+			      data->blitter.dsts[i % NUM_BUSY_BUFFERS],
 			      WIDTH*HEIGHT*4);
 	}
 }

@@ -250,7 +255,7 @@ static void blitter_busy_fini(data_t *data)
 {
 	int i;
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		drm_intel_bo_unreference(data->blitter.srcs[i]);
 		drm_intel_bo_unreference(data->blitter.dsts[i]);
 	}
Signature · 6 lines
2.1.3

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
#1 lore raw
Quoted 10 lines · On Fri, Nov 28, 2014 at 02:46:24PM +0000, [email protected] wrote:

From: Tim Gore <[email protected]>

gem_ring_sync_copy uses a lot of memory and gets OOM killed on smaller systems (eg android devices). Most of the allocation is for "busy work" to keep the render rings busy and for this we can just re-use the same few buffers over and over. This enables the test to be run on low end devices.

Signed-off-by Tim Gore <[email protected]>

The one thing I'm wondering is how we can ensure that 32 is indeed enough to create a dependency between the two rings.

I'm not sure why you've chosen to remove n_buffers_load (without actually removing it from the test data. How about:

tests/gem_ring_sync_copy.c +1 -1
index 4a732d2..2561bac 100644
@@ -331,7 +331,7 @@ igt_main
                data.drm_fd = drm_open_any_render();
                data.devid = intel_get_drm_devid(data.drm_fd);
 
-               data.n_buffers_load = 1000;
+               data.n_buffers_load = 32;
 
                data.bufmgr = drm_intel_bufmgr_gem_init(data.drm_fd, 4096);
                igt_assert(data.bufmgr);
Signature · 1 line
Damien
Quoted 93 lines
---
 tests/gem_ring_sync_copy.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)
tests/gem_ring_sync_copy.c +15 -10
index 4a732d2..7257188 100644
@@ -57,6 +57,7 @@
 
 #define WIDTH	512
 #define HEIGHT	512
+#define NUM_BUSY_BUFFERS 32
 
 typedef struct {
 	int drm_fd;

@@ -163,11 +164,13 @@ static void render_busy(data_t *data)
 	size_t array_size;
 	int i;
 
-	array_size = data->n_buffers_load * sizeof(struct igt_buf);
+	/* allocate 32 buffer objects and re-use them as needed */
+	array_size = NUM_BUSY_BUFFERS * sizeof(struct igt_buf);
+
 	data->render.srcs = malloc(array_size);
 	data->render.dsts = malloc(array_size);
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		scratch_buf_init(data, &data->render.srcs[i], WIDTH, HEIGHT,
 				 0xdeadbeef);
 		scratch_buf_init(data, &data->render.dsts[i], WIDTH, HEIGHT,

@@ -177,10 +180,10 @@ static void render_busy(data_t *data)
 	for (i = 0; i < data->n_buffers_load; i++) {
 		data->render.copy(data->batch,
 				  NULL,			/* context */
-				  &data->render.srcs[i],
+				  &data->render.srcs[i % NUM_BUSY_BUFFERS],
 				  0, 0,			/* src_x, src_y */
 				  WIDTH, HEIGHT,
-				  &data->render.dsts[i],
+				  &data->render.dsts[i % NUM_BUSY_BUFFERS],
 				  0, 0			/* dst_x, dst_y */);
 	}
 }

@@ -189,7 +192,7 @@ static void render_busy_fini(data_t *data)
 {
 	int i;
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		drm_intel_bo_unreference(data->render.srcs[i].bo);
 		drm_intel_bo_unreference(data->render.dsts[i].bo);
 	}

@@ -225,11 +228,13 @@ static void blitter_busy(data_t *data)
 	size_t array_size;
 	int i;
 
-	array_size = data->n_buffers_load * sizeof(drm_intel_bo *);
+	/* allocate 32 buffer objects and re-use them as needed */
+	array_size = NUM_BUSY_BUFFERS * sizeof(drm_intel_bo *);
+
 	data->blitter.srcs = malloc(array_size);
 	data->blitter.dsts = malloc(array_size);
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		data->blitter.srcs[i] = bo_create(data,
 						  WIDTH, HEIGHT,
 						  0xdeadbeef);

@@ -240,8 +245,8 @@ static void blitter_busy(data_t *data)
 
 	for (i = 0; i < data->n_buffers_load; i++) {
 		intel_copy_bo(data->batch,
-			      data->blitter.srcs[i],
-			      data->blitter.dsts[i],
+			      data->blitter.srcs[i % NUM_BUSY_BUFFERS],
+			      data->blitter.dsts[i % NUM_BUSY_BUFFERS],
 			      WIDTH*HEIGHT*4);
 	}
 }

@@ -250,7 +255,7 @@ static void blitter_busy_fini(data_t *data)
 {
 	int i;
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		drm_intel_bo_unreference(data->blitter.srcs[i]);
 		drm_intel_bo_unreference(data->blitter.dsts[i]);
 	}
Signature · 1 line
2.1.3

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#2 lore raw
Quoted 40 lines

-----Original Message-----
From: Lespiau, Damien
Sent: Friday, November 28, 2014 3:39 PM
To: Gore, Tim
Cc: [email protected]
Subject: Re: [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 9 lines · On Fri, Nov 28, 2014 at 02:46:24PM +0000, [email protected] wrote:

From: Tim Gore <[email protected]>

gem_ring_sync_copy uses a lot of memory and gets OOM killed on smaller systems (eg android devices).
Most of the allocation is for "busy work" to keep the render rings busy and for this we can just re-use the same few buffers over and over. This enables the test to be run on low end devices.

Signed-off-by Tim Gore <[email protected]>

The one thing I'm wondering is how we can ensure that 32 is indeed enough to create a dependency between the two rings.

I'm not sure why you've chosen to remove n_buffers_load (without actually removing it from the test data. How about:

tests/gem_ring_sync_copy.c +1 -2
index 4a732d2..2561bac 100644
@@ -331,7 +331,7 @@ igt_main
                data.drm_fd = drm_open_any_render();
                data.devid = intel_get_drm_devid(data.drm_fd);
 
-               data.n_buffers_load = 1000;
+               data.n_buffers_load = 32;
 
                data.bufmgr = drm_intel_bufmgr_gem_init(data.drm_fd, 4096);
                igt_assert(data.bufmgr);
 
--
Quoted 2 lines

Damien

N_buffers_load is still used. I am still submitting 1000 buffers to the ring, its just that I use the same buffers over and over (hence the "i % NUM_BUSY_BUFFERS"). So I only allocate 32 buffers, and each gets copied 1000/32 times, so the ring is kept busy for as long as previously.

Tim

Quoted 87 lines
Quoted 20 lines
---
 tests/gem_ring_sync_copy.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)
tests/gem_ring_sync_copy.c +1 -0
index 4a732d2..7257188 100644
@@ -57,6 +57,7 @@
 
 #define WIDTH	512
 #define HEIGHT	512
+#define NUM_BUSY_BUFFERS 32
 
 typedef struct {
 	int drm_fd;

@@ -163,11 +164,13 @@ static void render_busy(data_t *data)
 	size_t array_size;
 	int i;

tests/gem_ring_sync_copy.c static void render_busy(data_t *data) · line 174

Quoted 10 lines
tests/gem_ring_sync_copy.c +4 -2
-	array_size = data->n_buffers_load * sizeof(struct igt_buf);
+	/* allocate 32 buffer objects and re-use them as needed */
+	array_size = NUM_BUSY_BUFFERS * sizeof(struct igt_buf);
+
 	data->render.srcs = malloc(array_size);
 	data->render.dsts = malloc(array_size);
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		scratch_buf_init(data, &data->render.srcs[i], WIDTH,

HEIGHT,

tests/gem_ring_sync_copy.c static void render_busy(data_t *data) · line 176

Quoted 2 lines
tests/gem_ring_sync_copy.c +0 -0
 				 0xdeadbeef);
 		scratch_buf_init(data, &data->render.dsts[i], WIDTH,

HEIGHT, @@

tests/gem_ring_sync_copy.c

Quoted 6 lines

-177,10 +180,10 @@ static void render_busy(data_t *data)

tests/gem_ring_sync_copy.c +1 -1
 	for (i = 0; i < data->n_buffers_load; i++) {
 		data->render.copy(data->batch,
 				  NULL,			/* context */
-				  &data->render.srcs[i],
+				  &data->render.srcs[i %

NUM_BUSY_BUFFERS],

tests/gem_ring_sync_copy.c

Quoted 4 lines
tests/gem_ring_sync_copy.c +1 -1
 				  0, 0,			/* src_x, src_y */
 				  WIDTH, HEIGHT,
-				  &data->render.dsts[i],
+				  &data->render.dsts[i %

NUM_BUSY_BUFFERS],

Quoted 41 lines
tests/gem_ring_sync_copy.c +7 -5
 				  0, 0			/* dst_x, dst_y */);
 	}
 }

@@ -189,7 +192,7 @@ static void render_busy_fini(data_t *data)  {
 	int i;
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		drm_intel_bo_unreference(data->render.srcs[i].bo);
 		drm_intel_bo_unreference(data->render.dsts[i].bo);
 	}

@@ -225,11 +228,13 @@ static void blitter_busy(data_t *data)
 	size_t array_size;
 	int i;
 
-	array_size = data->n_buffers_load * sizeof(drm_intel_bo *);
+	/* allocate 32 buffer objects and re-use them as needed */
+	array_size = NUM_BUSY_BUFFERS * sizeof(drm_intel_bo *);
+
 	data->blitter.srcs = malloc(array_size);
 	data->blitter.dsts = malloc(array_size);
 
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		data->blitter.srcs[i] = bo_create(data,
 						  WIDTH, HEIGHT,
 						  0xdeadbeef);

@@ -240,8 +245,8 @@ static void blitter_busy(data_t *data)
 
 	for (i = 0; i < data->n_buffers_load; i++) {
 		intel_copy_bo(data->batch,
-			      data->blitter.srcs[i],
-			      data->blitter.dsts[i],
+			      data->blitter.srcs[i % NUM_BUSY_BUFFERS],
+			      data->blitter.dsts[i % NUM_BUSY_BUFFERS],
 			      WIDTH*HEIGHT*4);
 	}
 }

@@ -250,7 +255,7 @@ static void blitter_busy_fini(data_t *data)  {
 	int i;
Quoted 8 lines
Quoted 8 lines
tests/gem_ring_sync_copy.c +1 -2
-	for (i = 0; i < data->n_buffers_load; i++) {
+	for (i = 0; i < NUM_BUSY_BUFFERS; i++) {
 		drm_intel_bo_unreference(data->blitter.srcs[i]);
 		drm_intel_bo_unreference(data->blitter.dsts[i]);
 	}
--

2.1.3

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

#3 lore raw
Quoted 4 lines · Tim

N_buffers_load is still used. I am still submitting 1000 buffers to the ring, its just that I use the same buffers over and over (hence the "i % NUM_BUSY_BUFFERS"). So I only allocate 32 buffers, and each gets copied 1000/32 times, so the ring is kept busy for as long as previously.

Ah oops, yes, indeed. Looks good then, pushed, thanks for the patch.

Signature · 5 lines
Damien
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
#4 lore raw
Quoted 7 lines · Damien Lespiau
Quoted 4 lines · Tim

N_buffers_load is still used. I am still submitting 1000 buffers to the ring, its just that I use the same buffers over and over (hence the "i % NUM_BUSY_BUFFERS"). So I only allocate 32 buffers, and each gets copied 1000/32 times, so the ring is kept busy for as long as previously.

Ah oops, yes, indeed. Looks good then, pushed, thanks for the patch.

The ring is kept as busy, but the queue depth is drastically reduced (from N_buffers to 32). Since both numbers are arbitrary, I am not adverse to the change, but I would feel happier if it was demonstrated that the new test is still capable of detecting bugs deliberately introduced into the ring synchronisation code.
-Chris

Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
author
#5 lore raw
Quoted 18 lines

-----Original Message-----
From: Chris Wilson [mailto:[email protected]]
Sent: Friday, November 28, 2014 4:20 PM
To: Lespiau, Damien
Cc: Gore, Tim; [email protected]
Subject: Re: [Intel-gfx] [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 3 lines · Damien Lespiau
Quoted 2 lines · Tim

N_buffers_load is still used. I am still submitting 1000 buffers to the ring, its just that I use the same buffers over and over (hence the "i %

NUM_BUSY_BUFFERS").

Quoted 3 lines
Quoted 2 lines

So I only allocate 32 buffers, and each gets copied 1000/32 times, so the ring is kept busy for as long as previously.

Quoted 9 lines
Quoted 1 line

Ah oops, yes, indeed. Looks good then, pushed, thanks for the patch.

The ring is kept as busy, but the queue depth is drastically reduced (from N_buffers to 32). Since both numbers are arbitrary, I am not adverse to the change, but I would feel happier if it was demonstrated that the new test is still capable of detecting bugs deliberately introduced into the ring synchronisation code.
-Chris

Excuse a rather novice question, but which queue depth is reduced?

Tim

Quoted 2 lines

--
Chris Wilson, Intel Open Source Technology Centre

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

#6 lore raw
Quoted 28 lines · Tim
Quoted 18 lines

-----Original Message-----
From: Chris Wilson [mailto:[email protected]]
Sent: Friday, November 28, 2014 4:20 PM
To: Lespiau, Damien
Cc: Gore, Tim; [email protected]
Subject: Re: [Intel-gfx] [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 3 lines · Damien Lespiau
Quoted 2 lines · Tim

N_buffers_load is still used. I am still submitting 1000 buffers to the ring, its just that I use the same buffers over and over (hence the "i %

NUM_BUSY_BUFFERS").

Quoted 3 lines
Quoted 2 lines

So I only allocate 32 buffers, and each gets copied 1000/32 times, so the ring is kept busy for as long as previously.

Quoted 9 lines
Quoted 1 line

Ah oops, yes, indeed. Looks good then, pushed, thanks for the patch.

The ring is kept as busy, but the queue depth is drastically reduced (from N_buffers to 32). Since both numbers are arbitrary, I am not adverse to the change, but I would feel happier if it was demonstrated that the new test is still capable of detecting bugs deliberately introduced into the ring synchronisation code.
-Chris

Quoted 1 line

Excuse a rather novice question, but which queue depth is reduced?

We track on the object the last read/write request. If you reuse objects the effective depth in the read/write queue is reduced, and this queue is implicitly used when synchronising between rings.
-Chris

Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
author
#7 lore raw
Quoted 39 lines

-----Original Message-----
From: Chris Wilson [mailto:[email protected]]
Sent: Friday, November 28, 2014 4:47 PM
To: Gore, Tim
Cc: Lespiau, Damien; [email protected]
Subject: Re: [Intel-gfx] [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 29 lines · Tim
Quoted 28 lines

-----Original Message-----
From: Chris Wilson [mailto:[email protected]]
Sent: Friday, November 28, 2014 4:20 PM
To: Lespiau, Damien
Cc: Gore, Tim; [email protected]
Subject: Re: [Intel-gfx] [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 4 lines · Damien Lespiau
Quoted 3 lines · Tim

N_buffers_load is still used. I am still submitting 1000 buffers to the ring, its just that I use the same buffers over and over (hence the "i %

NUM_BUSY_BUFFERS").

Quoted 4 lines
Quoted 2 lines

So I only allocate 32 buffers, and each gets copied 1000/32 times, so the ring is kept busy for as long as previously.

Ah oops, yes, indeed. Looks good then, pushed, thanks for the patch.

The ring is kept as busy, but the queue depth is drastically reduced (from N_buffers to 32). Since both numbers are arbitrary, I am not adverse to the change, but I would feel happier if it was demonstrated that the new test is still capable of detecting bugs deliberately introduced into the ring synchronisation code. -Chris

Quoted 7 lines
Quoted 1 line

Excuse a rather novice question, but which queue depth is reduced?

We track on the object the last read/write request. If you reuse objects the effective depth in the read/write queue is reduced, and this queue is implicitly used when synchronising between rings.
-Chris

OK thanks. So the test has changed but in a subtle way. It would seem that the main thrust of the test is still there but perhaps we could do better by checking how much memory we have and then using 1000 buffers of a size that we can accommodate.?

Tim

Quoted 2 lines

--
Chris Wilson, Intel Open Source Technology Centre

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

#8 lore raw
Quoted 47 lines · Tim
Quoted 39 lines

-----Original Message-----
From: Chris Wilson [mailto:[email protected]]
Sent: Friday, November 28, 2014 4:47 PM
To: Gore, Tim
Cc: Lespiau, Damien; [email protected]
Subject: Re: [Intel-gfx] [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 29 lines · Tim
Quoted 28 lines

-----Original Message-----
From: Chris Wilson [mailto:[email protected]]
Sent: Friday, November 28, 2014 4:20 PM
To: Lespiau, Damien
Cc: Gore, Tim; [email protected]
Subject: Re: [Intel-gfx] [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 4 lines · Damien Lespiau
Quoted 3 lines · Tim

N_buffers_load is still used. I am still submitting 1000 buffers to the ring, its just that I use the same buffers over and over (hence the "i %

NUM_BUSY_BUFFERS").

Quoted 4 lines
Quoted 2 lines

So I only allocate 32 buffers, and each gets copied 1000/32 times, so the ring is kept busy for as long as previously.

Ah oops, yes, indeed. Looks good then, pushed, thanks for the patch.

The ring is kept as busy, but the queue depth is drastically reduced (from N_buffers to 32). Since both numbers are arbitrary, I am not adverse to the change, but I would feel happier if it was demonstrated that the new test is still capable of detecting bugs deliberately introduced into the ring synchronisation code. -Chris

Quoted 7 lines
Quoted 1 line

Excuse a rather novice question, but which queue depth is reduced?

We track on the object the last read/write request. If you reuse objects the effective depth in the read/write queue is reduced, and this queue is implicitly used when synchronising between rings.
-Chris

Quoted 3 lines

OK thanks. So the test has changed but in a subtle way. It would seem that the main thrust of the test is still there but perhaps we could do better by checking how much memory we have and then using 1000 buffers of a size that we can accommodate.?

Yes. You could allocate 1000 single pages and perform lots of little copies in each page to generate the workload with large queue depths. Good idea. -Chris

Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
#9 lore raw
Quoted 48 lines · Chris Wilson
Quoted 47 lines · Tim
Quoted 46 lines

-----Original Message-----
From: Chris Wilson [mailto:[email protected]]
Sent: Friday, November 28, 2014 4:47 PM
To: Gore, Tim
Cc: Lespiau, Damien; [email protected]
Subject: Re: [Intel-gfx] [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 29 lines · Tim
Quoted 19 lines

-----Original Message-----
From: Chris Wilson [mailto:[email protected]]
Sent: Friday, November 28, 2014 4:20 PM
To: Lespiau, Damien
Cc: Gore, Tim; [email protected]
Subject: Re: [Intel-gfx] [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 4 lines · Damien Lespiau
Quoted 3 lines · Tim

N_buffers_load is still used. I am still submitting 1000 buffers to the ring, its just that I use the same buffers over and over (hence the "i %

NUM_BUSY_BUFFERS").

Quoted 3 lines
Quoted 2 lines

So I only allocate 32 buffers, and each gets copied 1000/32 times, so the ring is kept busy for as long as previously.

Quoted 9 lines
Quoted 1 line

Ah oops, yes, indeed. Looks good then, pushed, thanks for the patch.

The ring is kept as busy, but the queue depth is drastically reduced (from N_buffers to 32). Since both numbers are arbitrary, I am not adverse to the change, but I would feel happier if it was demonstrated that the new test is still capable of detecting bugs deliberately introduced into the ring synchronisation code. -Chris

Quoted 1 line

Excuse a rather novice question, but which queue depth is reduced?

We track on the object the last read/write request. If you reuse objects the effective depth in the read/write queue is reduced, and this queue is implicitly used when synchronising between rings.
-Chris

Quoted 6 lines
Quoted 3 lines

OK thanks. So the test has changed but in a subtle way. It would seem that the main thrust of the test is still there but perhaps we could do better by checking how much memory we have and then using 1000 buffers of a size that we can accommodate.?

Yes. You could allocate 1000 single pages and perform lots of little copies in each page to generate the workload with large queue depths. Good idea.

I think overall we have way too many copypastas of "throw load with depencies onto $engine with $ctx". Volunteers to extract something autotuning and use it everwhere highgly welcome ;-)

I think Ville is working on something for kms_flip (since on vlv the current workload takes to long and results in timeouts for flips and so test failures). But not sure whether he'll do the full librarization.

Aside on depencies: As long as we keep things in the same (implicit) context we won't reorder with the scheduler. Or at least that's been my working assumption while writing tests. Only for cross-ctx/fd/engine stuff do the actual depencies matter.
-Daniel

Signature · 7 lines
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
#10 lore raw
Quoted 56 lines · Daniel Vetter
Quoted 48 lines · Chris Wilson
Quoted 47 lines · Tim
Quoted 46 lines

-----Original Message-----
From: Chris Wilson [mailto:[email protected]]
Sent: Friday, November 28, 2014 4:47 PM
To: Gore, Tim
Cc: Lespiau, Damien; [email protected]
Subject: Re: [Intel-gfx] [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 29 lines · Tim
Quoted 19 lines

-----Original Message-----
From: Chris Wilson [mailto:[email protected]]
Sent: Friday, November 28, 2014 4:20 PM
To: Lespiau, Damien
Cc: Gore, Tim; [email protected]
Subject: Re: [Intel-gfx] [RFC] tests/gem_ring_sync_copy: reduce memory usage

Quoted 4 lines · Damien Lespiau
Quoted 3 lines · Tim

N_buffers_load is still used. I am still submitting 1000 buffers to the ring, its just that I use the same buffers over and over (hence the "i %

NUM_BUSY_BUFFERS").

Quoted 3 lines
Quoted 2 lines

So I only allocate 32 buffers, and each gets copied 1000/32 times, so the ring is kept busy for as long as previously.

Quoted 9 lines
Quoted 1 line

Ah oops, yes, indeed. Looks good then, pushed, thanks for the patch.

The ring is kept as busy, but the queue depth is drastically reduced (from N_buffers to 32). Since both numbers are arbitrary, I am not adverse to the change, but I would feel happier if it was demonstrated that the new test is still capable of detecting bugs deliberately introduced into the ring synchronisation code. -Chris

Quoted 1 line

Excuse a rather novice question, but which queue depth is reduced?

We track on the object the last read/write request. If you reuse objects the effective depth in the read/write queue is reduced, and this queue is implicitly used when synchronising between rings.
-Chris

Quoted 6 lines
Quoted 3 lines

OK thanks. So the test has changed but in a subtle way. It would seem that the main thrust of the test is still there but perhaps we could do better by checking how much memory we have and then using 1000 buffers of a size that we can accommodate.?

Yes. You could allocate 1000 single pages and perform lots of little copies in each page to generate the workload with large queue depths. Good idea.

Quoted 7 lines

I think overall we have way too many copypastas of "throw load with depencies onto $engine with $ctx". Volunteers to extract something autotuning and use it everwhere highgly welcome ;-)

I think Ville is working on something for kms_flip (since on vlv the current workload takes to long and results in timeouts for flips and so test failures). But not sure whether he'll do the full librarization.

My current hacked up dummy load stuff still lives in kms_flip. It just tries to tune for a 1 second delay now. And it still uses two bos to do the copies, but those are now fixed 2kx2k and only the final copy is aimed at the fb. Seems to working reosonably well now. I'll try to clean it up a bit and post it to the list, but it's getting a bit late here so that'll have to wait until early next week.

Signature · 6 lines
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx