src1 exists, and must be set to ZERO. If we don't add this source,
lane2 refers to src2 which does not exists.
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/7472>
Now that we lower uniforms to UBO we can get rid of bi_emit_ld_uniform().
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/7472>
The number of src swizzle to initialize depends on the number of source
properties (size and number of components) not the destination ones.
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/7472>
So we can extend bi_emit_ld_vary() to support centroid and sample modes.
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/7472>
If we don't do that, pixels might be killed early thus preventing the
fragment shader from being called and updating the depth/stencil value.
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/7501>
Currently dpb_size for VP9 profile0 and profile2 is same eventhough
for profile2 dpb_size is multiplied by extra 3/2 and we are
seeing VM_L2_PROTECTION_FAULT error and ring vcn_dec timeout because
of less dpb_size for VP9_2.
This patch will correct dpb_size for VP9_2 and fixes the issue.
Signed-off-by: SureshGuttula <suresh.guttula@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7480>
Intel hardware supports 8-bit arithmetic but it's tricky and annoying:
- Byte operations don't actually execute with a byte type. The
execution type for byte operations is actually word. (I don't know
if this has implications for the HW implementation. Probably?)
- Destinations are required to be strided out to at least the
execution type size. This means that B-type operations always have
a stride of at least 2. This means wreaks havoc on the back-end in
multiple ways.
- Thanks to the strided destination, we don't actually save register
space by storing things in bytes. We could, in theory, interleave
two byte values into a single 2B-strided register but that's both a
pain for RA and would lead to piles of false dependencies pre-Gen12
and on Gen12+, we'd need some significant improvements to the SWSB
pass.
- Also thanks to the strided destination, all byte writes are treated
as partial writes by the back-end and we don't know how to copy-prop
them.
- On Gen11, they added a new hardware restriction that byte types
aren't allowed in the 2nd and 3rd sources of instructions. This
means that we have to emit B->W conversions all over to resolve
things. If we emit said conversions in NIR, instead, there's a
chance NIR can get rid of some of them for us.
We can get rid of a lot of this pain by just asking NIR to get rid of
8-bit arithmetic for us. It may lead to a few more conversions in some
cases but having back-end copy-prop actually work is probably a bigger
bonus. There is still a bit we have to handle in the back-end. In
particular, basic MOVs and conversions because 8-bit load/store ops
still require 8-bit types.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7482>
We can't really support these directly on any platform. May as well let
NIR lower them. The NIR lowering is potentially one more instruction
for scan/reduce ops thanks to not being able to do the B->W conversion
as part of SEL_EXEC. For imax/imin exclusive scan, it's yet another
instruction thanks to the extra imax/imin NIR has to insert to deal with
the fact that the first live channel will contain the identity value
which, when signed, will cast wrong. However, it does let us drop some
complexity from our back-end so it's probably worth it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7482>
Some ALU ops (comparisons being the primary example) have a fixed
bit-size destination and, in that case, we don't want to insert a
conversion on the destination.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7482>
The extension is only exposed on ACO and LLVM 11+ because of a LLVM bug.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7234>
64-bit image atomics only work with LLVM 11+ because of a LLVM bug.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7234>
The fmul operation takes the maximum number of components from either
of its operands. We only need to use 2 components from the fragment
coordinates.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7507>
We forgot to initialize the sample_count member here, leading to it
being undefined. This causes problems on MSVC when compiling in
debug-mode, where we get a run-time error for using an undefined
variable.
To avoid similar problems in the future if more fields are added,
let's initialize the whole struct to zero to start with. This also
allows us to remove a no-longer-needed zero-initialization.
Fixes: cf170616da ("gallium: Add a util_blitter path for using a custom VS and FS.")
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7503>
GLSL requires that image atomics have formats and there are rules about
things matching properly. We should enforce those in NIR unless we have
reason to do otherwise.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7509>
While we do need *some* fallback-driver, there's no good reason to
*always* require that to be Softpipe. LLVMpipe for instance does the job
just fine.
This makes the minimal build a bit smaller on Windows.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7506>
For some unknown reason, both RK3288 Chromebooks went catatonic over the
weekend. Disable them until we can get them fixed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7508>
Issue: Encoding parameters not updated after changing FrameRate
Root Cause:
In radeon_enc_begin_frame, there is a parameter need_rate_control
which was enabled only if the bitrate is changed. Due to this the
radeon_enc_rc_layer_init was not updating the encoder parameters with new
framerate, peak_bits_per_picture_integer and avg_target_bits_per_picture
Fix:
Added the condition where we will check if there is a change in
other parameters and enable rate control. Eventually updating the
encoder parameters with new framerate and bitrate.
Signed-off-by: Krunal Patel <krunalkumarmukeshkumar.patel@amd.corp-partner.google.com>
Reviewed-by: Boyuan Zhang boyuan.zhang@amd.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7363>
When calling GetPhysicalDeviceProperties2 we were ignoring and logging
the structures for extensions not supported. But for the case of
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PCI_BUS_INFO_PROPERTIES_EXT we
already know that we are not going to support it, so let's just do
nothing (not even logging) when passed.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7497>
We already have vk_error to report errors, they add little specific
v3dv wrapping over a simple fprintf, and they are not used really
often.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7497>
Otherwise FMASK metadata segfaults and on import we disable it ...
CC: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7358>
we don't currently do anything special with any of these, so it'd be better
to not have the same code copy/pasted around
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7485>
vkGetPhysicalDeviceFeatures2 and vkGetPhysicalDeviceProperties2 are not present on some MoltenVK versions.
VK_KHR_get_physical_device_properties2 exposes the KHR versions of the same functions.
These cannot be used via static linking, so we have to dynamically detect the loader version and then the extension
to work out which pointers to use.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7447>
If we don't have a non-visible VRAM heap, we should be counting
our non-visible VRAM allocations to the visible-VRAM heap.
CC: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6827>
When I enable "Above 4G decoding" in my BIOS I still get 16 MiB of
non-visible VRAM on my 8G VRAM GPU ...
CC: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6827>
Boris Brezillon
SureshGuttula
Jason Ekstrand
Rhys Perry
Louis-Francis Ratté-Boulianne
Erik Faye-Lund
Samuel Pitoiset
Alyssa Rosenzweig
Daniel Stone
Krunal Patel
Alejandro Piñeiro
Bas Nieuwenhuizen
Mike Blumenkrantz
Duncan Hopkins
Dylan Baker