| Age | Commit message (Collapse) | Author |
|---|
|
Relocation now consist of the following informations (in this order) :
handle buffer object handle identifier
start_offset start offset of first data of the buffer object used by the cs
end_offset end offset of last data of the buffer object used by the cs
read_domain read domain (either VRAM, or GTT as GPU is invalid for CS)
write_domain write domain (either VRAM, or GTT as GPU is invalid for CS)
flags flags used for further optimization (like discard previous
buffer content or forget buffer content after cs which can
help in avoiding moving content in or out)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I wanted to avoid doing this, as it's a bunch of churn, but there was a
conflict between the dri_ symbols in libdrm and the symbols that were in
Mesa in 7.2, which broke Mesa 7.2 AIGLX when the 2D driver had loaded new
libdrm symbols. The new naming was recommended by cworth for giving the
code a unique prefix identifying where the code lives.
Additionally, take the opportunity to fix up two API mistakes: emit_reloc's
arguments were in a nonsensical order, and set_tiling lacked the stride
argument that the kernel will want to use soon. API compatibility with
released code is maintained using #defines.
|
|
|
|
This relies on a new kernel ioctl to get the available aperture size.
In order to provide reasonable performance from dri_bufmgr_check_aperture, we
now require that once a buffer has been used as the target of a relocation,
it gets no further relocations added to it. This cuts the cost of
check_aperture from 10% to 1% in the 3D driver with no code changes, but
slightly complicates our plans for the 2D driver.
|
|
|
|
into modesetting-gem
|
|
|
|
|
|
|
|
Don't count on ioctl returning -errno; use errno directly.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
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.
|
|
|
|
|
|
|
|
libdrm_intel needs symbols from libdrm, so link against it.
|
|
Bug #18035. Fixes deadlock in glean texCube testcase.
|
|
|
|
When using bufmgr_fake without DRM, the X server idles the ring whenever it
wants to wait for something to complete (brutal, but effective). In this
case, bufmgr_fake must treat the pending fence as having passed. However, it
wasn't recording the fences as it emitted them, nor cleaning buffers as they
passed.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
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.
|
|
http://bugs.freedesktop.org/show_bug.cgi?id=17705
|
|
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
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=17705
|
|
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.
|
|
|
|
|
|
Reported by jcristau.
|
|
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_*
|
|
|
|
This patch allows you to --enable-udev, and will avoid having libdrm
make device nodes. If you are using udev, you should really --enable-udev
your libdrm.
|
|
This resolves and issue on amd64 FreeBSD and it looks like the
linux ioctl syscall should be unsigned long as well.
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
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.
|
|
|
|
|
|
|
