This will prevent any more missing `#include "config.h"` bug, at the
cost of having to recompile some files that didn't need to be when
changing build options.
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Move closing the fd to after subclass ->destroy() (since it might want
to delete gem bo's, etc), and actually free() the fd_device object.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The normal bo cache uses some intermediate steps between power of two
jumps to reduce memory wastage. But for a ringbuffer bo cache, we do
not need this.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
gallium needs to know if the kernel is new enough to support explicit
fencing, dynamically grown ringbuffers, etc.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
With a new enough drm/msm, we can let the kernel know about buffers that
are in the bo cache, so the kernel can free them under memory pressure.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Split out interface to allocate from and release to bo-cache, and get
rid of direct usage of bucket level API from fd_bo/etc.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Eventually we'll want a separate bo-cache for ringbuffer bo's, since
ringbuffer bo's get vmap'd on the kernel side, it is preferrable to
re-use them as ringbuffers rather than something else. Plus should
help to add madvise support if it is a bit better decoupled from bo
allocation (next patch).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Some compilers (like the Oracle Studio), require that the function
declaration must be annotated with the same visibility attribute as the
definition. As annotating functions with drm_public is no longer
required just remove the macro.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
They are less and easier to track than the public ones. The macro
drm_public will be going away by the end of the series.
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
libdrm_freedreno currently supports two backends, 'msm' for the upstream
drm/msm driver, and 'kgsl' which supports (to some extent), the android/
downstream kgsl driver plus a sort of drm shim nonsense to get flink
names.
However, kgsl support is strictly on a best-effort basis. Different
android devices with different versions of kgsl may have different
abi's. And the existing kgsl interface (at least the parts of it that
we use) is completely broken for 64bit. Lets disable it by default lest
anyone actually try to use it.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
4c2766b (drm_mmap/drm_unmap) brought this error for every .c file that
was not #including config.h:
In file included from private.h:4:0,
from abi16.c:29:
../libdrm.h: In function 'drm_munmap':
../libdrm.h:81:4: error: size of unnamed array is negative
Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
There seem to be some cases (I've noticed this switching resolution in
some games, for example) where the fd can get closed() before the device
and all it's bo's are destroyed. Which, if the drm device is opened
again and bo's are allocated with the same handles, results that when
the first pipe_screen/pipe_context is destroyed causes the first dev to
close handles for bo's allocated by the second device.
The easy solution to that is to add a mode where the fd_device creates
it's own private fd (a dup()).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Workloads which create many transient buffers cause significant CPU
overhead in buffer allocation, zeroing, cache maint, and mmap setup.
By caching and re-using existing buffers, the CPU overhead drops
significantly. See:
http://bloggingthemonkey.blogspot.com/2013/09/freedreno-update-moar-fps.html
A simple time based policy is used for purging the cache. Once the
kernel supports it, we could use madvise style API to handle memory
pressure scenarios a bit better.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Split out common code and backend. Current backend is for 'kgsl'
android driver, but a new backend will provide support for the
upstream msm drm/kms driver.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Due to the evil userspace buffer tracking we have to do, and hacks for
creating GEM buffer from fbdev/scanout, "evil-twin" fd_bo objects are
problematic. So introduce hashtable tracking of bo's and dev's, to
avoid getting duplicate fd_bo ptrs for the same underlying gem object,
in particular when importing via flink name.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The libdrm_freedreno helper layer for use by xf86-video-freedreno,
fdre (freedreno r/e library and tests for driving gpu), and eventual
gallium driver for the Adreno GPU. This uses the msm gpu driver
from QCOM's android kernel tree.
Note that current msm kernel driver is a bit strange. It provides a
DRM interface for GEM, which is basically sufficient to have DRI2
working. But it does not provide KMS. And interface to 2d and 3d
cores is via different other devices (/dev/kgsl-*). This is not
quite how I'd write a DRM driver, but at this stage it is useful for
xf86-video-freedreno and fdre (and eventual gallium driver) to be
able to work on existing kernel driver from QCOM, to allow to
capture cmdstream dumps from the binary blob drivers without having
to reboot. So libdrm_freedreno attempts to hide most of the crazy.
The intention is that when there is a proper kernel driver, it will
be mostly just changes in libdrm_freedreno to adapt the gallium
driver and xf86-video-freedreno (ignoring the fbdev->KMS changes).
So don't look at freedreno as an example of how to write a libdrm
module or a DRM driver.. it is just an attempt to paper over a non-
standard kernel driver architecture.
v1: original
v2: hold ref's to pending bo's (because qcom's kernel driver doesn't),
various bug fixes, add ringbuffer markers so we can emit IB's to
portion of ringbuffer (so that gallium driver can use a single
ringbuffer for both tile cmds and draw cmds.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Eric Engestrom
Rob Clark
Emil Velikov
Rob Clark
Maarten Lankhorst