- Dec 10, 2010
-
-
Chris Wilson authored
To export new kernel API for Intel's 2010Q4 release. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Dec 07, 2010
-
-
Chris Wilson authored
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>
-
Dave Airlie authored
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>
-
- Dec 03, 2010
-
-
Chris Wilson authored
... but only account for a fenced used if the object is tiled. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Dec 02, 2010
-
-
Marek Olšák authored
-
- Nov 25, 2010
-
-
Chris Wilson authored
... so that intel_bufmgr.h can be compiled standalone. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Nov 22, 2010
-
-
Chris Wilson authored
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>
-
Francisco Jerez authored
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>
-
- Nov 09, 2010
-
-
Emma Anholt authored
Both the consumers of this API (sync objects and client throttling) were expecting this behavior. The kernel used to actually behave the desired (but incorrect) way for us anyway, but that got fixed a while back.
-
- Nov 07, 2010
-
-
If bufmgr.bo_mrb_exec is not set, drm_intel_bo_mrb_exec returns ENODEV even though drm_intel_gem_bo_mrb_exec2 will work fine for the RENDER ring. Fixes xf86-video-intel after commit 'add BLT ring support' (5bed685f76) with kernels without BSD or BLT ring support (2.6.34 and before). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31443 Signed-off-by: Albert Damen <albrt@gmx.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Nov 02, 2010
-
-
Emma Anholt authored
The intent of these was to catch mismatched map/unmap. What it actually did was check whether there was ever a mapping of that type (including in a previous life of the buffer through the userland BO cache), not whether they were mismatched. We don't even actually want to catch mismatched map/unmap, unless we also do refcounting, since at one point Mesa would do map/map/use/unmap/unmap. Just remove this code instead.
-
Emma Anholt authored
This couldn't be triggered except by overflow, since there's an assert in unreference to catch the usual failure of over-unreferencing.
-
- Nov 01, 2010
-
-
Emma Anholt authored
-
Emma Anholt authored
-
- Oct 31, 2010
-
-
Francisco Jerez authored
nouveau_bo_unmap called the CPU_FINI IOCTL even if it was a NOSYNC mapping. It caused no harmful effects (actually CPU_FINI is a no-op on recent enough kernels) besides the precious CPU cycles being wasted. Signed-off-by: Francisco Jerez <currojerez@riseup.net>
-
- Oct 29, 2010
-
-
Chris Wilson authored
The kernel has always allowed userspace to underallocate objects supplied for fencing. However, the kernel only allocated the object size for the fence in the GTT and so caused tiling corruption. More recently the kernel does allocate the full fence region in the GTT for an under-sized object and so advertises that clients may finally make use of this feature. The biggest benefit is for texture-heavy GL games on i945 such as World of Padman which go from needing over 1GiB of RAM to play to fitting in the GTT! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Oct 27, 2010
-
-
Adam Jackson authored
_DRM_MALLOC hasn't been a relevant concern since we split libdrm out from xserver. Signed-off-by: Adam Jackson <ajax@redhat.com>
-
- Oct 26, 2010
-
-
Chris Wilson authored
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Oct 21, 2010
-
-
Francisco Jerez authored
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
-
- Oct 12, 2010
-
-
Francisco Jerez authored
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Acked-by: Ben Skeggs <bskeggs@redhat.com>
-
Francisco Jerez authored
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Acked-by: Ben Skeggs <bskeggs@redhat.com>
-
- Oct 01, 2010
-
-
Chris Wilson authored
As the higher layers check the error return from libdrm-intel and are supposed to handle the error (and print their own warning in extremis) the voluminous output on stderr is just noise and a hazard in its own right. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Sep 29, 2010
-
-
Carl Worth authored
For the upcoming 2.4.22 release.
-
- Sep 25, 2010
-
-
Chris Wilson authored
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Sep 21, 2010
-
-
Ben Skeggs authored
... and make a mental note to not push commits before having coffee Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
- Sep 19, 2010
-
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
- Sep 09, 2010
-
-
Chris Wilson authored
-
Jesse Barnes authored
Docs say this is necessary, and the kernel now enforces this.
-
- Sep 07, 2010
-
-
Jesse Barnes authored
-
- Aug 26, 2010
-
-
Emma Anholt authored
Avoids requiring nasty hacks around libdrm headers in the new C++ parts of Mesa drivers.
-
- Aug 24, 2010
-
-
Chris Wilson authored
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Aug 18, 2010
-
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
- Aug 06, 2010
-
-
This works in conjunction with newer kernels. If we succeed in requesting interface 1.4, the we know the kernel provides proper domain numbers. If not, ignore the domain number as it's bogus (except on Alpha). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Adam Jackson <ajax@redhat.com>
-
- Aug 03, 2010
-
-
Dave Airlie authored
-
- Jul 01, 2010
-
-
Chris Wilson authored
The high layers expect to receive a status code on error (on the pessimistic assumption that the errno value will have been overwritten by the time the failure is propagated all the way up), so convert xf86drmMode.c to return -errno on an ioctl error and be consistent with the rest of the libdrm API. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Signed-off-by: Fernando Carrijo <fcarrijo@yahoo.com.br> Signed-off-by: Brian Paul <brianp@vmware.com>
-
- Jun 29, 2010
-
-
Chris Wilson authored
If the mapping succeeds we have a valid pointer. If setting the domain failures we may incur cache corruption. However the usual failure mode is because of a hung GPU, in which case it is preferable to ignore the minor error from setting the domain and continue on oblivious. If these errors persist, we should rate limit the warning [or even just remove it]. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Jun 24, 2010
-
-
Chris Wilson authored
Fixes: Bug 28515 - Failed to allocate framebuffer when exceed 2048 width https://bugs.freedesktop.org/show_bug.cgi?id=28515 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Jun 22, 2010
-
-
Chris Wilson authored
Mesa uses the returned pitch from alloc_tiled, so make sure that we set it correctly before modifying the stride used for the SET_TILING call. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-