| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Makes state emission into a 2 phase, prepare sets things up and accounts
the size of all referenced buffer objects. The emit stage then actually
does the batchbuffer touching for emitting the objects.
There is an assert in dri_emit_reloc if a reloc occurs for a buffer
that hasn't been accounted yet.
|
|
|
|
batchbuffer > aperture size.
So with compiz on Intel hw with fake bufmgr, opening 4 firefox windows at 1680x1050 and hitting alt-tab, could cause the batchbuffer to try and reference more than the 32MB of RAM allocated.
Fix 1:
Fix 1 is to pre-verify the list of buffers against the current batchbuffer and if it can't possibly fit in the aperture to flush the batchbuffer to the hardware
and try again. If the buffers still can't fit well then you are hosed as I'm not sure there is a nice way to tell anyone.
Fix 2:
Next problem was that even with a simple check for total < aperture, we ran
into fragmentation issues, this meant that half way down a set of buffers,
we would fail as no blocks were available. Fix this by nuking the memory
manager from orbit and letting it start again and relayout the blocks in a
manner that fits.
Fix 3:
Finally the initial problem we were seeing was a memcpy to a NULL backing store.
We seem to end up with a texture at some point that never gets mapped but ends up with data in it. compiz al-tab icons have this property. So I created a card dirty bit that memcpy's any buffer that is !static and is written to back to memory. This probably is wrong but it makes compiz work for now.
Caveats:
965 support is still fail.
|
|
|
|
|
|
|
|
|
|
|
|
We have two consumers of relocations. One is static state buffers, which
want the same relocation every time. The other is the batchbuffer, which gets
thrown out immediately after submit. This lets us reduce repeated computation
for static state buffers, and clean up the code by moving relocations nearer
to where the state buffer is computed.
|
|
|
|
Now that the dri_bufmgr is stored in the context rather than the screen, all
access to one is single-threaded anyway.
|
|
|
|
bufmgr_fake doesn't care about it, but with ttm we would end up with the
buffer remaining referenced until application exit.
|
|
|
|
This is currently believed to work but be a significant performance loss.
Performance recovery should be soon to follow.
The dri_bo_fake_disable_backing_store() call was added to allow backing store
disable like bufmgr_fake.c did, which is a significant performance win (though
it's missing the no-fence-subdata part).
This commit is a squash merge of the 965-ttm branch, which had some history
I wanted to avoid pulling due to noisiness and brokenness at many points
for git-bisecting.
|
|
|
|
The uint64_t flags (as defined by drm.h) were being used as unsigned ints in
many places.
|
|
|
|
|
|
This is required for 965 performance, as it avoids a lot of repeated data
uploads of the state caches due to surface offsets in them.
|
|
They shouldn't be created, and this often helps catch stupid issues.
|
|
This is required for 965 support, which has relocations in other places than
just the batchbuffer.
|
|
remove unneeded entry points
|
|
gears now runs for about 10-15 seconds with some artifacts before falling
over.
|
|
|
|
This moves the relocations into the buffer manager in prepration for
a superioctl move.
|
|
|
|
|
|
|
|
git+ssh://people.freedesktop.org/~anholt/mesa into i915-unification
|
|
|
|
|
|
Now, allocations only take locations, rather than a variety of unused flags.
The only interesting flag before was the no_move/no_evict pair for scanout
and similar buffers, which the DRI drivers don't use. That will be readded
when we get to using this code for display buffer allocation, by adding a
pin/unpin call (dynamic pinning/unpinning may be useful for VT switching and
root window resizing).
This commit changes one instance of DRM_BO_FLAG_MEM_LOCAL with
DRM_BO_FLAG_MEM_TT, which appeared to have been unintentional.
|
|
|
|
|
|
|
|
|
|
|
|
The interface is not solid yet (some simplification to do still, and
adjustment for 0-copy), and the drivers are not converted. However, the new
interface allows using the same calls to support either a TTM or a classic
static allocation backend, with the static backend allowing a more limited
feature set.
|
