In case of a kernel that is new enough to support multiple submit-
queues, but with an adreno generation which doesn't support multiple
prioritized ringbuffers, we'd attempt to open a submit-queue with
prio=1 (medium), which is rejected by the kernel.
This could happen either w/ an older mesa (which uses fd_pipe_new())
or a newer mesa which defaults to prio=1 if no pipe context priority
flags are set.
The simple answer to fix both cases is to clamp the requested priority
according to the number of rings. This might not do exactly what you
want, if we hypothetically had 2 rings (it would result in requested
medium priority being high priority instead of low priority). But the
number of rings (for hw gen's that support this) is purely a software
construct, so the easy answer there is to have the kernel advertise at
least 3 rings if it supports more than one. There isn't really any
reason to do otherwise.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Copy and paste error from exynos.
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
This patch adds a complete meson build system, including tests and
install. It has the necessary hooks to allow it be used as a subproject
for other meson based builds such as mesa.
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-and-tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.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>
Fixes this warning:
freedreno/kgsl/kgsl_ringbuffer.c: In function ‘kgsl_ringbuffer_flush’:
freedreno/kgsl/kgsl_ringbuffer.c:149:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
req.timestamp = (uint32_t)kgsl_ring->bo->hostptr;
^
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
`ring` cannot be non-null, so the label reduces to a simple return.
Then, there is no point initialising `ring` just to overwrite it before
anyone reads it.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
`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>
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>
Something that valgrind spotted:
==8441== Invalid read of size 4
==8441== at 0x5DEE168: msm_ringbuffer_emit_reloc (msm_ringbuffer.c:506)
==8441== by 0x5B48F0F: OUT_RELOCW (freedreno_util.h:241)
==8441== by 0x5B48F0F: fd5_emit_blit (fd5_emit.h:131)
==8441== by 0x5B48F0F: emit_gmem2mem_surf.isra.12 (fd5_gmem.c:450)
==8441== by 0x5B4910F: fd5_emit_tile_gmem2mem (fd5_gmem.c:477)
==8441== by 0x5B14943: render_tiles (freedreno_gmem.c:342)
==8441== by 0x5B14943: fd_gmem_render_tiles (freedreno_gmem.c:416)
==8441== by 0x5B0FBA7: batch_flush (freedreno_batch.c:281)
==8441== by 0x5B0FBA7: fd_batch_flush (freedreno_batch.c:306)
==8441== by 0x5B11FE7: fd_context_flush (freedreno_context.c:52)
==8441== by 0x58AD783: st_glFlush (st_cb_flush.c:121)
==8441== by 0x5751EE7: _mesa_make_current (context.c:1652)
==8441== by 0x58E6A97: st_api_make_current (st_manager.c:811)
==8441== by 0x5A2CE43: dri_unbind_context (dri_context.c:207)
==8441== by 0x5A2C77F: driUnbindContext (dri_util.c:589)
==8441== by 0x4AC8A67: MakeContextCurrent (glxcurrent.c:214)
==8441== Address 0x6f5eb1c is 204 bytes inside a block of size 240 free'd
==8441== at 0x4868F44: realloc (vg_replace_malloc.c:785)
==8441== by 0x5DEE143: msm_ringbuffer_emit_reloc (msm_ringbuffer.c:502)
==8441== by 0x5B48F0F: OUT_RELOCW (freedreno_util.h:241)
==8441== by 0x5B48F0F: fd5_emit_blit (fd5_emit.h:131)
==8441== by 0x5B48F0F: emit_gmem2mem_surf.isra.12 (fd5_gmem.c:450)
==8441== by 0x5B4910F: fd5_emit_tile_gmem2mem (fd5_gmem.c:477)
==8441== by 0x5B14943: render_tiles (freedreno_gmem.c:342)
==8441== by 0x5B14943: fd_gmem_render_tiles (freedreno_gmem.c:416)
==8441== by 0x5B0FBA7: batch_flush (freedreno_batch.c:281)
==8441== by 0x5B0FBA7: fd_batch_flush (freedreno_batch.c:306)
==8441== by 0x5B11FE7: fd_context_flush (freedreno_context.c:52)
==8441== by 0x58AD783: st_glFlush (st_cb_flush.c:121)
==8441== by 0x5751EE7: _mesa_make_current (context.c:1652)
==8441== by 0x58E6A97: st_api_make_current (st_manager.c:811)
==8441== by 0x5A2CE43: dri_unbind_context (dri_context.c:207)
==8441== by 0x5A2C77F: driUnbindContext (dri_util.c:589)
==8441== Block was alloc'd at
==8441== at 0x4868F44: realloc (vg_replace_malloc.c:785)
==8441== by 0x5DEE08B: msm_ringbuffer_emit_reloc (msm_ringbuffer.c:481)
==8441== by 0x5B48F0F: OUT_RELOCW (freedreno_util.h:241)
==8441== by 0x5B48F0F: fd5_emit_blit (fd5_emit.h:131)
==8441== by 0x5B48F0F: emit_gmem2mem_surf.isra.12 (fd5_gmem.c:450)
==8441== by 0x5B4909F: fd5_emit_tile_gmem2mem (fd5_gmem.c:465)
==8441== by 0x5B14943: render_tiles (freedreno_gmem.c:342)
==8441== by 0x5B14943: fd_gmem_render_tiles (freedreno_gmem.c:416)
==8441== by 0x5B0FBA7: batch_flush (freedreno_batch.c:281)
==8441== by 0x5B0FBA7: fd_batch_flush (freedreno_batch.c:306)
==8441== by 0x5B11FE7: fd_context_flush (freedreno_context.c:52)
==8441== by 0x58AD783: st_glFlush (st_cb_flush.c:121)
==8441== by 0x5751EE7: _mesa_make_current (context.c:1652)
==8441== by 0x58E6A97: st_api_make_current (st_manager.c:811)
==8441== by 0x5A2CE43: dri_unbind_context (dri_context.c:207)
==8441== by 0x5A2C77F: driUnbindContext (dri_util.c:589)
Signed-off-by: Rob Clark <robclark@freedesktop.org>
... across the makefiles. Currently this isn't much but that will change
shortly.
As an added bonus this fixes all present and future cases where we've
forgotten to strip out the headers from LOCAL_SRC_FILES.
In a couple of cases (the tests) we start setting
LOCAL_EXPORT_C_INCLUDE_DIRS, which shouldn't be an issue.
Cc: Chih-Wei Huang <cwhuang@android-x86.org>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Seems to be the default option since ~2009 with commit 2f31293ba78 "auto
import from //branches/cupcake/...@137197". Fleshed out from a larger
commit in the AOSP repo/fork.
Cc: Dan Willemsen <dwillemsen@google.com>
Cc: Chih-Wei Huang <cwhuang@android-x86.org>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
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>
Currently only some Android Makefiles are included in the release tarball.
To be more consistent one could either add the remaining files or don't
ship Android Makefiles altogether.
According to Emil the Android folk doesn't use our release tarballs.
Thus it makes sense to remove those files from distribution which also
means less work for maintenance in the future.
Suggested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
The 'deprecated' #define was causing problems with bionic system headers
which used __attribute__((deprecated)).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Tested-by: Rob Herring <robh@kernel.org>
Note: cache the last ring the bo was emitted on, to avoid excess
hashtable lookups. We do this by tracking ring seqno to avoid
problems with dangling pointers.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
First step towards supporting a single logical ringbuffer mapping to
multiple physical cmd buffers, which will enable dynamically growing
ringbuffers.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Not actually needed. It just needs to ensure that there is a
corresponding entry in the submit's cmds table.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Since they get vmap'd on the kernel side, they are a bit more costly.
Don't let them mingle with the riffraff.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
If user has emit'd reloc's, and then resets or deletes the ring, we want
to drop the ref's that the ring holds to the bo's to avoid a leak.
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>
Provide a way to insert a reference (ie. OUT_IB()) to a target ring,
executing all the cmds in the target ring from the start.
Sometimes the ringmarker stuff is just overkill. And it will won't
really work properly once we support multiple physical cmdstream buffers
per fd_ringbuffer. So in the future the old ringmarker related APIs
will be deprecated in a few releases.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
AOSP master now errors if LOCAL_SRC_FILES contains headers, so filter
out header files from the source lists.
Signed-off-by: Rob Herring <robh@kernel.org>
Make sure that this function is defined (even empty/dummy) when KGSL support is
disabled, since it's part of the driver i/f and it was reported to cause symbols
issues when building against musl libc implementation.
Reported-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
EGL_EXT_image_dma_buf_import specifies that the importer retains
ownership of the fd, rather then the importee.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
fixes the prime sharing race condition described by
"intel: Serialize drmPrimeFDToHandle with struct_mutex".
we inline fd_bo_from_handle() into fd_bo_from_dmabuf() and allow locking.
Signed-off-by: Varad Gautam <varadgautam@gmail.com>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
don't call drmIoctl() directly for prime bo's, use the wrappers instead.
v3: remove struct drm_prime_handle and split locking
Signed-off-by: Varad Gautam <varadgautam@gmail.com>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Importing a bo whose handle is still in the bo cache crashes during cleanup.
Remove bo from cache when importing.
Signed-off-by: Varad Gautam <varadgautam@gmail.com>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
User should only see these with LIBGL_DEBUG=verbose. But in case you
are hitting issues like "handle X at index Y already on submit list"
errors from the kernel, this gives some useful visibility for debug.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
It should be a less common case, but it is possible for a single bo to
be on multiple rings, for example when sharing a buffer across multiple
pipe_context's created from same pipe_screen.
So rather than completely fall over in this case, fallback to slow-path
of looping over all bo's in the ring's bo-table (but retain the fast-
path of constant-lookup for the first ring the buffer is on).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Group the parts related to building out submit ioctl into their own
sub-struct. Split out from next commit since it is just boring churn.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
This is used by radeon and freedreno and will be used
by amdgpu. I looked at switching to libdrm_lists.h,
but it's pretty horrible. E.g., DRMLISTFOREACHENTRYSAFE.
v2: remove missed list.h from tests/radeon/Makefile.am
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Abeit quite unlikely to get hit by this bug here, let just fix it.
v2: Correct conditional (do not call ioctl(DRM_IOCTL_PRIME_HANDLE_TO_FD)
when we already have the fd).
v3: Fix kgsl_pipe.c, suggested by Thierry.
Cc: freedreno@lists.freedesktop.org
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
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>
With earlier commits we've annotated the private symbols, thus
we no longer require the -fvisibility=hidden CFLAGS.
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>
With earlier changes we've implicitly add the relevant directories
to the includes list, via LOCAL_EXPORT_C_INCLUDES_DIRS.
v2: Update the top Android.mk as well.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Each of the libdrm_${hw} modules pull libdrm for linking as such:
libdrm's LOCAL_EXPORT_C_INCLUDE_DIRS are added to the includes list.
The former of which is already set to ${top} and ${top}/include/drm.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
- Don't add ${hw}/${hw}, but ${hw} to the includes path. The former
does not exist.
- Set the variable for libkms.
Inspired by the work of from Chih-Wei from the Android-x86 project.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
v2: Fold libpciaccess and libdrm into a single local_shared_libraries
Acked-by: Jan Vesely <jan.vesely@rutgers.edu>
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
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>
We also need to check handle_table in the _from_handle() path and the
_from_dmabuf() (which goes through _from_handle()) to avoid duplicate
imports.
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>
Autotools is already smart enough to pick the *.pc.in files but it
needs some help with the Android.mk ones.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
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>
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>
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>
Rob Clark
Dylan Baker
Emil Velikov
Eric Engestrom
Eric Engestrom
Matt Turner
Andreas Boll
Rob Herring
Nicolas Dechesne
Rob Clark
Varad Gautam
Alex Deucher
Chih-Wei Huang
Maarten Lankhorst