| Age | Commit message (Collapse) | Author |
|---|
|
Since the TTM type isn't upstream yet, we need to make sure libdrm uses
what the kernel uses, which is _DRM_GEM = 6.
|
|
|
|
Add a drm_intel_gem_bo_map_gtt() function for mapping a buffer object
through the aperture rather than directly to its CPU cacheable memory.
|
|
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.
|
|
This turns the various nvXX_graph_init_ctxvals() methods into tables,
and speeds up compliation of nv50_graph.c quite a bit. This has bothered
me for a while, but others are complaining now so it's time to fix it :)
|
|
This allows us to not crash X when using newer Intel ddx drivers.
|
|
- logic was wrong. rs400/rs480 should clear the RADEON_BUS_MASTER_DIS bit
- should fix kernel bug 11798
|
|
rs400 is just like rs480. I mixed up the internal
chipset names for rs600 and rs400.
|
|
Olaf Kirch noticed that the i915_set_status_page() function of the i915
kernel driver calls ioremap with an address offset that is supplied by
userspace via ioctl. The function zeroes the mapped memory via memset
and tells the hardware about the address. Turns out that access to that
ioctl is not restricted to root so users could probably exploit that to
do nasty things. We haven't tried to write actual exploit code though.
It only affects the Intel G33 series and newer.
|
|
|
|
|
|
That's what I get for committing at 3 AM.
|
|
|
|
|
|
See bug 17908
|
|
|
|
This just doesn't look right..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While re-writing this for modesetting, I find we disable writeback on
resume.
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
ifdef out all the gem stuff for now. Also, the msi stuff isn't portable
the way it is... I'll try and fix that up sometime soon.
|
|
|
|
sarea_priv needs to be NULL before i915_initialized is called to
properly reset it. The stale value produces a panic any time something
opens/closes drm without calling initialize. i.e. version checking
|
|
|
|
This resolves the panic on FreeBSD during VT switch, without attempting
any of the more lofty goals for the time being.
|
|
Corresponding DDX patch at http://people.freedesktop.org/~stuart/nv0x-nv4x_suspend/
|
|
|
|
Conflicts:
shared-core/i915_dma.c
This brings in kernel support and userland interface for intel GEM.
|
|
the nvidia driver does this, and it stops the error message appearing on nv40
|
|
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 :)
|
|
|
|
|
|
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.
|
|
|
|
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 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.
|
