| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
This is just cosmetic, to produce less scary values when the ioctl fails and
doesn't return values there.
|
|
|
|
(And fix a nearby whitespace nit)
|
|
|
|
|
|
|
|
Fencing was used in two places: ensuring that we didn't get too many frames
ahead of ourselves, and glFinish. glFinish will be satisfied by waiting on
buffers like we would do for CPU access on them. The "don't get too far ahead"
is now the responsibility of the execution manager (kernel).
|
|
|
|
|
|
|
|
|
|
The previous default these days served mostly to cause artifical problems with
GLX compositing managers like compiz (see e.g.
http://bugs.freedesktop.org/show_bug.cgi?id=10501).
|
|
buffer.
|
|
|
|
#15574
|
|
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.
|
|
Add DRI2 direct rendering support to libGL and add DRI2 client side
protocol code. Extend the GLX 1.3 create drawable functions in
glx_pbuffer.c to call into the DRI driver when possible.
Introduce __DRIconfig, opaque struct that represents a DRI driver
configuration. Get's rid of the open coded __GLcontextModes in the
DRI driver interface and the context modes create and destroy
functions that the loader was requires to provide. glcore.h is no
longer part of the DRI driver interface. The DRI config is GL binding
agnostic, that is, not specific to GLX, EGL or other bindings.
The core API is now also an extension, and the driver exports a list
of extensions as the symbol __driDriverExtensions, which the loader
must dlsym() for. The list of extension will always include the DRI
core extension, which allows creating and manipulating DRI screens,
drawables and contexts. The DRI legacy extension, when available,
provides alternative entry points for creating the DRI objects that
work with the XF86DRI infrastructure.
Change DRI2 client code to not use drm drawables or contexts. We
never used drm_drawable_t's and the only use for drm_context_t was as
a unique identifier when taking the lock. We now just allocate a
unique lock ID out of the DRILock sarea block. Once we get rid of the
lock entirely, we can drop this hack.
Change the interface between dri_util.c and the drivers, so that the
drivers now export the DriverAPI struct as driDriverAPI instead of the
InitScreen entry point. This lets us avoid dlsym()'ing for the DRI2
init screen function to see if DRI2 is supported by the driver.
|
|
Failure to consistently do so resulted in mismatched aligned versus
unaligned alloc/free.
|
|
965 after merging intel_context.c from i915 and i965. fix bug# 15152.
|
|
It was harmless, as the only time we need to clear PRESUMED_OFFSET, the
variable had been initialized already.
|
|
|
|
|
