No functional changes - fixes the following assert:
nir_lower_io_impl: Assertion `!(modes & ~supported_modes)' failed.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5997>
We're about to make the SPIR-V -> NIR path generate a bit more complex
SSA chains for certain derefs. This will ensure we don't regress anyone
when we start making vec2's of derefs.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5278>
/glcts --deqp-surface-width=1024 --deqp-surface-height=64 --deqp-case=KHR-GL45.texture_view.view_sampling --deqp-surface-type=fbo
was failing but only for width 1024.
The test was filling a 4x4 ms texture, but leaving the viewport set to 1024x64.
This was resulting in this code incorrectly sign extending a value, and passing
it into the mask generator and getting the wrong values. Explicit cast
avoids the sign extension and fixes the above test.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6006>
tgsi_exec.c uses the generic src load path for indirects, so we don't
actually need addr regs. Saves extra intructions.
shader-db results:
total instructions in shared programs: 3346685 -> 3249052 (-2.92%)
instructions in affected programs: 961832 -> 864199 (-10.15%)
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6018>
The tgsi_exec path can handle it, and otherwise when we start using NIR
our MAX_VARYINGS value will cause us to have VARYING_SLOT_VARx above the
maximum.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6018>
In doing the softpipe NIR and NIR-to-TGSI transition, I want to make sure
I don't make shaders significantly worse, so I need shader-db output.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6018>
This makes us more like other drivers, and avoids having tons of different
names (particularly when you want to dump vs and fs in debugging). In the
process, having a debug flag for vertex shaders just falls out.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6018>
Turning on robust buffer access enables GLES 3.2, also
finished GL 4.3 support.
The post depth coverage fail is expected, it's a test bug
This also introduce a fail in the invalid flag test that I can't reproduce out of CI.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5971>
TGSI expect vec4 of constants for it's current code paths, and when
doing indirect accesses it does the comparison on vec4 indexes,
however NIR does the indexing on packed float indexes.
This also align the compute path with the other shaders, and
should improve robustness (at least under Vulkan)
Fixes:
KHR-NoContext.gl43.robust_buffer_access_behavior.uniform_buffer
v1.1:
rename variable to something more meaningful (Roland)
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5971>
u_screen will return 0 for all of these, which means that this is one
less driver to see in git grep when I'm checking who exposes a cap.
The exception is the texel/gather offsets and stream output
components, which will not be exposed since we don't expose the
corresponding GLSL version.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3298>
u_screen will return 0 for all of these, which means that this is one
less driver to see in git grep when I'm checking who exposes a cap.
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3298>
Since this is a software rasterizer, we really don't care whether the
buffers are "mapped" since it's just malloc. This will drop a bit of
pointless CPU overhead to throw errors.
Reviewed-by: Jan Zielinski <jan.zielinski@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3298>
u_screen will return 0 for all of these, which means that this is one
less driver to see in git grep when I'm checking who exposes a cap.
Reviewed-by: Jan Zielinski <jan.zielinski@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3298>
u_screen will return 0 for all of these, which means that this is one
less driver to see in git grep when I'm checking who exposes a cap.
Reviewed-by Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3298>
Since this is a software rasterizer, we really don't care whether the
buffers are "mapped" since it's just malloc. This will drop a bit of
pointless CPU overhead to throw errors.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3298>
u_screen will return 0 for all of these, which means that this is one
less driver to see in git grep when I'm checking who exposes a cap.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3298>
Since this is a software rasterizer, we really don't care whether the
buffers are "mapped" since it's just malloc. This will drop a bit of
pointless CPU overhead to throw errors.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3298>
u_screen will return 0 for all of these, which means that this is one
less driver to see in git grep when I'm checking who uses a cap.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3298>
- Execute cs_preamble_state as a separate IB with different flags.
- Set the PREEMPT flag for the main IB.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5798>
Copied from PAL. Higher values break tessellation, which I was only able
to reproduce with register shadowing enabled.
Fixes: 0bf3e6fae7 "radeonsi/gfx10: double the number of tessellation offchip buffers per SE"
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5798>
we need to explicitly add the offset in this case since it's not available
as a spirv param
fixes spec@glsl-1.30@execution@fs-texelfetchoffset-2d
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5911>
bit_size of 1 means we use a bool type here, 32 means uint, so we can just
handle that automatically for all relevant cases
ref shaders@glsl-vs-continue-in-switch-in-do-while
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5911>
Has been utilised within nouveau in place of the former M2MF class, which was
dropped for Kepler in PGRAPH in favour of:
- a new P2MF object that only does simple upload; and
- PCOPY took over responsibility of M2MF's other DMA functions.
Autogenerated headers from envytools commit 32659e654170cb03038ccf2cb165decd3a2409d6
NVIDIA documentation released at:
https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/dma-copy/cla0b5.h
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5982>
For implementing panfrost_flush, it suffices to wait on only a single
syncobj, not an entire array of them. This lets us wait on it directly,
without coercing to/from syncfds in the middle (although some complexity
may be added later to support Android winsys).
Further, we should let the fence own the syncobj, tying together the
lifetimes and thus removing the connection between syncobjs and
batch_fence.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5995>
With the current kernel UABI, there is no benefit to explicitly
specifiying dependencies, since the kernel by design adds implicit
dependencies to any referenced BOs. This is something we'd like to
address in the future, but efficient handling with future kernels will
require a tweaked design in userspace as well. So let's do the obvious
thing now, and extend later.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5995>
