| Age | Commit message (Collapse) | Author |
|---|
|
Most of these were to ensure that caches got synchronized between 2d (or meta)
rendering and later use of the target as a source, such as for texture
miptree setup. Those are replaced with intel_batchbuffer_emit_mi_flush(),
which just drops an MI_FLUSH. Most of the remainder were to ensure that
REFERENCES_CLIPRECTS batchbuffers got flushed before the lock was dropped.
Those are now replaced by automatically flushing those when dropping the lock.
|
|
|
|
Nothing would get drawn as the negative coordinates broke the rectangle
intersection code that used unsigned ints. Tested with copypix demo and
sliding the copy to the upper left.
|
|
This disables the textured copy implementation on 965, which didn't appear
to work (mesa copypix demo, disable the blit path, move so that regions don't
overlap and textured is used, and you get garbage). If we resurrect this for
i965, I'd rather it used the 915-style metaops instead. Current metaops code
left in place so that whoever picks it up has a reference.
|
|
|
|
Mesa demos tend to leave blending on but in GL_ONE/GL_ZERO, or
GL_SRC_ALPHA/GL_ONE_MINUS_SRC_ALPHA with a source alpha of 1.0.
|
|
Both had some useful bits for the other.
|
|
|
|
|
|
Taken from commit bad6e175cf59cce630c37d73f6e71f3a4de50ae6.
|
|
This matches 965.
|
|
This lets GEM use pwrite, for an additional 4% or so speedup.
|
|
|
|
|
|
|
|
The fencing code is not required, and waiting on the fences defeated one of
the purposes of the extension, which is to allow asynchronous readpixels.
|
|
|
|
Refactoring of mine in 02d5ba849197e19843dad164239b51f18fb16faf broke it
by failing to understand that the masking was about sign extension.
|
|
|
|
The no_rast fallback was getting partially overwritten by later TNL init,
resulting in a segfault when things were in a mixed-up state.
|
|
Apparently a bit gets flipped in the addressing for some rows of each tile.
|
|
|
|
This is an API breakage only.
|
|
The objects are swappable, so we're less concerned by excessive object
allocation now, and it's about a 20% performance improvement. If we get
concerns about the memory consumption from others, we can look into a
compromise position later.
|
|
Swap buffers is a fairly reasonable time to wait for the hardware for a
while; this keeps us from overrunning the ring.
|
|
Conflicts:
src/mesa/drivers/dri/common/dri_bufmgr.h
src/mesa/drivers/dri/intel/intel_bufmgr_ttm.c
src/mesa/drivers/dri/intel/intel_bufmgr_ttm.h
src/mesa/drivers/dri/intel/intel_ioctl.c
|
|
I'll release a libdrm 2.3.1 without TTM apis included from a special
drm branch that should allow mesa 7.1 to build against it.
I've had to turn off DRI2 stuff.
|
|
|
|
This is good for about 5% on ipers on 965, and should help any cpu-bound app.
|
|
Mapping and unmapping buffers is expensive, and having the map around isn't
harmful (other than consuming address space). So, once mapped, just leave
buffers mapped in case they get re-used.
|
|
Add both MI_FLUSH and intel_batchbuffer_flush to intelEmitCopyBlit.
This ensures that the data are flushed *and* the gem kernel driver sees the
various memory domain transitions.
|
|
Use the new DRM_IOCTL_I915_GEM_BUSY ioctl to detect
idle buffers for re-use.
|
|
We don't need an MI_FLUSH there, because everything that's been flushed in the
batch will eventually hit the hardware.
|
|
Otherwise, since the MI_FLUSH at the end of every batch had been removed,
non-automatic-flushing chips (965) wouldn't get flushed and apps with static
rendering would get partial screen contents until the server's blockhandler
flush kicked in.
|
|
The right solution would probably be keeping a list of regions which have been
rendered to.
|
|
The write_domain needs to be set after any batch buffer uses an object,
track when that happens in the new 'cpu_domain_set' field.
|
|
Only a few relocations are typically used, so don't clear the
whole thing.
|
|
This avoids kernel relocations for most batchbuffer relocs.
|
|
Track DRM GEM name changes.
Add driver hooks for bo_subdata and bo_get_subdata so that GEM can use pread
and pwrite.
|
|
|
|
|
|
function."
This reverts commit c50ffc4cb89b67ae59208eb72cdb664c846ba987.
I'll fix this using the mipmap hooks I just picked from gallium-0.1
|
|
This at least stops the compiz brain explosion we were seeing, I do wonder
though if we should somehow be calling intel_generate_mipmap somehow.
|
|
Fix the kernel API to place the read/write domain information in the
relocation instead of the buffer.
|
|
Make sure 'used' tracks the right value through the whole function.
Also, use GLint for intel_batchbuffer_space in case we do bad things
in the future.
|
|
The GEM flags are much more descriptive for what we need. Since this makes
bufmgr_fake rather device-specific, move it to the intel common directory.
We've wanted to do device-specific stuff to it before.
|
|
|
|
Doesn't deal with local modifications yet (need new kernel set_domain ioctl
for that to work). Also, guesses what domains are affected based on the
read/write bits set in the flags. Works for 915, probably not so much for
965.
|
|
Accessing tiled surfaces without using the fence registers requires that
software deal with the address swizzling itself.
|
|
|
