Helpful if your nm executable has a prefix based on the
architecture, for example.
Signed-off-by: Heiko Becker <heirecka@exherbo.org>
Cc: Timo Gurr <timo.gurr@gmail.com>
[Eric: v2: rebase and add Meson support]
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
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>
Heiko Becker
Eric Engestrom
Rob Clark
Dylan Baker
Emil Velikov
Eric Engestrom
Matt Turner
Andreas Boll
Rob Herring
Nicolas Dechesne