| Age | Commit message (Collapse) | Author |
|---|
|
Already declared in our public header freedreno_drmif.h
Cc: Rob Clark <robclark@freedesktop.org>
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Rob Clark <robclark@freedesktop.org>
|
|
v2 Rename the headers variable(s) to *_H_FILES.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Will be used to consolidate the required sources lists as well as the
install-able headers. This is turn will help us to avoid the
duplication with the upcoming Android build support.
v2: Rename the headers variable to *_H_FILES.
v3: Rebase on top of symbol visibility patches.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Hiding fd_device_del_locked, and fd_cleanup_bo_cache.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
|
|
Userspace needs to know the patch-revision in addition to just the
gpu-id (ie. 320, 305, etc).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Since realloc() doesn't zero-init.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
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>
|
|
Don't even bother trying DRM_KGSL_GEM_CREATE_FD. It hasn't worked since
(afaict) 2.6.35 kernels. And in some cases seems to cause some
problems. Instead just allocate a minimum size dummy object (just for
purposes of having a handle) and then mmap the framebuffer as user-mem
(which is deprecated, but seems to still work.. and as far as I can tell
is the best option for now).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Need to update timestamp on all ring's associated with a submit (ie.
both the binning pass and main ring). Also, make sure nr_reloc's
in particular gets cleared if the rb is reset.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
The userspace headers were intended to be BSD license.
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>
|
|
Allow IB to different ringbuffer in addition to just different part of
same ringbuffer. In particular, we need to add bo's to the parent (ie.
one passed to flush) bo table, since the bo table applies to all the
cmd buffers in submit ioctl.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
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>
|
|
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Handles automake complains about lack of forward-compatibility, due to the
source files in the kgsl and msm backends/folders.
Cc: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Otherwise build will fail, as drm/drm.h is not available.
Cc: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
This adds support for the "msm" backend, using the upstream msm drm/kms
driver.
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>
|
|
When adding the name tracking, I missed removing from the name table
when the bo was deleted, leaving a dangling pointer.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Things are worse if we issueibcmds with bogus gpu ptrs, so it is better
to just make userspace crash when things go pear shaped.
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>
|
|
Super-cheezy way to synchronization between mesa and ddx.. the
SET_ACTIVE ioctl gives us a way to stash a 32b # w/ a GEM bo, and
GET_BUFINFO gives us a way to retrieve it. We use this to stash
the timestamp of the last ISSUEIBCMDS on the buffer.
To avoid an obscene amount of syscalls, we:
1) Only set the timestamp for buffers w/ an flink name, ie.
only buffers shared across processes. This is enough to
catch the DRI2 buffers.
2) Only set the timestamp for buffers submitted to the 3d ring
and only check the timestamps on buffers submitted to the
2d ring. This should be enough to handle synchronizing of
presentation blit. We could do synchronization in the other
direction too, but that would be problematic if we are using
the 3d ring from DDX, since client side wouldn't know this.
The waiting on timestamp happens before flush, and setting of
timestamp happens after flush. It is transparent to the user
of libdrm_freedreno as all the tracking of buffers happens via
_emit_reloc()..
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Gallium driver will need to query this to figure out whether to load the
a2xx or a3xx driver.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Needed for RB_COPY_DEST_BASE register on a3xx.
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
I even compile time tested this on a panda with make dist!
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
|
|
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>
|
