| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
shared-core/i915_dma.c
This brings in kernel support and userland interface for intel GEM.
|
|
While the bufmgr isn't thread-safe at the moment, we need it to be for shared
objects between contexts.
|
|
the nvidia driver does this, and it stops the error message appearing on nv40
|
|
another name
|
|
|
|
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.
|
|
|
|
This reverts commit 965a72202b439068e62ac341990f51953457b202.
Please re-do over properly
|
|
|
|
|
|
|
|
This reverts commit 3ad8db2071d30c198403e605f2726fc5c3e46bfd.
We ended up not needing that namespace, and I'd rather not have the churn
for producing diffs.
|
|
|
|
|
|
|
|
|
|
This makes our handling of cliprects sane. drm_clip_rect always has exclusive
bottom-right corners, but the hardware expects inclusive bottom-right corners,
so we adjust this here.
This complements Michel Daenzer's commit 57aea290e1e0a26d1e74df6cff777eb9f038f1f8
to Mesa. See also http://bugs.freedesktop.org/show_bug.cgi?id=16123 .
|
|
|
|
|
|
Conflicts:
linux-core/Makefile.kernel
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
clearly the function had never been used :)
|
|
|
|
|
|
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.
|
|
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=16799 .
|
|
DRAW_INDEX writes a vertex count to VAP_VF_CNTL. Docs say that behaviour
is undefined (i.e. lockups happen) when this write is not followed by the
right number of vertex indices.
Thus we used to do the wrong thing when drawing across many cliprects was
necessary, because we emitted a sequence
DRAW_INDEX, DRAW_INDEX, INDX_BUFFER, INDX_BUFFER
instead of
DRAW_INDEX, INDX_BUFFER, DRAW_INDEX, INDX_BUFFER
The latter is what we're doing now and which ought to be correct.
|
|
|
|
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 resolves a panic on FreeBSD which was caused by trying
to re-initialize the swap lock. It's just much easier to
initialize all of the locks at load time. It should also
ensure that the vblank structures are available earlier.
|
|
Fixes an oops in fbotexture from walking off the end of the page list.
|
|
This increases overhead for the large-readpixels case due to the repeated
page cache accessing, but greatly reduces overhead for the small-readpixels
case.
|
|
These will be covered by the fence, while pread/pwrite are supposed to be
CPU-perspective writes, with manual detiling done by the client.
|
|
|
|
|
|
|
|
Thanks to airlied.
|
|
This is in pci.h in the fixed patch to the kernel.
|
|
This requires an updated 2D driver to not try to set it up as well.
|
|
Thanks to Nicolai Haehnle for pointing this out on IRC.
|
|
I incorrectly thought it was obsolete.
|
|
The driver code that caused this is no longer necessary and has been dropped.
|
|
Thanks to the reworked vblank-rework, we can just use the hardware frame
counter directly, and make the RADEON_PARAM_VBLANK_CRTC getparam just return
what was set by the corresponding setparam.
|
|
Remove some dead/obsolete code and make drm_update_vblank_count() static.
|
|
Caused drm_update_vblank_count() not to do its thing when called from
drm_modeset_ctl() -> drm_vblank_get().
The vblank functionality no longer needs to be suspended during a modeset, so
rename the field to vblank_inmodeset.
|
|
All interrupt off vblank count updates are done in drm_vblank_get/put
now, so convert users of the vblank counter over to that interface.
|
|
In my last push I forgot to convert users of drm_update_vblank_count
over to drm_vblank_get/put, since that's where any interrupt off->on
update accounting is done now. Since the modeset ioctl did something
similar (an open coded update of the counter) convert it over to using
get/put too, which saves us from having to deal with every combination
of interrupt off & on between calls.
|
