| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This reverts commit cd5c66c659168cbe2e3229ebf8be79f764ed0ee1. It broke too
many kernel assumptions about the double ioctl (connector status, mode
fetching, etc.)
|
|
This patch speeds up drmModeGetConnector by pre-allocating mode &
property info space before calling into the kernel. In many cases this
pre-allocation will be sufficient to hold the returned values (it's easy
enough to tweak if the common case becomes larger), which means we don't
have to make the second call, which saves a lot of time.
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
libdrm has some support for GTT mapping already, but there are bugs
with it (no surprise since it hasn't been used much).
In fixing 20803, I found that sharing bo_gem->virtual was a bad idea,
since a previously mapped object might not end up getting GTT mapped,
leading to corruption. So this patch splits the fields according to
use, taking care to unmap both at free time (but preserving the map
caching).
There's still a risk we might run out of mappings (there's a sysctl
tunable for max number of mappings per process, defaulted to 64k or so
it looks like) but at least GTT maps will work with these changes (and
some others for fixing PAT breakage in the kernel).
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
|
|
|
|
|
|
|
|
- This was causing a significant memory leak.
|
|
bo_handle_ref on !mm_enabled treats handle as an offset, make
bo_handle_get do the same rather than failing.
|
|
drm_handle_t is defined to be a u32 on linux and a u64 on everything
else. This addresses an issue on FreeBSD amd64 where the map offsets
may be greater than 32bits. When the handle is cast to 32bit, mmap
cannot match the requested map and causes X to crash.
This should be a NOOP on linux since drm_handle_t is always 32bit.
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
This helps avoid the n^2 performance cost of counting tree size when we
get a lot of relocations into our batch buffer. rgb10text on keithp's laptop
went from 136k glyphs/sec to 234k glyphs/sec.
|
|
|
|
Oops. Disting is hard.
|
|
|
|
|
|
|
|
This avoids using the oldest BO in the BO cache and waiting for it to be
idle before we turn around and render to it with the GPU. Thanks to
Chris Wilson for pointing out how silly we were being.
|
|
|
|
|
|
The minor CPU cost here is probably outweighed by bothering us with noise in
the tool.
|
|
libdrm isn't supposed to ship APIs not present in a released kernel.
|
|
|
|
nouveau_notifier.c had two places where void* was used in arithmetic,
fixed by using char*.
nouveau_dma_wait(), nouveau_notifier_wait_status() and
nouveau_resource_alloc() had signed/unsigned comparison warnings, fixed
by changing the function parameter into an unsigned type.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
|
|
|
|
|
|
|
|
This patch tries to use the available fence count to figure out whether a
given batch can succeed or not (just like the aperture check).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
|
|
It's also unused, so worthless.
|
|
It is impossible to replace the original semantics of this call purely
in userland, since the fb_id would change.
after discussion with Dr_Jakob
Signed-Off-By: Owain Ainsworth <oga@openbsd.org>
Acked-By: Jakob Bornecrantz <jakob@vmware.com>
|
|
Should be more portable this way.
|
|
Michel caught a case where we might overwrite a success or other return
value with EBUSY, so check the return value before checking for the
timeout condition.
|
|
In some cases, vblank interrupts may be disabled or otherwise broken.
The kernel has a 3s timeout builtin to handle these cases, but the X
server's SIGALM for cursor handling may interrupt vblank wait ioctls,
causing libdrm to restart the ioctl, making the kernel's timeout
useless.
This change tracks time across ioctl restarts and returns EBUSY to the
caller if the expected vblank sequence doesn't occur within 1s of the
first call.
Fixes fdo bz #18041, which is caused by a drmWaitVBlank hanging due to
the corresponding pipe getting disabled (thus preventing further events
from coming in).
|
|
Remember tiling mode values provided by appplications, and
record tiling mode when creating a buffer from another application. This
eliminates any need to ask the kernel for tiling values and also makes
reused buffers get the right tiling.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Applications may actually care if the mapping operation failed, so when
it happens, return an error indication. errno is probably trashed by
fprintf though.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
The execbuffer ioctl returns ENOMEM when it fails to pin all of the buffers
in the GTT. This is usually caused by the DRM client attempting to use too
much memory in a single request. Dumping out the requested and available
memory values should help point out failures in the DRM code to catch over
commitments of this form.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Add mode setting files to libdrm, including xf86drmMode.* and the new
drm_mode.h header. Also add a couple of tests to sanity check the
kernel interfaces and update code to support them.
|
|
|
|
We wouldn't want some remaining 3D rendering to scribble on our batchbuffer.
|
|
|
|
This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208.
We really just want the libdrm and ioctl bits, not all the driver
stuff.
|
|
|
|
we already have a 2.3.x version out there
|
|
|
|
This function can also serve the role that the bo_wait_rendering did, when
write_enable is unset.
|
|
into modesetting-gem
|
