| Age | Commit message (Collapse) | Author |
|---|
|
Needed to merge in VM fault changes & pci_read_base API update.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When i915_gem_retire_request has a flush which matches an object write
domain, clear the write domain. This will move the object to the inactive
list rather than the flushing list, avoiding trouble with objects left stuck
on the flushing list.
|
|
In i915_gem_object_wait_rendering, if the object write domain is being
written by the GPU, the appropriate flushing commands are written to the
device and an additional request queued to mark that flush. Finally, the
function blocks on that new request.
The bug was that the write_domain in the object was cleared before the
function blocked.
If the wait is interrupted by a signal, the flushing commands may still be
pending. With the current write_domain information lost, the restarted
syscall will drop right through the write_domain test as that value was
lost, and so the function will not block at all. Oops.
Fixed by simply moving the write_domain clear until after the wait_request
succeeds. Note that the restarted system call will generate an additional
flush sequence and request, but that should be 'harmless', aside from a
slight performance impact.
Someday we'll track flushing more accurately and clear write_domains more
efficiently, but for now, this should suffice.
This bug was discovered in the 2d gem development by running x11perf
-copypixwin500 and noticing that the window got cleared accidentally.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
linux-core/Makefile.kernel
linux-core/drmP.h
linux-core/drm_mm.c
linux-core/drm_stub.c
linux-core/i915_gem.c
linux-core/i915_opregion.c
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
Conflicts:
linux-core/Makefile.kernel
linux-core/ati_pcigart.c
linux-core/drm_compat.h
linux-core/drm_irq.c
linux-core/drm_lock.c
linux-core/i915_drv.c
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/nouveau_mem.c
shared-core/radeon_cp.c
shared-core/radeon_drv.h
|
|
|
|
|
|
|
|
(cherry picked from commit 10d5b037b85706037df89bf0275436797e4eb559)
|
|
This removes all the TTM userspace API and all userspace objects.
It also removes the drm_bo_lock.c code
|
|
|
|
|
|
This reverts commit 3ad8db2071d30c198403e605f2726fc5c3e46bfd.
We ended up not needing that namespace, and I'd rather not have the churn
for producing diffs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
linux-core/Makefile.kernel
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
Main fix is an oops that was triggered by the gtt pwrite path when we don't
have the gtt initialized. Also, settle on -EBADF for "bad object handle",
and -EINVAL for "reading/writing beyond object boundary".
|
|
This is around 3x or so speedup, since we would read wide rows at a time, and
clflush each tile 8 times as a result. We'll want code related to this anyway
when we do fault-based per-page clflushing for sw fallbacks.
|
|
this at least parses the DDX stream and lets me run gnome-terminal/metacity
|
|
take code from Jerome munge into a TTM IB re-use
|
|
|
|
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=16799 .
|
|
This is an initial import of the atom bios parser with modesetting support
for r500 hw using atombios. It also includes a simple memory manager
layer that translates a radeon GEM style interface onto TTM internally.
So far this memory manager has only been used for pinned object allocation
for the DDX to test modesetting.
|
|
|
|
this lets us debug the X server through xkb startup.
Not sure what the correct answer is, probably X needs to drop
the lock when execing stuff, with input hotplug it can get
xkb stuff at any time I believe.
|
|
|
|
|
|
|
|
|
|
this lets us debug the X server through xkb startup.
Not sure what the correct answer is, probably X needs to drop
the lock when execing stuff, with input hotplug it can get
xkb stuff at any time I believe.
|
