| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
I was being overly miserly and gave the offset of the buffer into the bo
insufficient bits, distracted by the adjacency of the buffer[4096].
Ref: https://bugs.freedesktop.org/show_bug.cgi?id=34541
Signed-off-by: Chris Wilson <[email protected]>
|
| |
|
|
|
|
|
|
| |
... a leftover from a bad merge.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Reducing the number of relocations has lots of nice knock-on effects,
not least including reducing batch buffer size, auxilliary array sizes
(vmalloced and copied into the kernel), processing of uncached
relocations etc.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
Replace the intermediate tests due to the logical or with the bitwise
or.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Rather than waiting on the first batch after the last swapbuffers to be
retired, call into the kernel to wait upon the retirement of any request
less than 20ms old. This has the twofold advantage of (a) not blocking
any other clients from utilizing the device whilst we wait and (b) we
attain higher throughput without overloading the system.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
As we will flush when reading the return values of the blit, we can forgo
the earlier flush.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
| |
If the next vertex arrays are a (discontiguous) continuation of the
current arrays, such that the new vertices are simply offset from the
start of the current vertex buffer definitions we can reuse those
defintions and avoid the overhead of relocations and invalidations.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
| |
Use a temporary glarray variable to replace the numerous input->glarray.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
| |
Using a temporary buffer for large discontiguous uploads into the common
buffer and a single buffered upload is faster than performing the
discontiguous copies through a mapping into the GTT.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
Upload the non-vbo arrays into a single interleaved buffer object, and
so need to just emit a single vertex buffer relocation.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
If the user passed in several arrays interleaved in the same vbo, only
emit a single vertex buffer and relocation.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
Track reuse of the vertex buffer objects and so minimise the number of
vertex buffers used by the hardware (and their relocations).
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
| |
As we now pack the indices into a common upload buffer, we can reuse a
single CMD_INDEX_BUFFER packet and translate each invocation with a
start vertex offset.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
| |
Move the tracking of the last emitted instructions into the core
batchbuffer routines and take advantage of the shadow batch copy to
avoid extra memory allocations and copies.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
It's faster. Not only is the memcpy more efficiently performed in the
kernel (making up for the system call overhead), but by not using mmap
we remove the greater overhead of tracking the vma of every batch.
And it means we can read back from the batch buffer without incurring
the cost of a uncached read through the GTT.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
As we use state relocations and we know that all the state belongs to
the same bo, we can drop the multiple references to the same bo.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
As we write directly into the batch in system memory, we do not need to
write first to the stack (as was to avoid read back through the GTT)
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
As we write directly into the batch in system memory, we do not need to
write first to the stack (as was to avoid read back through the GTT)
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
In preparation for a greater change, use the color_calc_state_bo already
provisioned for this purpose.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Rather than performing lots of little writes to update the common bo
upon each update, write those into a static buffer and flush that when
full (or at the end of the batch). Doing so gives a dramatic performance
improvement over and above using mmaped access.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
Rather than performing a blit to completely overwrite a busy bo, simply
discard it and create a new one with the fresh data.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
Reuse the new common upload buffer for uploading temporary indices and
rebuilt vertex arrays.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
| |
Dynamic arrays have the tendency to be small and so allocating a bo for
each one is overkill and we can exploit many efficiency gains by packing
them together.
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dynamic draw buffers are used by clients for temporary arrays and for
uploading normal vertex arrays. By keeping the data in memory, we can
avoid reusing active buffer objects and reallocate them as they are
changed. This is important for Sandybridge which can not issue blits
within a batch and so ends up flushing the batch upon every update, that
is each batch only contains a single draw operation (if using dynamic
arrays or regular arrays from system memory).
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
| |
Following a GPU hang, or other error, the render target is not likely to
have an allocated BO and so we must fallback to avoid using it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32534
Signed-off-by: Chris Wilson <[email protected]>
|
| |
|
|
|
|
|
|
| |
We're using bo_subdata.
Signed-off-by: Daniel Vetter <[email protected]>
|
| |
|
| |
|
| |
|