| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In theory gcc is free to re-load them, and if a concurrent
execbuf races and updates bo->offset64 then we have a problem:
execbuffer api requires that the ->presumed_offset and the one
we used for the reloc matches. It does not require that the value
is sensible, which means no locks needed, just a consistent load.
Ken said his next series will nuke this, so just hand-roll the
kernel's READ_ONCE idea inline.
FIXME: Most callers of brw_emit_reloc recompute the relocation
themselves, which means this doesn't really fix the race. But the long
term plan is to move to per-context relocation handling, which will
fix this all properly. So leave this for now as just a reminder.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This was done because the kernel has 1 global address space, shared
with all render clients, for gtt mmap offsets, and that address space
was only 32bit on 32bit kernels.
This was fixed in
commit 440fd5283a87345cdd4237bdf45fb01130ea0056
Author: Thierry Reding <treding@nvidia.com>
Date: Fri Jan 23 09:05:06 2015 +0100
drm/mm: Support 4 GiB and larger ranges
which shipped in 4.0. Of course you still want to limit the bo cache
to a reasonable size on 32bit apps to avoid ENOMEM, but that's better
solved by tuning the cache a bit. On 64bit, this was never an issue.
On top, mesa never set this, so it's all dead code. Collect an trash it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
is_reusable was needed by uxa because it couldn't keep track of its
scanout buffers and used this as a proxy. Disabling reuse is a silly
idea, we set this once at start. Remove both.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Iirc this was used by uxa for persistent mmpas of the frontbuffer. For
mesa all the set_domain stuff needed before a synchronized mmap is handled
within the bufmgr, so no reason ever to call this.
Inline the implementation into its only internal user.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Entirely unused, and really shouldn't be used. The alloc functions already
take care of this. And even in a future where we're not going to
h/v-align tiled buffers in the bufmgr, but only in isl, I think we
still want to adjust the tiling mode in the bufmgr, since that ties in
closely to mmaps and stuff like that.
get_tiling is still needed for the import paths (until we have modifiers
everywhere).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Entirely unused, mesa instead used the BO_ALLOC_FOR_RENDER flag.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Noticed while reading
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Matches the class name and the header file name.
|
|
indent -i3 -nut -br -brs -npcs -ce --no-tabs -Tuint32_t -Tuint64_t
plus some manual fixes because those aren't quite the right settings.
|
|
The bacon is all gone.
This renames both the class and the related functions. We're about to
run indent on the bufmgr code, so no need to worry about fixing bad
indentation.
|
|
The stupid reason for eliminating these functions is that I'm about
to rename drm_bacon_bo_map() to brw_bo_map(), which makes the real
function have the short name, rather than the wrapper.
I'm also planning on reworking our mapping code soon, so we use WC
mappings and proper unsynchronized mappings on non-LLC platforms.
It will be easier to do that without thinking about the stall
warnings and wrappers.
My eventual hope is to put the performance warnings in the BO map
function itself, so all callers gain the warning.
|
|
Less bacon.
|
|
Also stop using typedefs, per Mesa coding style.
|
|
drm_bacon_context is a malloc'd struct containing a uint32_t context ID
and a pointer back to the bufmgr. The bufmgr pointer is pretty useless,
as everybody already has brw->bufmgr. At that point...we may as well
just use the ctx_id handle directly. A number of places already had to
call drm_bacon_gem_context_get_id() to extract the ID anyway. Now they
just have it.
|
|
|
|
No need for a prefix as this struct is local to the .c file.
Less bacon.
|
|
Mesa style is to not use lengthy prefixes for static functions.
|
|
The only difference is that it takes an explicit bufmgr rather than
using bo->bufmgr, but there is only one bufmgr per screen so they
should be identical anyway.
|
|
The separate class gives us a bit of extra encapsulation, but I don't
know that it's really worth the boilerplate. I think we can reasonably
expect the rest of the driver to be responsible.
|
|
These fields are the same value. In the bad old days, bo->handle could
have been an identifier from the pre-GEM fake bufmgr, but that's long
gone. Keep the "gem_handle" name for clarity.
|
|
The execbuf2 kernel API requires us to construct two kinds of lists.
First is a "validation list" (struct drm_i915_gem_exec_object2[])
containing each BO referenced by the batch. (The batch buffer itself
must be the last entry in this list.) Each validation list entry
contains a pointer to the second kind of list: a relocation list.
The relocation list contains information about pointers to BOs that
the kernel may need to patch up if it relocates objects within the VMA.
This is a very general mechanism, allowing every BO to contain pointers
to other BOs. libdrm_intel models this by giving each drm_intel_bo a
list of relocations to other BOs. Together, these form "reloc trees".
Processing relocations involves a depth-first-search of the relocation
trees, starting from the batch buffer. Care has to be taken not to
double-visit buffers. Creating the validation list has to be deferred
until the last minute, after all relocations are emitted, so we have the
full tree present. Calculating the amount of aperture space required to
pin those BOs also involves tree walking, which is expensive, so libdrm
has hacks to try and perform less expensive estimates.
For some reason, it also stored the validation list in the global
(per-screen) bufmgr structure, rather than as an local variable in the
execbuffer function, requiring locking for no good reason.
It also assumed that the batch would probably contain a relocation
every 2 DWords - which is absurdly high - and simply aborted if there
were more relocations than the max. This meant the first relocation
from a BO would allocate 180kB of data structures!
This is way too complicated for our needs. i965 only emits relocations
from the batchbuffer - all GPU commands and state such as SURFACE_STATE
live in the batch BO. No other buffer uses relocations. This means we
can have a single relocation list for the batchbuffer. We can add a BO
to the validation list (set) the first time we emit a relocation to it.
We can easily keep a running tally of the aperture space required for
that list by adding the BO size when we add it to the validation list.
This patch overhauls the relocation system to do exactly that. There
are many nice benefits:
- We have a flat relocation list instead of trees.
- We can produce the validation list up front.
- We can allocate smaller arrays and dynamically grow them.
- Aperture space checks are now (a + b <= c) instead of a tree walk.
- brw_batch_references() is a trivial validation list walk.
It should be straightforward to make it O(1) in the future.
- We don't need to bloat each drm_bacon_bo with 32B of reloc data.
- We don't need to lock in execbuffer, as the data structures are
context-local, and not per-screen.
- Significantly less code and a better match for what we're doing.
- The simpler system should make it easier to take advantage of
I915_EXEC_NO_RELOC in a future patch.
|
|
I'm about to rewrite how relocation handling works, at which point
drm_bacon_bo_emit_reloc() and drm_bacon_bo_mrb_exec() won't exist
anymore. This code is already largely not using the batchbuffer
infrastructure, so just go all the way and handle relocations, the
validation list, and execbuffer ourselves. That way, we don't have
to think the weird case where we only have a screen, and no context,
when redesigning the relocation handling.
|
|
This is the threshold after which drm_intel_bufmgr_check_aperture_space
returns -ENOSPC, signalling that it thinks an execbuf is likely to fail
and we need to roll back and flush the batch.
We'll need this when we rewrite aperture space checking, shortly.
In the meantime, we can also use it in GLX_MESA_query_renderer.
|
|
We'll want to change the implementation of this shortly.
|
|
I'm about to make brw_emit_reloc do actual work, so everybody needs
to start using it and not the raw drm_bacon function.
|
|
This renames intel_batchbuffer_reloc to brw_emit_reloc and changes the
parameter naming and ordering to match drm_intel_bo_emit_reloc().
For now, it's a trivial wrapper that accesses batch->bo. When we
rework relocations, it will start doing actual work.
|
|
This is only useful when doing an incoherent CPU mapping of the current
scanout buffer. That's a terrible plan, so we never do it. We always
use an uncached GTT map.
So, this is useless. Drop the code.
|
|
This functionality was added by libdrm commit
743af59669386cb6e063fa4bd85f0a0b2da86295 (intel: make bufmgr_gem
shareable from different API) in an attempt to solve libva/mesa buffer
sharing problems. Specifically, this was working around an issue hit
by Chromium, which used the same drm_fd for multiple APIs, and shared
buffers between them.
This code attempted to work around that issue by using the same bufmgr
for both libva and Mesa. It worked because libdrm_intel was loaded by
both libraries. However, now that Mesa has forked, we don't have a
common library, and this code cannot work.
The correct solution is to have each API open its own file descriptor
(and get a corresponding buffer manager), and then use PRIME export
and import to share BOs across those APIs. Then the kernel can manage
those shared resources. According to Chris, the kernel will pass back
the same handle for a prime FD if the lookup is from the same device FD.
We believe Chromium has since moved to this model.
In Mesa, there is already only one screen per FD, and so there will
only be one bufmgr per FD. We don't need any of this code.
|
|
This used to have another field, but now it's just a BO pointer.
|
|
No performance data has been gathered about this choice. I just don't
want that many hash tables.
|
|
It's always zero now.
|
|
Mesa doesn't use this yet. We'll almost certainly want to, but we can
add the functionality back after we clean up the messy drm code.
|
|
We may want this eventually, but simplify for now. We can add it back
later when we actually intend to use it.
|
|
We'll probably want this someday, but let's simplify now and add it back
when we actually intend to use it.
|
|
This is basically handholding to prevent a bogus caller from trying to
execbuffer on a bogus engine. i965 already does this correctly.
|
|
This moves the PCI ID detection to intel_screen.c and makes
drm_bacon_bufmgr_gem_init() take a devinfo pointer.
We also drop the HAS_LLC query stuff - devinfo has that info already,
without kernel queries, and it makes no sense to have two has_llc flags
set by different mechanisms.
|
|
This field was the wrong size, so we replaced it with offset64.
|
|
We require Kernel 3.6 and fail screen creation if this doesn't exist.
|
|
This query has been available since 2.6.28. We require 3.6.
|
|
|
|
This moves us one step closer to killing off intel_bufmgr_priv.h.
|
|
Legacy DRI1 leftovers.
|
|
libdrm_bacon used to have a GEM-based bufmgr and a legacy fake bufmgr,
but that's long since dead (and we never imported it to i965). So,
drop the extra layer of function pointers.
|
|
Eliminates some API around this, and more importantly, the last
field in one bufmgr class.
|
|
|
|
ROUND_UP_TO handles a NPOT alignment, but all the alignments we use
are power of two anyway, so there's no need.
|
|
execbuf2 has been around for years.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Based on a patch by Kristian Høgsberg.
|
|
Based on a patch by Kristian Høgsberg.
|
|
Both are kernel style lists, so this is trivial.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
|
