Android rules to build u_trace sources and u_tracepoints generated sources
Changelog:
- add util/u_tracepoints.{c,h} gen rules for Android using $(MESA_PYTHON3)
- update Makefile.sources with the required sources and generated sources
Fixes: 3471af9c6c ("gallium/aux: Add GPU tracepoint mechanism")
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7942>
This is in preparation for additional generated sources rules for Android
which will require ad hoc rules, so it is necessary to replace old ones
NOTE: pre-existing gen rules based on $(transform-generated-source) macro
are both obsolete and use of '%' pattern rule is incompatible with ad hoc
python commands for different targets
Changelog:
- remove util/u_format_srgb.c target
- replace obsolete indices/{u_indices,unfilled}_gen.c 'common' gen rules
with 'per target' gen rules using $(MESA_PYTHON3) as per meson gen rules
Fixes: 3471af9c6c ("gallium/aux: Add GPU tracepoint mechanism")
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7942>
Lavapipe exposes support for the logicOp feature, but doesn't actually
respect the state. This is easy to fix, so let's plumb it through.
This fixes spec@!opengl 1.0@gl-1.0-logicop When running with Zink on
Lavapipe.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7932>
MoltenVK does not export the vkGetPhysical*2() functionns, even in Vulkan 1.2.154.0 where the instance version moves from 1.0 to 1.1.
If the extension is present and used the KHR versions of the functions can be used.
From the spec the vkGetPhysicalDevice*2() functions should be avaiable from Vk 1.1 loaders and devices. Which implies MoltenVK might be misbehaving.
This change allows the extension to be used, if present, before the Vk 1.1 version check.
Fixes: 752f6d80 ("zink: setup version dependent VkPhysicalDeviceVulkan*Features and VkPhysicalDeviceVulkan*Properties.")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7960>
It's straightforward except that the amdgpu winsys had to be cleaned up
to allow this.
radeon_cmdbuf is inlined and optionally the winsys can save the pointer
to it. radeon_cmdbuf::priv points to the winsys cs structure.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7907>
This removes the "warn: No Varying records" printed by pandecode.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7921>
Move the 2 words padding out of the draw descriptor to fix Midgard tiler
job decoding.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7921>
Besides leaking and a lack of thread-safety, it would also incorrectly
share front buffers if multiple contexts happened to use the same
size/format, as demonstrated by the new unit test.
Closes: #2035
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7886>
We were returning a pointer to use-after-free the depth buffer, not
updating it in after future rendering, and also not y flipping it. A
little refactor to mostly reuse the color buffer's path makes it easy to
do it all right.
Adds a unit test to check for these bugs.
Closes: #885
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7886>
If we don't do that, the line_stride might be wrong. We also need
to create a new BO if the previous one is too small to hold the
linear version, which can happen with the tile alignment done on
linear+renderable resources.
Suggested-by: Icecream95
Fixes: d4f662a252 ("panfrost: Update the resource layout when doing a tile -> linear conversion")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7821>
Use DWORD count to calculate the number of DWORD filled in slice header template.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6942>
For blit/compute non-draw batches, we are already emitting traces in the
draw cmdstream, which means we cannot also have traces in the GMEM ring
(as that breaks the FIFO ordering of traces)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7818>
This adds a mechanism, loosely inspired by the linux kernel's tracepoint
mechanism, to declare and emit tracepoints. A driver provided callback
is used to emit cmdstream to capture timestamps on the GPU, which are
used to later "render" the emitted tracepoints.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Acked-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7818>
Building svgadrm module on window platform is not required.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7806>
Unlike the other drivers, the D3D12 driver is hardware accelerated, so
it's going to be a more reasonable choice. So let's prefer it.
This only matters for people who build with the D3D12 driver. And they
can set the GALLIUM_DRIVER environment variable as appropriate to
override it.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7534>
Setting these avoids a few warnings while running glxgears on Zink on
Lavapipe. There's a lot more flags to set here, but this is better than
nothing.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7879>
In the following sequence:
- transfer_map(buffer, DISCARD) // use staging upload
- memcpy(...)
- transfer_unmap
- draw
- transfer_map(buffer, UNSYNCHRONIZED) // non-staging upload
- memcpy(...)
- draw
Currently the order of operations is:
- map#1 - staging buffer
- memcpy to staging buffer
- map#2
- memcpy to buffer
- staging buffer copy to real buffer
- draw#1
- draw#2
When the 2nd map operation doesn't use UNSYNCHRONIZED, the tc_sync_msg() call
will make sure that the bo is unused before mapping it.
But, if it does use UNSYNCHRONIZED and the mapped intervals overlap this commit
clears the UNSYNCHRONIZED to make sure ordering is maintained.
This will affect performance, but correct output is better than fast output.
See https://gitlab.freedesktop.org/mesa/mesa/-/issues/3611.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7098>
llvmpipe was reporting 32 max const buffers, while sizing its arrays to 16
according to gallivm's #define.
Fixes: 1d35f77228 ("gallivm,llvmpipe,draw: Support multiple constant buffers.")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7695>
This is only required for the DRI-path. For the swrast code-path, we
don't need this.
We also don't need to explicitly test for it in the DRI-path, because we
test for KHR_external_memory_fd, which depends on KHR_external_memory. So
no implementation will expose the former without the latter.
Fixes: f1432fd3e2 ("zink: generate extension infrastructure using a python script")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7882>
Three things:
1. MSVC dislikes mismatching declaration/definition of __declspec(dllexport).
Since CL headers don't have the declspec, the implementations should't either.
2. An unnamed brace-initialization gets deduced as an initializer list, instead
of a brace-constructed string. Just add the type name.
3. posix_memalign doesn't exist on Windows.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7680>
Constructing a class where the class name is wrapped in parens
doesn't work with MSVC. I see no good reason to do that so drop
the parens. Also, use a generic page size helper instead of hardcoding
something OS-specific.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7680>
