* [PATCH i-g-t 0/3] aubdump: A few improvements
@ 2017-08-23 17:14 Jason Ekstrand
2017-08-23 17:14 ` [PATCH i-g-t 1/3] aubdump: Reject execbuffer2 calls with bad BOs Jason Ekstrand
` (5 more replies)
0 siblings, 6 replies; 10+ messages in thread
From: Jason Ekstrand @ 2017-08-23 17:14 UTC (permalink / raw)
To: intel-gfx; +Cc: Jason Ekstrand
These three patches are improvements that I've had locally in my tree for
some period of time. The first one is required for Vulkan to work
correctly with aubdump ever since we turned on 48-bit addressing. The
second is just a bit of future-proofing. The third makes the tool dump
some information to stderr which I have found very useful when debugging
things.
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Jason Ekstrand (3):
aubdump: Reject execbuffer2 calls with bad BOs
aubdump: Use write_reloc for filling out the ringbuffer
aubdump: Log some information about the execbuf calls
tools/aubdump.c | 80 +++++++++++++++++++++++++++++++++------------------------
1 file changed, 46 insertions(+), 34 deletions(-)
--
2.5.0.400.gff86faf
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH i-g-t 1/3] aubdump: Reject execbuffer2 calls with bad BOs
2017-08-23 17:14 [PATCH i-g-t 0/3] aubdump: A few improvements Jason Ekstrand
@ 2017-08-23 17:14 ` Jason Ekstrand
2017-08-23 20:28 ` Lionel Landwerlin
2017-08-23 17:14 ` [PATCH i-g-t 2/3] aubdump: Use write_reloc for filling out the ringbuffer Jason Ekstrand
` (4 subsequent siblings)
5 siblings, 1 reply; 10+ messages in thread
From: Jason Ekstrand @ 2017-08-23 17:14 UTC (permalink / raw)
To: intel-gfx; +Cc: Jason Ekstrand
This is required for the supports_48b_addresses check in the Vulkan
driver to work without messing up the resulting aub.
---
tools/aubdump.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/tools/aubdump.c b/tools/aubdump.c
index 610526c..c14c9fa 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -426,6 +426,12 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
obj = &exec_objects[i];
bo = get_bo(obj->handle);
+ /* If bo->size == 0, this means they passed us an invalid
+ * buffer. The kernel will reject it and so should we.
+ */
+ if (bo->size == 0)
+ return;
+
if (obj->flags & EXEC_OBJECT_PINNED) {
bo->offset = obj->offset;
} else {
@@ -475,6 +481,7 @@ add_new_bo(int handle, uint64_t size, void *map)
struct bo *bo = &bos[handle];
fail_if(handle >= MAX_BO_COUNT, "intel_aubdump: bo handle out of range\n");
+ fail_if(size == 0, "intel_aubdump: bo size is invalid\n");
bo->size = size;
bo->map = map;
@@ -487,6 +494,7 @@ remove_bo(int handle)
if (bo->map && !IS_USERPTR(bo->map))
munmap(bo->map, bo->size);
+ bo->size = 0;
bo->map = NULL;
}
--
2.5.0.400.gff86faf
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH i-g-t 2/3] aubdump: Use write_reloc for filling out the ringbuffer
2017-08-23 17:14 [PATCH i-g-t 0/3] aubdump: A few improvements Jason Ekstrand
2017-08-23 17:14 ` [PATCH i-g-t 1/3] aubdump: Reject execbuffer2 calls with bad BOs Jason Ekstrand
@ 2017-08-23 17:14 ` Jason Ekstrand
2017-08-23 20:31 ` Lionel Landwerlin
2017-08-23 17:14 ` [PATCH i-g-t 3/3] aubdump: Log some information about the execbuf calls Jason Ekstrand
` (3 subsequent siblings)
5 siblings, 1 reply; 10+ messages in thread
From: Jason Ekstrand @ 2017-08-23 17:14 UTC (permalink / raw)
To: intel-gfx; +Cc: Jason Ekstrand
---
tools/aubdump.c | 66 ++++++++++++++++++++++++++++-----------------------------
1 file changed, 32 insertions(+), 34 deletions(-)
diff --git a/tools/aubdump.c b/tools/aubdump.c
index c14c9fa..567de3d 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -262,9 +262,36 @@ aub_write_trace_block(uint32_t type, void *virtual, uint32_t size, uint64_t gtt_
}
static void
+write_reloc(void *p, uint64_t v)
+{
+ if (gen >= 8) {
+ /* From the Broadwell PRM Vol. 2a,
+ * MI_LOAD_REGISTER_MEM::MemoryAddress:
+ *
+ * "This field specifies the address of the memory
+ * location where the register value specified in the
+ * DWord above will read from. The address specifies
+ * the DWord location of the data. Range =
+ * GraphicsVirtualAddress[63:2] for a DWord register
+ * GraphicsAddress [63:48] are ignored by the HW and
+ * assumed to be in correct canonical form [63:48] ==
+ * [47]."
+ *
+ * In practice, this will always mean the top bits are zero
+ * because of the GTT size limitation of the aubdump tool.
+ */
+ const int shift = 63 - 47;
+ *(uint64_t *)p = (((int64_t)v) << shift) >> shift;
+ } else {
+ *(uint32_t *)p = v;
+ }
+}
+
+static void
aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
{
uint32_t ringbuffer[4096];
+ unsigned aub_mi_bbs_len;
int ring = AUB_TRACE_TYPE_RING_PRB0; /* The default ring */
int ring_count = 0;
@@ -275,14 +302,11 @@ aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
/* Make a ring buffer to execute our batchbuffer. */
memset(ringbuffer, 0, sizeof(ringbuffer));
- if (gen >= 8) {
- ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START | (3 - 2);
- ringbuffer[ring_count++] = batch_offset;
- ringbuffer[ring_count++] = batch_offset >> 32;
- } else {
- ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START;
- ringbuffer[ring_count++] = batch_offset;
- }
+
+ aub_mi_bbs_len = gen >= 8 ? 3 : 2;
+ ringbuffer[ring_count] = AUB_MI_BATCH_BUFFER_START | (aub_mi_bbs_len - 2);
+ write_reloc(&ringbuffer[ring_count + 1], batch_offset);
+ ring_count += aub_mi_bbs_len;
/* Write out the ring. This appears to trigger execution of
* the ring in the simulator.
@@ -299,32 +323,6 @@ aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
data_out(ringbuffer, ring_count * 4);
}
-static void
-write_reloc(void *p, uint64_t v)
-{
- if (gen >= 8) {
- /* From the Broadwell PRM Vol. 2a,
- * MI_LOAD_REGISTER_MEM::MemoryAddress:
- *
- * "This field specifies the address of the memory
- * location where the register value specified in the
- * DWord above will read from. The address specifies
- * the DWord location of the data. Range =
- * GraphicsVirtualAddress[63:2] for a DWord register
- * GraphicsAddress [63:48] are ignored by the HW and
- * assumed to be in correct canonical form [63:48] ==
- * [47]."
- *
- * In practice, this will always mean the top bits are zero
- * because of the GTT size limitation of the aubdump tool.
- */
- const int shift = 63 - 47;
- *(uint64_t *)p = (((int64_t)v) << shift) >> shift;
- } else {
- *(uint32_t *)p = v;
- }
-}
-
static void *
relocate_bo(struct bo *bo, const struct drm_i915_gem_execbuffer2 *execbuffer2,
const struct drm_i915_gem_exec_object2 *obj)
--
2.5.0.400.gff86faf
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH i-g-t 3/3] aubdump: Log some information about the execbuf calls
2017-08-23 17:14 [PATCH i-g-t 0/3] aubdump: A few improvements Jason Ekstrand
2017-08-23 17:14 ` [PATCH i-g-t 1/3] aubdump: Reject execbuffer2 calls with bad BOs Jason Ekstrand
2017-08-23 17:14 ` [PATCH i-g-t 2/3] aubdump: Use write_reloc for filling out the ringbuffer Jason Ekstrand
@ 2017-08-23 17:14 ` Jason Ekstrand
2017-08-23 18:00 ` Scott D Phillips
2017-08-23 17:33 ` ✗ Fi.CI.BAT: failure for aubdump: A few improvements Patchwork
` (2 subsequent siblings)
5 siblings, 1 reply; 10+ messages in thread
From: Jason Ekstrand @ 2017-08-23 17:14 UTC (permalink / raw)
To: intel-gfx; +Cc: Jason Ekstrand
---
tools/aubdump.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/aubdump.c b/tools/aubdump.c
index 567de3d..cf4c6e8 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -405,6 +405,8 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
struct bo *bo, *batch_bo;
void *data;
+ fprintf(stderr, "Dumping execbuffer2:\n");
+
/* We can't do this at open time as we're not yet authenticated. */
if (device == 0) {
device = gem_get_param(fd, I915_PARAM_CHIPSET_ID);
@@ -427,8 +429,12 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
/* If bo->size == 0, this means they passed us an invalid
* buffer. The kernel will reject it and so should we.
*/
- if (bo->size == 0)
+ if (bo->size == 0) {
+ fprintf(stderr, "BO #%d is invalid!\n", obj->handle);
return;
+ }
+
+ fprintf(stderr, "BO #%d (%dB) @ 0x%x\n", obj->handle, bo->size, offset);
if (obj->flags & EXEC_OBJECT_PINNED) {
bo->offset = obj->offset;
--
2.5.0.400.gff86faf
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 10+ messages in thread
* ✗ Fi.CI.BAT: failure for aubdump: A few improvements
2017-08-23 17:14 [PATCH i-g-t 0/3] aubdump: A few improvements Jason Ekstrand
` (2 preceding siblings ...)
2017-08-23 17:14 ` [PATCH i-g-t 3/3] aubdump: Log some information about the execbuf calls Jason Ekstrand
@ 2017-08-23 17:33 ` Patchwork
2017-08-24 13:00 ` ✓ Fi.CI.BAT: success " Patchwork
2017-08-24 14:03 ` ✓ Fi.CI.IGT: " Patchwork
5 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2017-08-23 17:33 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: intel-gfx
== Series Details ==
Series: aubdump: A few improvements
URL : https://patchwork.freedesktop.org/series/29225/
State : failure
== Summary ==
IGT patchset tested on top of latest successful build
42b42c99cd9d1b890807ae97cbd1c593396ae051 tests/Makefile.am: Wrap audio test with dedicated conditional
with latest DRM-Tip kernel build CI_DRM_2995
2964b2f40295 drm-tip: 2017y-08m-23d-13h-11m-32s UTC integration manifest
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
pass -> FAIL (fi-hsw-4770)
Subgroup basic-flip-before-cursor-varying-size:
pass -> FAIL (fi-hsw-4770)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass -> SKIP (fi-skl-x1585l) fdo#101781
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:457s
fi-bdw-gvtdvm total:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:438s
fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:366s
fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:568s
fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:251s
fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:518s
fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:531s
fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:529s
fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:440s
fi-glk-2a total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:618s
fi-hsw-4770 total:279 pass:261 dwarn:0 dfail:0 fail:2 skip:16 time:443s
fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:425s
fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:419s
fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:509s
fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s
fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s
fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:598s
fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:603s
fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:529s
fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:468s
fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:480s
fi-skl-6770hq total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:489s
fi-skl-gvtdvm total:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s
fi-skl-x1585l total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:488s
fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:550s
fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:408s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_91/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH i-g-t 3/3] aubdump: Log some information about the execbuf calls
2017-08-23 17:14 ` [PATCH i-g-t 3/3] aubdump: Log some information about the execbuf calls Jason Ekstrand
@ 2017-08-23 18:00 ` Scott D Phillips
0 siblings, 0 replies; 10+ messages in thread
From: Scott D Phillips @ 2017-08-23 18:00 UTC (permalink / raw)
To: Jason Ekstrand, intel-gfx; +Cc: Jason Ekstrand
Jason Ekstrand <jason@jlekstrand.net> writes:
> ---
> tools/aubdump.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/tools/aubdump.c b/tools/aubdump.c
> index 567de3d..cf4c6e8 100644
> --- a/tools/aubdump.c
> +++ b/tools/aubdump.c
> @@ -405,6 +405,8 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
> struct bo *bo, *batch_bo;
> void *data;
>
> + fprintf(stderr, "Dumping execbuffer2:\n");
> +
Maybe put these prints under an `if (verbose)'. Series is
Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>
> /* We can't do this at open time as we're not yet authenticated. */
> if (device == 0) {
> device = gem_get_param(fd, I915_PARAM_CHIPSET_ID);
> @@ -427,8 +429,12 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
> /* If bo->size == 0, this means they passed us an invalid
> * buffer. The kernel will reject it and so should we.
> */
> - if (bo->size == 0)
> + if (bo->size == 0) {
> + fprintf(stderr, "BO #%d is invalid!\n", obj->handle);
> return;
> + }
> +
> + fprintf(stderr, "BO #%d (%dB) @ 0x%x\n", obj->handle, bo->size, offset);
>
> if (obj->flags & EXEC_OBJECT_PINNED) {
> bo->offset = obj->offset;
> --
> 2.5.0.400.gff86faf
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH i-g-t 1/3] aubdump: Reject execbuffer2 calls with bad BOs
2017-08-23 17:14 ` [PATCH i-g-t 1/3] aubdump: Reject execbuffer2 calls with bad BOs Jason Ekstrand
@ 2017-08-23 20:28 ` Lionel Landwerlin
0 siblings, 0 replies; 10+ messages in thread
From: Lionel Landwerlin @ 2017-08-23 20:28 UTC (permalink / raw)
To: Jason Ekstrand, intel-gfx; +Cc: Jason Ekstrand
Heh, fixed the same in ksim. Don't know why I didn't see it while using
aubdump recently...
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
On 23/08/17 18:14, Jason Ekstrand wrote:
> This is required for the supports_48b_addresses check in the Vulkan
> driver to work without messing up the resulting aub.
> ---
> tools/aubdump.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/tools/aubdump.c b/tools/aubdump.c
> index 610526c..c14c9fa 100644
> --- a/tools/aubdump.c
> +++ b/tools/aubdump.c
> @@ -426,6 +426,12 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
> obj = &exec_objects[i];
> bo = get_bo(obj->handle);
>
> + /* If bo->size == 0, this means they passed us an invalid
> + * buffer. The kernel will reject it and so should we.
> + */
> + if (bo->size == 0)
> + return;
> +
> if (obj->flags & EXEC_OBJECT_PINNED) {
> bo->offset = obj->offset;
> } else {
> @@ -475,6 +481,7 @@ add_new_bo(int handle, uint64_t size, void *map)
> struct bo *bo = &bos[handle];
>
> fail_if(handle >= MAX_BO_COUNT, "intel_aubdump: bo handle out of range\n");
> + fail_if(size == 0, "intel_aubdump: bo size is invalid\n");
>
> bo->size = size;
> bo->map = map;
> @@ -487,6 +494,7 @@ remove_bo(int handle)
>
> if (bo->map && !IS_USERPTR(bo->map))
> munmap(bo->map, bo->size);
> + bo->size = 0;
> bo->map = NULL;
> }
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH i-g-t 2/3] aubdump: Use write_reloc for filling out the ringbuffer
2017-08-23 17:14 ` [PATCH i-g-t 2/3] aubdump: Use write_reloc for filling out the ringbuffer Jason Ekstrand
@ 2017-08-23 20:31 ` Lionel Landwerlin
0 siblings, 0 replies; 10+ messages in thread
From: Lionel Landwerlin @ 2017-08-23 20:31 UTC (permalink / raw)
To: Jason Ekstrand, intel-gfx; +Cc: Jason Ekstrand
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
On 23/08/17 18:14, Jason Ekstrand wrote:
> ---
> tools/aubdump.c | 66 ++++++++++++++++++++++++++++-----------------------------
> 1 file changed, 32 insertions(+), 34 deletions(-)
>
> diff --git a/tools/aubdump.c b/tools/aubdump.c
> index c14c9fa..567de3d 100644
> --- a/tools/aubdump.c
> +++ b/tools/aubdump.c
> @@ -262,9 +262,36 @@ aub_write_trace_block(uint32_t type, void *virtual, uint32_t size, uint64_t gtt_
> }
>
> static void
> +write_reloc(void *p, uint64_t v)
> +{
> + if (gen >= 8) {
> + /* From the Broadwell PRM Vol. 2a,
> + * MI_LOAD_REGISTER_MEM::MemoryAddress:
> + *
> + * "This field specifies the address of the memory
> + * location where the register value specified in the
> + * DWord above will read from. The address specifies
> + * the DWord location of the data. Range =
> + * GraphicsVirtualAddress[63:2] for a DWord register
> + * GraphicsAddress [63:48] are ignored by the HW and
> + * assumed to be in correct canonical form [63:48] ==
> + * [47]."
> + *
> + * In practice, this will always mean the top bits are zero
> + * because of the GTT size limitation of the aubdump tool.
> + */
> + const int shift = 63 - 47;
> + *(uint64_t *)p = (((int64_t)v) << shift) >> shift;
> + } else {
> + *(uint32_t *)p = v;
> + }
> +}
> +
> +static void
> aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
> {
> uint32_t ringbuffer[4096];
> + unsigned aub_mi_bbs_len;
> int ring = AUB_TRACE_TYPE_RING_PRB0; /* The default ring */
> int ring_count = 0;
>
> @@ -275,14 +302,11 @@ aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
>
> /* Make a ring buffer to execute our batchbuffer. */
> memset(ringbuffer, 0, sizeof(ringbuffer));
> - if (gen >= 8) {
> - ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START | (3 - 2);
> - ringbuffer[ring_count++] = batch_offset;
> - ringbuffer[ring_count++] = batch_offset >> 32;
> - } else {
> - ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START;
> - ringbuffer[ring_count++] = batch_offset;
> - }
> +
> + aub_mi_bbs_len = gen >= 8 ? 3 : 2;
> + ringbuffer[ring_count] = AUB_MI_BATCH_BUFFER_START | (aub_mi_bbs_len - 2);
> + write_reloc(&ringbuffer[ring_count + 1], batch_offset);
> + ring_count += aub_mi_bbs_len;
>
> /* Write out the ring. This appears to trigger execution of
> * the ring in the simulator.
> @@ -299,32 +323,6 @@ aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
> data_out(ringbuffer, ring_count * 4);
> }
>
> -static void
> -write_reloc(void *p, uint64_t v)
> -{
> - if (gen >= 8) {
> - /* From the Broadwell PRM Vol. 2a,
> - * MI_LOAD_REGISTER_MEM::MemoryAddress:
> - *
> - * "This field specifies the address of the memory
> - * location where the register value specified in the
> - * DWord above will read from. The address specifies
> - * the DWord location of the data. Range =
> - * GraphicsVirtualAddress[63:2] for a DWord register
> - * GraphicsAddress [63:48] are ignored by the HW and
> - * assumed to be in correct canonical form [63:48] ==
> - * [47]."
> - *
> - * In practice, this will always mean the top bits are zero
> - * because of the GTT size limitation of the aubdump tool.
> - */
> - const int shift = 63 - 47;
> - *(uint64_t *)p = (((int64_t)v) << shift) >> shift;
> - } else {
> - *(uint32_t *)p = v;
> - }
> -}
> -
> static void *
> relocate_bo(struct bo *bo, const struct drm_i915_gem_execbuffer2 *execbuffer2,
> const struct drm_i915_gem_exec_object2 *obj)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* ✓ Fi.CI.BAT: success for aubdump: A few improvements
2017-08-23 17:14 [PATCH i-g-t 0/3] aubdump: A few improvements Jason Ekstrand
` (3 preceding siblings ...)
2017-08-23 17:33 ` ✗ Fi.CI.BAT: failure for aubdump: A few improvements Patchwork
@ 2017-08-24 13:00 ` Patchwork
2017-08-24 14:03 ` ✓ Fi.CI.IGT: " Patchwork
5 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2017-08-24 13:00 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: intel-gfx
== Series Details ==
Series: aubdump: A few improvements
URL : https://patchwork.freedesktop.org/series/29225/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
80cc54023e198165eca34450e9cc75c9cffcb072 lib/core: Use igt_info instead of printf
with latest DRM-Tip kernel build CI_DRM_2998
3adc9e3cacef drm-tip: 2017y-08m-23d-21h-35m-35s UTC integration manifest
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass -> DMESG-WARN (fi-byt-n2820) fdo#101705
Subgroup suspend-read-crc-pipe-c:
fail -> PASS (fi-skl-6700k) fdo#100367
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705
fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367
fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:454s
fi-bdw-gvtdvm total:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:439s
fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:365s
fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:557s
fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:253s
fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:526s
fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:525s
fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:517s
fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:437s
fi-glk-2a total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:621s
fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:447s
fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:420s
fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:420s
fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:504s
fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s
fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:479s
fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:598s
fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:526s
fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:474s
fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:482s
fi-skl-6770hq total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:494s
fi-skl-gvtdvm total:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:453s
fi-skl-x1585l total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:486s
fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:551s
fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:412s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_93/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* ✓ Fi.CI.IGT: success for aubdump: A few improvements
2017-08-23 17:14 [PATCH i-g-t 0/3] aubdump: A few improvements Jason Ekstrand
` (4 preceding siblings ...)
2017-08-24 13:00 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2017-08-24 14:03 ` Patchwork
5 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2017-08-24 14:03 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: intel-gfx
== Series Details ==
Series: aubdump: A few improvements
URL : https://patchwork.freedesktop.org/series/29225/
State : success
== Summary ==
shard-hsw total:2230 pass:1229 dwarn:0 dfail:0 fail:19 skip:982 time:9603s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_93/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-08-24 14:03 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-23 17:14 [PATCH i-g-t 0/3] aubdump: A few improvements Jason Ekstrand
2017-08-23 17:14 ` [PATCH i-g-t 1/3] aubdump: Reject execbuffer2 calls with bad BOs Jason Ekstrand
2017-08-23 20:28 ` Lionel Landwerlin
2017-08-23 17:14 ` [PATCH i-g-t 2/3] aubdump: Use write_reloc for filling out the ringbuffer Jason Ekstrand
2017-08-23 20:31 ` Lionel Landwerlin
2017-08-23 17:14 ` [PATCH i-g-t 3/3] aubdump: Log some information about the execbuf calls Jason Ekstrand
2017-08-23 18:00 ` Scott D Phillips
2017-08-23 17:33 ` ✗ Fi.CI.BAT: failure for aubdump: A few improvements Patchwork
2017-08-24 13:00 ` ✓ Fi.CI.BAT: success " Patchwork
2017-08-24 14:03 ` ✓ Fi.CI.IGT: " Patchwork
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.