| 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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
into modesetting-gem
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
While the bufmgr isn't thread-safe at the moment, we need it to be for shared
objects between contexts.
|
|
another name
|
|
|
|
|
|
|
|
|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
linux-core/drm_stub.c
linux-core/i915_drv.c
linux-core/i915_gem.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
+ modeprint changes.
- All things are now called _id when they are id's.
- modeprint now accepts driver name as first argument.
|
|
not needed, hotplug will work just as well hopefully.
|
|
|
|
|
|
- I do not fully understand these blobs, so i'm leaving it at this for the moment.
|
|
I915_GEM_DOMAIN_CPU is very expensive to wait for -- it generally requires
clflushing the frame buffer.
|
|
|
