Outputs are always considered 32-bits.
Found by inspection.
Cc: 22.3 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19612>
It's pulled too much system dependent headers before this commit
when #include <vulkan/vulkan.h> directly,
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19491>
So include util headers are always using util/ prefix in mesa code base
And prevent including files under src/util without util/ prefix
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19546>
Because these files are accessed in util/format/u_format_*.c
To make sure util are self contained we need move these files
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19547>
Now the idep_mesautilc11 have no need reference when idep_mesautil is referenced
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19526>
With support for MRT in the driver (not included here), passes:
dEQP-GLES31.functional.shaders.builtin_functions.integer.imulextended.int_highp_fragment
dEQP-GLES31.functional.shaders.builtin_functions.integer.umulextended.int_highp_fragment
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19590>
Otherwise the registers "leak", bloating register pressure by
arbitrarily large amounts. This is easy to handle in DCE by rewriting to
a null destination, though we could use a sideband channel if we didn't
want null destinations in the IR.
glmark2 subset of shader-db is much improved:
total instructions in shared programs: 7324 -> 7313 (-0.15%)
instructions in affected programs: 483 -> 472 (-2.28%)
helped: 5
HURT: 2
total bytes in shared programs: 42788 -> 42722 (-0.15%)
bytes in affected programs: 2808 -> 2742 (-2.35%)
helped: 5
HURT: 2
total halfregs in shared programs: 2421 -> 2058 (-14.99%)
halfregs in affected programs: 1235 -> 872 (-29.39%)
helped: 28
HURT: 0
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19590>
Some review feedback of an earlier commit caused me to rearrange some
code quite a bit. I wasn't paying enough attention while applying the
later commits, and these breaks should have been returns. As it is, the
result of the imin or imax analysis is overwritten by the default case
handling... effectively the original commit does nothing. :(
Tiger Lake and Ice Lake had similar results. (Ice Lake shown)
total instructions in shared programs: 19914090 -> 19904772 (-0.05%)
instructions in affected programs: 121258 -> 111940 (-7.68%)
helped: 445 / HURT: 0
total cycles in shared programs: 855291535 -> 855266659 (<.01%)
cycles in affected programs: 2737005 -> 2712129 (-0.91%)
helped: 426 / HURT: 17
LOST: 0
GAINED: 3
Skylake and Broadwell had similar results. (Skylake shown)
total cycles in shared programs: 842395356 -> 842338259 (<.01%)
cycles in affected programs: 5460985 -> 5403888 (-1.05%)
helped: 458 / HURT: 0
Haswell and Ivy Bridge had similar results. (Haswell shown)
total instructions in shared programs: 16710449 -> 16708449 (-0.01%)
instructions in affected programs: 44101 -> 42101 (-4.54%)
helped: 75 / HURT: 0
total cycles in shared programs: 882760230 -> 882727923 (<.01%)
cycles in affected programs: 2867797 -> 2835490 (-1.13%)
helped: 62 / HURT: 10
No shader-db change on any other Intel platform.
No fossil-db changes on any Intel platform.
Fixes: 5ec75ca10d ("intel/compiler: Teach signed integer range analysis about imax and imin")
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19602>
The new nouveau code asks the kernel for supported class,
this needs the new nvif interface, so stub it up using
the old code.
unfortunately this also needs a clang warning turned off
so the gnu extension this code needs is enabled in meson
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Acked-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17633>
Let's get stuff rolling and deal with figuring this out later.
Acked-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17633>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17633>
I somewhat expect this isn't necessary on Volta and newer too, as the
index is coded into shaders now, but, HW doesn't complain, so leave it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17633>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17633>
Important for upcoming kernel changes to more correctly manage the CE
context on Volta and newer, or the channel will be killed in response
to a CTXNOTVALID error from the GPU.
The kernel will have a workaround for Volta and Turing GPUs to preserve
ABI, but will require userspace to behave correctly on Ampere and newer.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17633>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17633>
This can cause us to stomp the contents of r5 before we have a chance to read
it, like this:
0x3d103186bb800000 nop ; nop ; ldvary.r0
0x3d105686bbf40000 nop ; mov rf26, r5 ; ldvary.r1
0x020000ef0000d000 bu.allna 232, r:unif (0x0000001c / 0.000000)
0x3d1096c6bbf40000 nop ; mov rf27, r5 ; ldvary.r2
Here, the MOV in the last instruction is supposed to read r5 produced from
ldvary.r0, but because we have inserted the bu instruction in between now
that read happens at the same time that ldvary.r1 updates r5, stomping the
value we were supposed to read.
Fix this by disallowing injection of a branch instruction in between an ldvary
instruction and its write to the r5 register 2 instructions later.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7062
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19616>
This prevents nir_lower_io_to_temporaries from emitting new writes to the
old globals that we meant to have disappear through
DCE/remove_unused_variables. If you don't do this, then unless you call
nir_opt_undef() and it successfully catches io_to_temps' new writes of
undefs to the scalar components, the scalar vars will stick around and
have stores that conflict with the real vector vars.
This hasn't been a problem for the end result of codegen because
nir_opt_undef() did succeed. However, things went south with vars_to_ssa
mediump lowering, which obscured the result from opt_undef. And, it's
really mind-bending to see undef writes to the outputs for a chunk of the
shader compiler pipeline anyway.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18218>
The back-end swizzles dwords so that our indirect scratch messages match
the memory layout of spill/fill messages for better cache coherency.
The swizzle happens at a DWORD granularity. If a read or write crosses
a DWORD boundary, the first bit will get correctly swizzled but whatever
piece lands in the next dword will not because the scatter instructions
assume sequential addresses for all bytes. For DWORD writes, this is
handled naturally as part of scalarizing. For smaller writes, we need
to be sure that a single write never escapes a dword.
Fixes: fd04f858b0 ("intel/nir: Don't try to emit vector load_scratch instructions")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7364
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19580>
Because dup_mem_intrinsic() retains the SSA offset from the original
intrinsic and only modifies it by adding a constant, we can compute the
alignment based on the original alignment and the constant offset. This
is both easier and more accurate.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19580>
If an application was transitioning out of fullscreen exclusive
display mode, the wsi_display_connector->active state was not
reset in vkReleaseDisplay() from fullscreen. When the app then
later tried to go to fullscreen display mode again on the same
display output with the same video mode, this caused
_wsi_display_queue_next() to skip a required drmModeSetCrtc()
during the first vkQueuePresent() after entering direct display
mode.
While this often worked by pure luck on a single-display setup,
it goes sideways on a multi-display setup where the viewport
of the associated crtc does not have a (x,y) offset of (0,0).
E.g., XOrg/X11 RandR output leasing of an output whose viewport
starts at x = 1920:
1. X-Server has RandR outputs viewport at x = 1920, in a shared
framebuffer, shared across all crtc's on a X-Screen.
2. Application leases that output for direct display mode,
1st vkQueuePresent() triggers drmModeSetCrtc() of output
to (x,y) = 0,0, as required for Vulkan/wsi/direct framebuffer
setup.
3. Application does rendering and presenting.
4. Application vkReleaseDisplay() the output, terminates the
RandR lease. X-Server takes over again.
5. X-Server modesets to reconfigure output back to viewport
with (x,y) = 1920, 0.
6. Application leases same output again later on, and tries
vkQueuePresent() again. Because of the bug fixed in this
commit, the required drmModeSetCrtc() to (x,y) = 0,0 is
erroneously skipped due to the stale cached connector state.
7. drmModePageflip() fails due to the wrong crtc viewport
(x,y) = 1920, 0, mismatched for the need of the Vulkan
framebuffer of (x,y) = 0,0. Kernel returns -ENOSPACE,
Swapchain goes into permanent VK_ERROR_SURFACE_LOST state.
Destroying and recreating the swapchain, as recommended
by the Vulkan spec for error handling won't help. Game over!
Resetting wsi_display_connector->active = false; fixes the
problem of wrong / stale connector state and Vulkan/wsi/display
clients are happy on multi-display setups again, as tested
in various single- and multi-display configurations.
This bug affects all Mesa releases with Vulkan/WSI/Display
support and should therefore be backported.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Fixes: 352d320a07 ("vulkan: Add EXT_direct_mode_display [v2]")
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19484>
Karol Herbst
Samuel Pitoiset
Yonggang Luo
Alyssa Rosenzweig
Alyssa Rosenzweig
Timothy Arceri
Eric Engestrom
Emma Anholt
Ian Romanick
Dave Airlie
Ben Skeggs
Iago Toral Quiroga
Jason Ekstrand
Mario Kleiner