| Age | Commit message (Collapse) | Author |
|---|
|
libdrm_intel needs symbols from libdrm, so link against it.
(cherry picked from commit d9c2f65dd8e50736a33e97a55c257ef6843e1ce7)
Conflicts:
libdrm/Makefile.am
|
|
We want to be able to use the bufmgr from multiple threads for GL, and thus
we need to protect the internal structures.
The pthread-stubs package is used so that programs not linked against
pthreads get weak symbols to stubs and don't eat most of the cost.
|
|
We need a way of getting at the underlying handle for use with mode
setting. We can either export it in the dri_bo object or provide a new
callback to get it.
|
|
Conflicts:
libdrm/Makefile.am
libdrm/dri_bufmgr.h
linux-core/drm_irq.c
linux-core/drm_sysfs.c
linux-core/drm_ttm.c
shared-core/i915_dma.c
shared-core/i915_irq.c
shared-core/nouveau_drv.h
shared-core/radeon_cp.c
|
|
The gltestperf demo in some cases took over seven seconds to make it through
one batchbuffer on a GM965.
Bug #17004.
|
|
I'd swapped the operands, so if we weren't in lockstep with the hardware we
said the sequence was always passed. Additionally, a race was available that
we might have failed at recovering from. Instead, I've replaced the logic
with new stuff that should be more robust and not rely on all the parties in
userland following the same IRQ_EMIT() == 1 protocol. Also, in a radical
departure from past efforts, include a long comment describing the failure
modes and how we're working around them.
Thanks to haihao for catching the original issue.
|
|
|
|
|
|
Thanks to airlied for catching this.
|
|
This avoids duplicating the effort in 3 places. Also, added emit/wait fence
callbacks back in bufmgr_fake since we need it for non-drm 2d. Sigh.
|
|
In the process, work around the glaring bugs of the kernel irq wait function.
|
|
dri_bufmgr.h is replaced by intel_bufmgr.h, and several functions are renamed,
though the structures and many functions remain dri_bufmgr_* and dri_bo_*
|
|
|
|
Conflicts:
libdrm/xf86drm.c
linux-core/Makefile.kernel
linux-core/drmP.h
linux-core/drm_compat.h
linux-core/drm_drv.c
linux-core/drm_stub.c
linux-core/drm_vm.c
shared-core/i915_dma.c
shared-core/r300_cmdbuf.c
shared-core/radeon_drv.h
|
|
Conflicts:
libdrm/Makefile.am
libdrm/xf86drm.h
shared-core/i915_dma.c
shared-core/i915_irq.c
|
|
Store the global name in global_name, don't overwrite the gem_handle.
|
|
We'll need something like this (either a handle field or a dri_bo_get_handle
function) for kernel mode setting to get at the handles.
|
|
|
|
|
|
|
|
While the bufmgr isn't thread-safe at the moment, we need it to be for shared
objects between contexts.
|
|
another name
|
|
|
|
|
|
I915_GEM_DOMAIN_CPU is very expensive to wait for -- it generally requires
clflushing the frame buffer.
|
|
When a software fallback has completed, usermode must notify the kernel so
that any scanout buffers can be synchronized. This ioctl should be called
whenever a fallback completes to flush CPU and chipset caches.
|
|
Thanks to Thomas Hellstrom for catching the issue, no thanks to the kernel
developer who authoritatively told me that they would get restarted on their
own.
|
|
This reduces the diff from Mesa and reduces the illegibility of what I did.
|
|
This is the create (may want location flags), pread/pwrite/mmap
(performance tuning hints), and set_domain (will 32 bits be enough for
everyone?) ioctls. Left in the generic set are just flink/open/close.
The 2D driver must be updated for this change, and API but not ABI is broken
for 3D. The driver version is bumped to mark this.
|
|
|
|
Place the buffer reuse links right into the dri_bo_gem object.
|
|
|
|
The code was discarding the dri_bo_gem structure and saving only the kernel
handle. This lost the mmap address, causing pain when the next buffer user
wanted to map the buffer.
|
|
This will be used by the X Server for VT switch.
|
|
|
|
|
