Age | Commit message (Collapse) | Author |
|
Luckily the kernel has become extremely paranoid about such matters.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Otherwise it's pretty hard to differentiate the different chipset
variants.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
... because argument is evaluated only if NDEBUG is not defined
|
|
Both drmIoctl and ioctl define second argument as unigned long.
Debugging/tracing tools (like strace or valgrind) on 64-bit machines see
different request value for ioctls with 32nd bit set, because casting
signed int to unsigned long extends 32nd bit to upper word, so 0x80000000
becomes 0xFFFFFFFF80000000)
Nobody noticed because higher 32 bits are chopped off on their way to kernel.
|
|
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It's going to call bo_get_subdata method, but not bo_subdata
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
|
|
|
|
Push the new Intel API for use by mesa.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
... so request a 32bpp dumb buffer rather than a 16bpp.
Fixes modetest and friends.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Hi Alex,
Enclosed is a revised version of the patch sent on Mar 18, against
the master branch of the drm userspace (i.e. libdrm). Details
summarised in this thread:
http://lists.freedesktop.org/archives/dri-devel/2011-March/009499.html
This patch reconciles libdrm with the the kernel change that Dave
pushed this morning. It *supersedes* the previously sent patch (i.e.
apply it to the master branch as it exists at the time of this writing,
not as an incremental patch to the one sent previously).
Regards,
Ilija
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Reported-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
A tile on gen2 has a size of 2kb, stride of 128 bytes and 16 rows.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Replace some deprecated autoconf macros and use the new libtool
syntax
|
|
|
|
this uses the drm cap interface to check if the dumb ioctl
is supported.
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
New kernel headers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This is Fail.
First patch to libdrm, and I've borked it up.
Noticed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The incorrect order was:
fb, other_fb, other_fb, fb_id, other_fb, ..
|
|
|
|
|
|
|
|
|
|
Todo: What tiling should be set on scanout buffers?
Haven't tested besides compiling it.
|
|
... and if asked to open a bo by the same global name, return a fresh
reference to the previously allocated buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33016
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The nvc0 gallium drivers passes NULL here to indicate to the memory manager
that a buffer is being used, but without creating an actual reloc.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
To export new kernel API for Intel's 2010Q4 release.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
gen4+ hardware doesn't use fences for GPU access and the older kernel
doesn't expect userspace to make such a mistake. So don't.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32190
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
this can remove nodes it shouldn't, let udev run the show.
this is needed for reliably GPU switch.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
... but only account for a fenced used if the object is tiled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
... so that intel_bufmgr.h can be compiled standalone.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For relaxed fencing the object may only consume the small set of active
pages, but still requires a fence region once bound into the aperture.
This is the size we need to use when computing the maximum possible
aperture space that could be used by a single batchbuffer and so avoid
hitting ENOSPC.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It makes sure that GPU object destruction is executed in order with
respect to the previous FIFO commands.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
|