If we are using a streaming GGTT write into the source, we need to
trigger an early fault in order to obtain a mappable offset. This is
required when later we start reserving execbuf object top-down to try
and avoid mappable space!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
During the streaming setup, we execute a dummy batch in order to bind
the objects into the GTT and query their offsets. For this, we should
not use a snooped buffer for the dummy batch, or else we may anger the
GPU. Given that we have a choice, use the other buffer for the dummy
batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The llc cpu path only partially mapped the batch buffer so confused the
CS when attempting to execute an empty batch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90809
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since our goal is to have concurrent read/writes of GPU buffers, we want
to spend as little time in between as possible.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use the first pass to write all values prior to the initial execbuf to
verify that the copy itself is true. Subsequent passes then focus on
verifying that writing values whilst the GPU is reading from
neighbouring values is then correct.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reduce memory usage for batches by a factor of 64 - which we immediately
spend some of in increasing the stress.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
