In mesa/gallium, a pipe_fence can outlive the pipe_context it was
created from. But to wait on the fence we need to know the submit-
queue (ie. the fd_pipe).
The most straightforward way to fix this is to add reference counting
to the fd_pipe and let the fence hold a reference to the pipe (rather
than hanging on to the context, which might have been destroyed before
the fence).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
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>
With a new-enough kernel to support prioritized submit-queues, we can
expose priority level support to mesa. Open a submit queue associated
with the fd_pipe and pass it's id back to SUBMIT ioctl.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
`pipe` cannot be non-null, so the label reduces to a simple return.
Then, there is no point initialising `pipe` just to overwrite it before
anyone reads it.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
a5xx and later are 64bit devices.. make reloc's handle that. A new
public symbol is introduced to avoid silent problems with new mesa and
old libdrm (since on 64b reloc consumes two dwords).
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>
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>
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>
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>
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>
Rob Clark
Eric Engestrom
Eric Engestrom
Emil Velikov
Rob Clark
Maarten Lankhorst