- The bo was mapped with sysmem == NULL, so this means cpu prep is called.
- The bo was unmapped with sysmem != NULL, so this means cpu finish is not called.
- This can lead to a non-zero "cpu writers" count in ttm_bo.
The goal of the BO cache is to keep buffers on hand for fast continuous use,
as in every frame of a game or every batchbuffer of the X Server. Keeping
older buffers on hand not only doesn't serve this purpose, it may hurt
performance by resulting in disk cache getting kicked out, or even driving
the system to swap.
Bug #20766.
Several POSIX extensions are used in the libdrm code (e.g., mknod and ffs).
Set _XOPEN_SOURCE and _GNU_SOURCE to something reasonable to ensure that
prototypes for these functions are available. This is done in configure.ac
using AC_USE_SYSTEM_MACROS. This requires autoconf 2.60 or later. Eventually
the code should check for the existance of these defines and do something
reasonable if they are not available.
Inspired by a patch by Pauli Nieminen and suggestions from Julien Cristau.
Thanks.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
The logbase2 would overflow and wrap the size around to 0, making the code
allocate a 4kb object instead. By simplifying the code to just walk the
14-entry bucket array comparing sizes instead of indexing on
ffs(1 << logbase2(size)), we avoid silly math errors and have code of
approximately the same speed.
Many thanks to Simon Farnsworth for debugging and providing a working patch.
Bug #27365.
Normal map() should operate as before, and map_range()/map_flush() should
give correct results but lacking any performance difference from map().
Nothing exiting being done here yet, but the interface is a good start.
The commit 651e3dc6dd, "drm: Fix
compilation on 2.6.30" broke all builds on kernels before 2.6.26.
Variadic functions cannot be inlined.
The variadic inline function is replaced with a variadic macro.
Also, the function dev_name() added by that same commit is never used,
so it is removed.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
No idea what this reg does.. NVIDIA put 0x802 into it on some chips, the
criteria aren't too clear on when they do that however. Hopefully 0x800
will work everywhere...
Patch allows the backlight to be manipulated under gnome on apple powerpc
based NV30 machines. It works fine on my powerbook, and should also work
for older NV17/NV18 machines.
Note that older powerpc specific tools (pbbuttonsd) have some problems with
this implementation (because the device is not yet there at the start time
of the daemon, and the code makes incorrect assumptions about the max
brightness values). However, IMHO these things can and should be addressed
in the daemon.
Some style/warning fixes applied by Stuart Bennett <stuart@freedesktop.org>
This avoids making objects significantly bigger than they would be
otherwise, which would result in some failing at binding to the GTT.
Found from firefox hanging on:
http://upload.wikimedia.org/wikipedia/commons/b/b7/Singapore_port_panorama.jpg
due to a software fallback trying to do a GTT-mapped copy between two 73MB
BOs that were instead each 128MB, and failing because both couldn't fit
simultaneously.
The cost here is that we get no opportunity to cache these objects and
avoid the mapping. But since the objects are a significant percentage
of the aperture size, each mapped access is likely having to fault and rebind
the object most of the time anyway.
Bug #20152 (2/3)
The convention is that all APIs are per-bufmgr, so make this one the same.
Then, have it return -1 on failure so that the application can know what's
going on and do something sensible.
Signed-off-by: Keith Packard <keithp@keithp.com>
This wraps the new DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID ioctl,
allowing applications to discover the pipe number corresponding
to a given CRTC ID. This is necessary for doing pipe-specific
operations such as waiting for vblank on a given CRTC.
Scanout buffers need to be freed through the kernel as it holds a reference
to them; exposing this API allows applications allocating scanout buffers to
flag them as not reusable.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Add assertions to drm_intel_gem_bo_reference,
drm_intel_gem_bo_reference_locked and drm_intel_gem_bo_unreference_locked
that the object has not been freed (refcount > 0). Mistakes in refcounting
lead to attempts to insert a bo into a free list more than once which causes
application failure as empty free lists are dereferenced as buffer objects.
Signed-off-by: Keith Packard <keithp@keithp.com>