these shouldn't result in any sort of draw, and passing the unsupported primtype
to the driver is invalid
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13845>
For historical reasons, we ingest 1-bit booleans in NIR but expand them
to 16/32-bit booleans in the backend IR. We need to handle this case
when loading boolean constants, extending from 1-bit to 16/32-bit as
required. This issue is masked by effective constant folding for
booleans, but is visible in a shader from Firefox WebRender.
Fixes: 646e03c451 ("pan/bi: Temporarily switch back to 0/~0 bools")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Icecream95
Closes: #5797
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14371>
Instead of emitting a pile of moves to fixed registers at codegen time
and hoping everything works out, add a second staging source to the
BLEND instruction in the intermediate representation containing the dual
source colour, and modify register allocation appropriately. This better
models the operation of blending render target #0 with two sources.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13714>
Extend store_combined_output_pan to take a dual source blend input in
addition to colour, depth, and stencil inputs. Use the last source for
this, and represent the type with the DEST_TYPE index. This is a hack
but there is no SRC2_TYPE and NIR doesn't seem to mind as long as we
know what we mean. This allows the backend to emit a combined "blend
render target #0" instruction taking two sources.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13714>
Combine depth/stencil writeout redundancy. This simplifies the code and
will allow us to add dual source blend handling without duplicating even
more code.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13714>
`base` is meaningless for combined stores, so don't read it. This allows
us to remove the base index from the intrinsic and simplify the lowering
code generating the combined store intrinsic.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13714>
`base` is meaningless for combined stores, so don't read it. This allows
us to remove the base index from the intrinsic and simplify the lowering
code generating the combined store intrinsic.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13714>
This make things all fall back to the common synchronization functions
which will switch things to the new submission path and to use
vk_fence and vk_semaphore.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
radv: Use common AcquireNextImage2KHR.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
radv: Use common functions for Metro Exodus layer.
Needs to be squashed with the big "switch the world" deletion patch
but kept it separate for review.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13974>
Basically just a copy of radv's internal deferred submission handler.
This uses the new winsys submit2 to later be able to move the sem_info
to the winsys.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13974>
We basically use 2 types for amdgpu:
1) syncobj. This supports both binary & timeline and autodetects
all the features.
2) emulated timelines if (1) doesn't detect timeline syncobj support.
Note that one has to put these in order of preference so that the
common CreateFence/CreateSemaphore functions decide on the right
type.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13974>
For getting the fd from the device.
This uses the new function introduced with libdrm 2.4.109. This has
already been updated in CI and is already required for mesa common
bits so requiring it for libdrm_amdgpu is no big deal.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13974>
We don't plan to support NV_mesh_shader officially on RADV,
because it performs poorly on AMD hardware. However, we are
implementing this extension to get some experience with mesh
shader technology.
Users should not rely on this support because we are going
to remove it if/when a potential cross-vendor extension appears.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13580>
The NV indirect command buffer format is not supported by
the hardware, so we have to emit several copy packets to
make it work.
Otherwise it works by emulating the number of launched
MS workgroups by setting the number of "input vertices".
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13580>
