This is needed to lower some corner cases correctly,
in case the same operand occurs multiple times:
e.g. v0 = p_create_vector(v0[0:8], v0[0:8], v0[0:8], v0[0:8])
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5226>
As there are no SDWA instructions, we need to take care not to overwrite
the upper bits of other copy_operation's operands.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5226>
when shaders are created and destroyed in large numbers, the same pointers
get reused for different shaders, which can lead to bad lookups in the
program_cache hash table.
now each shader tracks its program usage to automatically remove itself from
that program in order to avoid hash collisions
fixesmesa/mesa#3053
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5315>
rm -rf and then copying over all the contents again is a waste of time
when we'll almost always be using the same rootfs. Saves about 30s of job
time.
Closes: #3065
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5266>
Test 1/50th of the CTS on a630 pre-merge, since we've got hardware that
can do it and infrastructure that should handle instability with a
less-mature driver.
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5266>
I'm going to enable the VK CTS on cheza, so swap the deqp we have in the
container. build-deqp-vk already included GLES deqp binaries and data,
and is a newer branch than the last opengl-es-cts tag.
This brings a few things back over from build-deqp-gl for testlog
extraction, and copyes out the GLES mustpass lists.
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5266>
mpv is passing in a NULL destination_video_rect, which results in a
black screen when playing videos using VDPAU in some cases.
Signed-off-by: Thong Thai <thong.thai@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5386>
This seems to be working now, but it wasn't working before.
I don't know what fixed this. Tested on Raven and Navi14.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5402>
The app is allowed to never bind descriptor sets that are statically
unused by the pipeline, which would've caused a context fault since
CP_LOAD_STATE6 would try to load the descriptors that don't exist. Fix
this by not preloading descriptors from unused descriptor sets. We could
do more fine-grained accounting of which descriptors are used, but this
is enough to fix the problem.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5400>
Unreal Engine 4 has a bug in usage of glDrawRangeElements,
causing it to be called with a number of vertices in place
of "end" parameter (which specifies the maximum array index
contained in indices).
Since there is unknown amount of games affected and we
could not identify that a game is built with UE4 - we are
forced to make a blanket workaround, disregarding max_index
in range calculations. Fortunately all such calls look like:
glDrawRangeElements(GL_TRIANGLES, 0, 3, 3, ...);
So we are able to narrow down this workaround.
This was uncovered after b684030c3a
broke a bunch of UE4 games.
Cc: 20.1 <mesa-stable@lists.freedesktop.org>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2917
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5203>
Replace the various ad-hoc flushes that we've inserted, copied from
freedreno, etc. with a unified system that uses the user-supplied
information via vkCmdPipelineBarrier() and subpass dependencies.
There are a few notable differences in behavior:
- We now move setting RB_CCU_CNTL up a little in the gmem case, but
hopefully that won't matter too much. This matches what the Vulkan blob
does.
- We properly implement delayed setting of events, completing our
implementaton of events.
- Finally, of course, we should be a lot less flush-happy. We won't emit
useless CCU/cache flushes with multiple copies, renderpasses, etc. that
don't depend on each other, and also won't flush/invalidate the cache
around renderpasses unless we actually need to.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4964>
We just dropped the last user which actually cared about the seqno.
This never worked anyway, since the seqno was never reset between
multiple executions of the same command buffer. Turn the part of the
control buffer which used to track the seqno into a dummy dword, and
figure out automatically whether we need to include it. We will
implement seqnos again eventually, with timline semaphores, but that
will likely be totally different.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4964>
The Vulkan blob doesn't do this, and based on my understanding of how
the blob works this is unnecessary. CACHE_FLUSH is already serialized
against all 3d commands so you don't need to wait for rendering commands
to finish before issuing it, and the subsequent wfi + WAIT_FOR_ME will
cause the CP to wait for the CACHE_FLUSH to finish, so there's also no
need to wait for it to complete. The CACHE_INVALIDATE also seems
unnecessary, and also isn't done by the blob.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4964>
Using arm_test-base as a separate base layer as well for storage &
network bandwidth efficiency.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5381>
NVIDIA hardware doesn't have an equivilant to bfi, but we do already have
a lowering for bitfield_insert->bfi.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5373>
