When unpacking the texture sample result ensure it is moved to the
proper expected dest register.
This fixes incorrect texturing in Chromium using PixiJS framework.
CC: mesa-stable
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18122>
The default lib prefix is `lib`, so adding `lib` to the lib name just
results in `liblibbroadcom_v3d.a` for instance.
Those are internal, build-temporary static libraries that end up being
linked into the real user-visible libraries, so it doesn't really
matter, but we might as well just clean up their names anyway.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18171>
Allows following tests to pass.
dEQP-VK.wsi.android.swapchain.create#image_swapchain_create_info
dEQP-VK.wsi.android.swapchain.simulate_oom#image_swapchain_create_info
Venus code was used as example.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18047>
Android CDD has additional requirements that must be met in order to
enable 1.1+:
- samplerYcbcrConversion
- VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT
- VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT
- VK_ANDROID_external_memory_android_hardware_buffer >= v2
Requirements are checked by:
android.graphics.cts.VulkanFeaturesTest#testVulkan1_1Requirements CTS
Fixes: 2686c5419d ("v3dv: add Android support")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18047>
vk_common_AcquireImageANDROID and vk_common_QueueSignalReleaseImageANDROID
expect sync_fd import/export to be enabled, otherwise they crashes
while trying to ImportSemaphoreFdKHR() / GetSemaphoreFdKHR().
Features was disabled on Linux to skip sync_fd CTS tests, which is using
late vkEvent signalling which causes deadlock / dEQP timeout on v3dv.
One of the options was implementing blocking v3dv-specific
AcquireImageANDROID / QueueSignalReleaseImageANDROID to avoid importing
/ exporting sync_fd, but since these features are also required by CDD
for Vulkan 1.1 and above, it was decided to enable the extensions for
Android in exchange of a few failed dEQP tests (which should not cause
any issues in non-dEQP scenarious).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6977
Fixes: 316728a55b ("v3dv: Switch to the common submit framework")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18047>
We improved this a long time ago and now it emits a clear rect inside
the current subpass job instead of emitting its own job with its own
RCL, so we no longer need to handle this as an exception to the rule.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
For this we add a scoring system that evaluates various aspects of
the draw calls in a job.
If the cost of the geometry side of the pipeline is too high, then
we may pay too high a price in double-buffer mode because with smaller
tile size may will probably have more vertex shader invocations in the
render and binning stages.
On the other hand, if rendering cost is not high enough, we may not
have enough rendering work to hide the latency of tile stores in
double-buffer mode.
Also, because we need to make a decision after we know all the draw
calls in a job, but the double-buffer enable bit comes in the
TILE_BINNING_MODE_CFG that needs to be emitted first in the binning
command list before the draw calls are recorded, if we decide to
enable it we need to rewrite that packet and we need to size the
tile state properly to account for the extra tiles. For this
purpose we delay tile state setup for render pass jobs until we are
finishing a job.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
We want to have control over the double-buffer setting here so we can control
explicitly from the driver when we want to enable this mode.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
These are jobs for which we may want to enable double-buffering,
which affects tile state allocation. Since the idea is that we
want to decide about double buffering late, we also want to
postpone allocation of the tile state until we are about to
emit the RCL for the job.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
If we enable double-buffer we are reducing the tile size, and thus,
we'll need more tiles and a larger tile state allocation, so we'll
need to call to this helper.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
MSAA is not compatible with double-buffer mode. Also, jobs that emit
tile loads or that don't have any stores can't take advantage
of double-buffer mode.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
neither of these have a real alpha channel, so reuse the xrgb blend
clamping here to ensure the "right" alpha value is used
cc: mesa-stable
fixes:
spec@arb_texture_float@fbo-blending-formats
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17687>
This is known to produce bogus results for certain combinations of
operands, so don't use it. See this issue for details:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/6555
With this change, the idiv lowering will produce mul_high instructions,
so we need to instruct the compiler to lower those with the ALU lowering
right after the idiv lowering by adding the lower_mul_high option (we
only need to add this to V3D, since V3DV already had it set). This will
cause injection of uadd_carry instructions, for which we have backend
implementations that produce better code for us than the NIR lowering.
total instructions in shared programs: 12457692 -> 12463625 (0.05%)
instructions in affected programs: 23115 -> 29048 (25.67%)
helped: 0
HURT: 111
total threads in shared programs: 416372 -> 416368 (<.01%)
threads in affected programs: 8 -> 4 (-50.00%)
helped: 0
HURT: 2
total uniforms in shared programs: 3704067 -> 3704589 (0.01%)
uniforms in affected programs: 5804 -> 6326 (8.99%)
helped: 2
HURT: 109
total max-temps in shared programs: 2147845 -> 2148088 (0.01%)
max-temps in affected programs: 2456 -> 2699 (9.89%)
helped: 6
HURT: 91
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17871>
As it is needed to have V3D_DEBUG defined. For the v3d case, I did it
restoring v3d_process_debug_variable, as it is at v3d_debug.c that
DEBUG_GET_ONCE_FLAGS_OPTION is called.
Fixes: 106b33405e ("vc4/v3d: stop adding NORAST when SHADERDB debug option is used")
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17812>
Right now if we use the option SHADERDB, NORAST is added
automatically. There's no comment justifying it, neither a lot of info
on the commits that added that. But I guess that the purpose is that
SHADERDB option is assumed to be used only to gather shader-db stats,
so setting setting NORAST would allow to get those dumps faster.
But adding debug options automatically can be confusing, as we could
get a behaviour that we were not expecting. At least I needed to check
why using SHADERDB was getting a black screen. And if we want to get
this behaviour, we can easily add manually the NORAST.
Finally, v3dv doesn't support NORAST right now (and we don't have
immediate plans to implement it), so it is somewhat inconsistent to
get different behaviour from the same debug option from the two
drivers.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17788>
For some reason the Vulkan spec required that these features must be
supported even though they only affect features that are optional
in Vulkan 1.2 and that we don't support, so enabling them doesn't
have any practical implications for us.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17786>
Semaphore waits in a command buffer only affect the first jobs we execute
in each hardware queue since jobs in the same queue are serialized against
each other. Binning syncs in particular, only affect CL jobs.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17594>
We only want to cleant BCL barrier flags if we consume a BCL barrier.
For example, if the client records a barrier for an index buffer
it should apply to the next draw call that uses an index buffer
which may not be the current draw call but one coming after it.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17594>
Two advantages:
* When using NIR_DEBUG=nir_print_xx, will print outcome only if
there is a change
* We can use NIR_PASS(_, ...) instead of NIR_PASS_V, that has
slightly more validation checks.
This includes:
* v3d_nir_lower_image_load_store
* v3d_nir_lower_io
* v3d_nir_lower_line_smooth
* v3d_nir_lower_load_store_bitsize
* v3d_nir_lower_robust_buffer_access
* v3d_nir_lower_scratch
* v3d_nir_lower_txf_ms
As we are here we also simplify some of them by using the
nir_shader_instructions_pass helper.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17609>
The trigger for this commit was when we found that we were not calling
nir_metadata_preserve when lowering the layout code. But then I found
that it would be better to just update the code to use
nir_shader_instructions_pass, so we can avoid to manually:
* Initialize the nir_builder
* Call nir_foreach functions (we pass the callback)
* Call nir_metadata_preserve functions (that as mentioned we were not calling)
We also get a nice cleanup of several functions by reducing the number
of parameters (we pass a state struct).
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17609>
This represents an offset from the actual start of the image data,
not from the start of the memory allocation bound to the image.
Fixes:
dEQP-VK.image.subresource_layout.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17648>
From the Vulkan spec:
"If poolSizeCount is not 0, pPoolSizes must be a valid pointer to an
array of poolSizeCount valid VkDescriptorPoolSize structures"
So 0 is actually allowed and there is a CTS to check it is handled gracefully.
Fixes:
dEQP-VK.api.descriptor_pool.zero_pool_size_count
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17648>
