| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
small integers are much prettier, and let me correlate to DRM debug output.
|
