Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7fb6224340 in calloc (/usr/lib64/libasan.so.6.0.0+0xa4340)
#1 0x7facfdd5a0 in u_transfer_helper_create ../src/gallium/auxiliary/util/u_transfer_helper.c:580
#2 0x7facf2e09c in lima_resource_screen_init ../src/gallium/drivers/lima/lima_resource.c:935
#3 0x7facf23af4 in lima_screen_create ../src/gallium/drivers/lima/lima_screen.c:746
#4 0x7fac83ed30 in kmsro_drm_screen_create ../src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c:124
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20764>
Whenever we add or remove a flag here, we need to update a bunch of
drivers in a fragile way. Moving to flags here instead should make this
a bit easier to maintain in the future.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17959>
24be011901 ("lima: wire up MSAA 4x support") switched to aligning all the
buffers to tile size and it resulted in allocating 16x more memory for
index, vertex and constant buffers.
We only want to align textures and render targets to tile size, not
other buffers, so restore old logic, but relax it.
Fixes: 24be011901 ("lima: wire up MSAA 4x support")
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17283>
Utgard supports MSAA 4x, so wire it up.
RSW bits were already REd by Luc, the only remaining part was storing
non-resolved buffers, reloading them (including for depth/stencil) and
doing MSAA resolve.
To store non-resolved buffer we need to set mrt_pitch and mrt_bits
registers in WB, and to resolve non-resolved buffer we need to reload
it into individual samples and then write out with mrt_bits = 0, it's
now done by lima blitter.
We also need to do resolve on transfer_map() of multi-sampled buffers,
so utilize u_transfer_helper for that.
As a side fix, it turns out that our wb_reg definition wasn't correct,
'zero' isn't always zero, it's set if we need to swap channels, and
it goes before mrt_bits. mrt_bits actually enables multiple MRTs,
so this commit renames 'zero' to 'flags' and changes its position.
If mrt_bits == 0 and MSAA is enabled, GPU does resolve
in place, to expose this functionality we set PIPE_CAP_SURFACE_SAMPLE_COUNT.
Fixes dEQP-GLES2.functional.multisample.*
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13963>
It should be more efficient than u_blitter since it skips
vertex shader stage. Also it's a prerequisite for supporting
MSAA since u_blitter can't do MSAA resolve for us.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16686>
It returned false when a render condition was not bound, but it should
have returned true.
The bool stuff is random and incomplete, but that's life.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13602>
Currently stride, offset, modifier is obtained by invoking
lima_resource_get_handle() with WINSYS_HANDLE_TYPE_KMS.
Before commit 47f000c170 this path was working. Obtained handle
was simply ignored by DRI frontend and only requested data used.
After commit 47f000c170 such requests started to fail when
DRI is initialized using KMSRO and resource has no scanout data.
When lima_resource_get_param() is implemented, it will be used in
a first place to obtain resource data.
Fixes: 47f000c170 ("lima: fail in get_handle(TYPE_KMS) without a scanout resource")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12362>
The previous logic was returning a handle valid for the render-only
device if rsc->scanout was NULL. However the caller doesn't expect
this: the caller will use the handle with the KMS device.
Instead of returning a handle for the wrong device, fail if we don't
have one.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12074>
BO resources imported from a handle may have an offset provided, which
reduces the available size within the BO. Take this in account when
checking that the size is sufficient in lima.
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11076>
The u_resource_vtbl indirection is going to be removed.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10659>
Overwriting entire resource multiple times indicates streaming and in this
case it's more efficient to use linear layout to avoid expensive linear->tiled
conversions.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10572>
We don't need stride of imported buffer to be equal to calculated
stride if the buffer is linear.
Fixes#3070
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9646>
Need to import client buffer to display drm device, otherwise
get following xserver error log:
[ 190.982] (WW) modeset(0): Page flip failed: No such file or directory
[ 190.982] (EE) modeset(0): present flip failed
With this fix, full screen x11 client can display its window
buffer directly without a copy. Tested on Allwinner H3, 1080p
full screen glxgears go from 163FPS to 173FPS.
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9038>
Some opengl features require shader recompilation to be implemented in
the mali400 and can only be detected at draw time. In some applications,
this could lead to recompiling shaders on every frame which could kill
performance. Introduce a shader cache to prevent this issue.
lima didn't have vertex shader recompilation yet but it is needed to
implement followup features, so include it here too.
Code heavily borrowed from the vc4 shader cache implementation.
One notable difference between the vc4 reference implementation and lima
is that lima still compiles the base shader at state creation time
without deferring it to the next draw (so that it stays compatible with
behaviour expected by unmodified shader-db, for example).
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8357>
The reload texture descriptor needs to take care of the mipmap level
and the layer in case of GL_TEXTURE_CUBE_MAP.
glCopyTexSubImage2D triggers the lima_blit function which ends in a draw.
A reload is necessary. The reload texture descriptor is always built with
just one mipmap level, but this needs to be the level we want to reload,
not just 0. We also have to take care of the cubemap face.
This fixes the following dEQP tests:
dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.2d_rgb
dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.2d_rgba
dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.cube_rgb
dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.cube_rgba
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Andreas Baierl <ichgeh@imkreisrum.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6816>
In stream draws, the resource bo might be in use in a previous draw.
Allocate a new one for the resource to avoid overwriting data in use.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6503>
With EGL_EXT_image_dma_buf_import, user can import dma_buf
with offset.
This is also used by AOSP GLConsumer::updateTexImage
with HAL_PIXEL_FORMAT_YV12 buffer which store YUV planes in
the same buffer with offset. Render sample from it using
GL_OES_EGL_image_external. This should fix some video
display problem when using MediaCodec soft decoding which
generates HAL_PIXEL_FORMAT_YV12 buffer and render it on
screen.
Test program:
https://github.com/yuq/gfx/tree/master/yuv2rgb/dma-buf
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4362>
Fragment shader can write depth and stencil if we set necessary flags
in RSW. In addition to that we need to use special format for Z24S8.
Original format is apparently Z24X8 since we can't sample stencil in GLES2.
This new format also seems to use several components for storing depth
since we saw r != g != b when sampling with this format.
[vasily: - initialize clear->depth to 0xffffff if we reload depth, just
like blob does. Reloading doesn't work otherwise
- use single bitmap for reload type]
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4197>
Generating PLB PP stream is expensive. PLB PP stream content depends on
damage, and if damage consists of several rects it's impossible to come
up with a simple key.
Simplify damage to a single bounding box so we have a simple key
and cache PLB PP stream. Cache size is limited to 0.1% of system RAM and
once limit is reached least recently used entries are dropped.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3834>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3834>
This information is preserved across draws and needed
when task submission.
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3755>
lima_submit is created by lima_submit_get() in draw/clear functions
and freed after submit to kernel.
There is a hash map to find the same lima_submit for color/depth
buffer combination if user switch framebuffer w/o flush the command
then switch back again.
v2:
rename lima_flush_submit to lima_flush_submit_accessing_bo.
v3:
delay flush access submit to lima_update_submit_wb when really know
if this submit will write to the target buffer.
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3755>
There's a lot going on here (it's a ton of commits squashed together
since otherwise this would be impossible to review...)
1. We have a fast path for linear->tiled for whole (aligned) tiles, but we
have to use a slow path for unaligned accesses. We can get a pretty
major win for partial updates by using this slow path simply on the
borders of the update region, and then hit the fast path for the
tile-aligned interior. This does require some shuffling.
2. Mark the LUTs constant, which allows the compiler to inline them,
which pairs well with loop unrolling (eliminating the memory accesses
and just becoming some immediates.. which are not as immediate on
aarch64 as I'd like..)
3. Add fast path for bpp1/2/8/16. These use the same algorithm and we
have native types for them, so may as well get the fast path.
4. Drop generic path for bpp != 1/2/8/16, since these formats are
generally awful and there's no way to tile them efficienctly and
honestly there's not a good reason too either. Lima doesn't support any
of these formats; Panfrost can make the opinionated choice to make them
linear.
5. Specialize the unaligned routines. They don't have to be fully
generic, they just can't assume alignment. So now they should be nearly
as fast as the aligned versions (which get some extra tricks to be even
faster but the difference might be neglible on some workloads).
6. Specialize also for the size of the tile, to allow 4x4 tiling as well
as 16x16 tiling. This allows compressed textures to be efficiently tiled
with the same routines (so we add support for tiling ASTC/ETC textures
while we're at it)
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> #lima on Mali400
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3414>
There's an implicit dependence on Gallium here that will add more
complexity than needed when testing/optimizing out of driver as well as
potentially Vulkanizing. We don't need a full pipe_box, just the x/y/w/h
properties directly.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> #lima on Mali400
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3414>
Add debug flag to disable tiling. Note that it prevents lima from creating
tiled buffers, but it's still able to import them if modifier is specified
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Use linear layout for shared buffers if modifier is not specified
and use linear layout when importing buffers with invalid modifier.
Fixes: 01a451b04d ("lima: handle DRM_FORMAT_MOD_INVALID in resource_from_handle()")
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Assume that resource is tiled if we get DRM_FORMAT_MOD_INVALID
in resource_from_handle() and we don't have RO.
Fixes: 8c12f4e5f2 ("lima: enable tiling")
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Now that we have tiled format modifier merged into linux we can enable tiling.
That should improve overall performance and also workaround broken mipmapping
for linear textures since now we prefer tiled textures.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
To make PIPE_FORMATs usable from non-gallium parts of Mesa, I want to
move their helpers out of gallium. Since u_format used
util_copy_rect(), I moved that in there, too.
I've put it in a separate directory in util/ because it's a big chunk
of related code, and it's not clear to me whether we might want it as
a separate library from libmesa_util at some point.
Closes: #1905
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Allocating BOs is expensive, so we should avoid doing that by caching
freed BOs.
BO cache is modelled after one in v3d driver and works as follows:
- in lima_bo_create() check if we have matching BO in cache and return
it if there's one, allocate new BO otherwise.
- in lima_bo_unreference() (renamed from lima_bo_free()): put BO in
cache instead of freeing it and remove all stale BOs from cache
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Some time weston set full damage region. It is
more effient to use the cached pp stream instead
of dynamically create one.
Reviewed-and-Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
This extension set a damage region for each
buffer swap which can be used to reduce buffer
reload cost by only feed damage region's tile
buffer address for PP.
Reviewed-and-Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
This is a relatively minimal change to adjust all the gallium interfaces
to use bool instead of boolean. I tried to avoid making unrelated
changes inside of drivers to flip boolean -> bool to reduce the risk of
regressions (the compiler will much more easily allow "dirty" values
inside a char-based boolean than a C99 _Bool).
This has been build-tested on amd64 with:
Gallium drivers: nouveau r300 r600 radeonsi freedreno swrast etnaviv v3d
vc4 i915 svga virgl swr panfrost iris lima kmsro
Gallium st: mesa xa xvmc xvmc vdpau va
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
This will allow both drivers to share this code. Both drivers
build-tested with meson. Android build not tested.
v2: Change naming from tiling->shared, in case Lima and Panfrost can
share more in the future. Fix Android build system.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-and-tested-by: Qiang Yu <yuq825@gmail.com>
Buffer needs to be reloaded every time unless explicit clear() was
called.
Fixes rendering issues with wayland compositors.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
