| Message ID | 20180607152723.21246-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Quoting Chris Wilson (2018-06-07 16:27:22) > Batches are contained in their position within the GTT by the kernel, constrained > and if they are in an invalid poistion will be unbound and rebound position > before execution. In our test setup, we therefore need to place the > batch into a valid poistion within the GTT before we fill the ring with > busyspinners.
On Thu, Jun 07, 2018 at 04:27:22PM +0100, Chris Wilson wrote: > Batches are contained in their position within the GTT by the kernel, > and if they are in an invalid poistion will be unbound and rebound > before execution. In our test setup, we therefore need to place the > batch into a valid poistion within the GTT before we fill the ring with > busyspinners. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com> Kasia :)
Quoting Katarzyna Dec (2018-06-08 08:36:35) > On Thu, Jun 07, 2018 at 04:27:22PM +0100, Chris Wilson wrote: > > Batches are contained in their position within the GTT by the kernel, > > and if they are in an invalid poistion will be unbound and rebound > > before execution. In our test setup, we therefore need to place the > > batch into a valid poistion within the GTT before we fill the ring with > > busyspinners. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com> Sorry for being curt on irc, not enough coffee. The problem entirely lies in how we are constructing our set of busy spinning batches. We try to fill the ring with a chain of batches that are all linked to one buffer, and then try to execute that buffer. This gives us the most implicit fences on that one buffer we can trivially construct; with the goal being that the kernel handles them all with aplomb. However, what we failed to take into account was that we might end up with that final buffer being at address 0, which is in an invalid location to execute from (because reasons) and the kernel would be forced to move it. However, since we have a ring full of busy spinners all using that buffer, we can not move that buffer until we wait for the queue to complete -- which it never will and so we declare a GPU hang, failing the test. -Chris
diff --git a/tests/gem_exec_await.c b/tests/gem_exec_await.c index b0d5c9045..5cfeb8ec8 100644 --- a/tests/gem_exec_await.c +++ b/tests/gem_exec_await.c @@ -135,6 +135,9 @@ static void wide(int fd, int ring_size, int timeout, unsigned int flags) gem_write(fd, obj[nengine*ring_size].handle, 0, &bbe, sizeof(bbe)); memset(&execbuf, 0, sizeof(execbuf)); + execbuf.buffers_ptr = to_user_pointer(&obj[nengine*ring_size]); + execbuf.buffer_count = 1; + gem_execbuf(fd, &execbuf); /* tag the object as a batch in the GTT */ execbuf.buffers_ptr = to_user_pointer(obj); execbuf.buffer_count = nengine*ring_size + 1;
Batches are contained in their position within the GTT by the kernel, and if they are in an invalid poistion will be unbound and rebound before execution. In our test setup, we therefore need to place the batch into a valid poistion within the GTT before we fill the ring with busyspinners. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- tests/gem_exec_await.c | 3 +++ 1 file changed, 3 insertions(+)