If the block in which the jump is inserted is the predecessor of a phi
then we need to remove phi sources otherwise the phi may end up with
things improperly connected. This fixes the following CTS test when
dEQP is run with SPIR-V optimization recipe 1:
dEQP-VK.glsl.functions.control_flow.return_in_nested_loop_vertex
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
(cherry picked from commit bfc89c668e)
For some applications SetCursorPosition
is called when a cursor event is received.
Our SetCursorPosition was always calling
wine SetCursorPos which would trigger
a cursor event.
The infinite loop is avoided by not calling
SetCursorPos when the position hasn't changed.
Found thanks to wine tests.
Fixes irresponsive GUI for some applications.
Fixes: https://github.com/iXit/Mesa-3D/issues/173
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
(cherry picked from commit dcfde02bb0)
Tests done on several devices of all 3 vendors and
of different generations showed that there are several
ways of handling infs and NaN for d3d9.
Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours vary
with shader versions).
Doing this in nine avoids 0*inf issues for drivers
that can't generate 0*inf=0 (which is controled by
TGSI's MUL_ZERO_WINS).
For now clamp for all drivers. An ulterior optimization
would be to avoid clamping for drivers with MUL_ZERO_WINS
for the specific shader versions where NV or AMD don't
clamp.
LOG and RSQ being already clamped, this patch only
clamps RCP.
Fixes: https://github.com/iXit/Mesa-3D/issues/316
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 7ee5e5e239)
A ZPASS_DONE packet doesn't make sense for the compute queue. It will
result in a gpu hang.
This change resolves a gpu hang for SteamVR+Vega.
Cc: mesa-stable@lists.freedesktop.org
Fixes: 1f616a840e "radv: emit a dummy ..."
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit ec1fcf92ae)
NVC0_CB_AUX_BINDLESS_INFO isn't written to on Maxwell+ and it's too small
anyway.
With these changes, TXQ is used to determine the number of samples and
the coordinate adjustment information looked up in a small array in the
driver constant buffer.
v2: rework to use TXQ and a small array instead of a larger array with an
entry for each texture
v3: get rid of the small array and calculate the adjustments in the shader
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Fixes: c2ae9b4052 ('nvc0: implement multisampled images on Maxwell+')
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
(cherry picked from commit b473fcc9a3)
Squashed with:
nv50/ir: fix link-time build failure
Seems this fixes linking problems that occur in some situations.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
(cherry picked from commit 6ca1402c11)
It's just over 10 months since 17.3.0 was released with s3tc support enabled.
Probably a good idea to update the FAQ page.
v2: Incorporate feedback from Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Fixes: 04396a134f ("mesa: Import libtxc_dxtn sources")
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit c95dd966c4)
Corrects building glx as gallium-xlib without any dri targets.
v2: - fix ugly formatting
Fixes: 66c94b9313
("meson: build gallium winsys for dri, null, and wrapper")
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
(cherry picked from commit 5dcb77e491)
SDL has some shaders that compute sin(angle) and cos(angle) for a rotation
matrix in the VS, and angle is usually 0.0. Our previous implementation
had quite a bit of error around 0.0, causing single-pixel rotations at
typical window sizes. SDL2 has changed as of August 28th (commit
12156:e5a666405750) to not need sin/cos in the VS, but we should still fix
this for existing implementations or similar patterns that other programs
may have.
glsl-cos goes from 32 instructions to 36, but 9 uniforms to 7.
glsl-sin goes from 32 instructions to 34, but 8 uniforms to 7.
This seems like a fine impact to have for the bugfix.
Cc: 18.1 18.2 <mesa-stable@lists.freedesktop.org>
Fixes: https://github.com/anholt/mesa/issues/110
(cherry picked from commit 10d5d2d527)
VkPhysicalDeviceProtectedMemoryProperties structure is new on Vulkan 1.1.
Fixes Vulkan CTS CL#2849.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit 59a8e0dbf8)
This was added as part of 1.1 but it's very hard to track exactly what
extension added it. In any case, we should implement it.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Dave Airlie <Airlied@redhat.com>
(cherry picked from commit ab80889e92)
When we're about to re-arrange a bunch of blocks, it's a good idea to
make sure that we don't have deref uses crossing block boundaries.
Otherwise we may end up with a deref going through a phi and that would
be bad.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: "18.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 0796c3934e)
This pass re-materializes deref instructions on a per-block basis to
ensure that every use of a deref occurs in the same block as the
instruction which uses it.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: "18.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 7d1d1208c2)
[Juan A. Suarez: resolve trivial conflicts]
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Conflicts:
src/compiler/nir/nir_deref.c
Squashed with:
nir: add initializer data to fix MSVC compile error
CC: Jason Ekstrand <jason@jlekstrand.net>
Fixes: 82799a5d1b8 ("nir: Add a small pass to rematerialize derefs
per-block")
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
(cherry picked from commit 0c82e3603e)
Missing break; causes parameter checking to
never pass GL_FRAMEBUFFER_FLIP_Y_MESA parameters.
Fixes: 318c265160 ("mesa: GL_MESA_framebuffer_flip_y extension [v4]")
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 60d0c0d062)
Instances where direction was determined based on
winsys or user fbo and should be determined based on
FlipY.
Key STATE_FB_WPOS_Y_TRANSFORM for of FlipY instead of
_mesa_is_user_fbo. This corrects gl_FragCoord usage
when applying GL_MESA_framebuffer_flip_y.
Fixes: ab05dd183c ("i965: implement GL_MESA_framebuffer_flip_y [v3]")
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit ba6cc32cf9)
To get an useful UUID for systems that have a non-useful mtime
for the binaries.
I started using SHA1 to ensure we get reasonable mixing in the
various possibilities and the various build id lengths.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
(cherry picked from commit d17443a459)
Gallium may pick L16A16_FLOAT to represent GL_INTENSITY16F if no intensity
format is provided by the driver. However, when calling
glGetTexLevelParameteriv(..., GL_TEXTURE_INTENSITY_SIZE, ...)
mesa will return a zero size because the actually used format has no
intensity channel and as a fallback only the sizes of the red/green
channels are checked.
Also checking for LA sizes in the allocated texture resolves this problem.
v2: Only check alpha channel size and return it (Marek)
L and A size are always the same in this case.
Fixes (on virgl):
ext_framebuffer_multisample-fast-clear GL_ARB_texture_float *
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107832
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 47e01e77d8)
Each query slot is a uint64_t and we were only zeroing half of it.
Fixes: 7ec6e4e689 "anv/query: implement multiview interactions"
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit 07e214f1ce)
No shader-db changes on any Intel platform... which probably explains
why no bugs have been bisected to this problem since it landed in Mesa
18.1. :( The commit mentioned below is in 18.2, so 18.1 would need a
slightly different fix (due to code refactoring).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes: 77f269bb56 "i965/fs: Refactor propagation of conditional modifiers from compares to adds"
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> (reviewed the original patch)
Cc: Matt Turner <mattst88@gmail.com> (reviewed the original patch)
(cherry picked from commit df9dbc03d3)
When we're mapping temp-resources, we clip the resource to the
transfer-box, which means the stride might not be correct any more.
So let's update the stride from the temp-resource, and recompute the
layer-stride.
This fixes crashes when running dEQP with --deqp-gl-config-name=rgba8888d24s8ms4
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: a8987b88ff "virgl: add driver for virtio-gpu 3D (v2)"
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit fa5e9f1f73)
Those operations do not map to actual hardware instructions, therefore
those should always be lowered to 32-bit instructions.
Fixes: 009c54aa7a "nv50/ir: Split 64-bit integer MAD/MUL operations"
Signed-off-by: Pierre Moreau <pierre.morrow@free.fr>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
(cherry picked from commit 21b92b3464)
If we end up never taking the loop that writes ret, we can end up with
an uninitialized value, and if we're *really* unlucky, that value can
be -1, causing us to go down an error-path instead of a success path.
This was obviously not intended, so let's just initialize this to zero.
Noticed by Valgrind:
Conditional jump or move depends on uninitialised value(s)
at 0xBA640A0: virgl_drm_winsys_resource_cache_create (virgl_drm_winsys.c:348)
by 0xBA62FCF: virgl_buffer_create (virgl_buffer.c:170)
by 0xBA605AC: virgl_resource_create (virgl_resource.c:60)
by 0xBCF816F: bufferobj_data (st_cb_bufferobjects.c:344)
by 0xBCF816F: st_bufferobj_data (st_cb_bufferobjects.c:390)
by 0xBB7E836: vbo_use_buffer_objects (vbo_exec_api.c:1136)
by 0xBCFCC6E: st_create_context_priv (st_context.c:414)
by 0xBCFD3CD: st_create_context (st_context.c:590)
by 0xBBB30CA: st_api_create_context (st_manager.c:896)
by 0xB981E76: dri_create_context (dri_context.c:155)
by 0xB97BDCE: driCreateContextAttribs (dri_util.c:473)
by 0x5288331: dri3_create_context_attribs (dri3_glx.c:309)
by 0x5264D64: glXCreateContextAttribsARB (create_context.c:78)
Fixes: a8987b88ff ("virgl: add driver for virtio-gpu 3D (v2)")
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
(cherry picked from commit eaa718588e)
Apparently for compute there are only 16 instead of the 32 for the
graphics path.
Fixes dEQP-VK.binding_model.descriptorset_random.sets16.noarray.ubolimitlow.sbolimitlow.imglimitlow.noiub.comp.0
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 0dd8189f15)
Fixes the following building error in vc4 build:
In file included from external/mesa/src/gallium/drivers/vc4/kernel/vc4_render_cl.c:34:
In file included from external/mesa/src/gallium/drivers/vc4/kernel/vc4_drv.h:27:
In file included from external/mesa/src/gallium/drivers/vc4/vc4_simulator_validate.h:34:
In file included from external/mesa/src/gallium/drivers/vc4/vc4_context.h:39:
In file included from external/mesa/src/gallium/drivers/vc4/vc4_cl.h:56:
gen/STATIC_LIBRARIES/libmesa_broadcom_genxml_intermediates/broadcom/cle/v3d_packet_v21_pack.h:12:10:
fatal error: 'cle/v3d_packet_helpers.h' file not found
^~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Fixes: 5b102160ae ("broadcom/genxml: Introduce a V3D packet/struct decoder.")
Cc: "18.2" <mesa-stable@lists.freedesktop.org>
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
(cherry picked from commit cc3b99bb48)
Fixes the following building error:
In file included from external/mesa/src/broadcom/cle/v3d_decoder.c:38:
In file included from external/mesa/src/broadcom/cle/v3d_packet_helpers.h:29:
external/mesa/src/gallium/auxiliary/util/u_math.h:42:10:
fatal error: 'pipe/p_compiler.h' file not found
^~~~~~~~~~~~~~~~~~~
1 error generated.
Fixes: 5b102160ae ("broadcom/genxml: Introduce a V3D packet/struct decoder.")
Cc: "18.2" <mesa-stable@lists.freedesktop.org>
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
(cherry picked from commit 9158e0bd82)
Fixes the following building error, happening when building both intel and broadcom:
Gen Header: libmesa_broadcom_genxml_32 <= v3d_packet_v21_pack.h
FAILED: gen/STATIC_LIBRARIES/libmesa_broadcom_genxml_intermediates/broadcom/cle/v3d_packet_v21_pack.h
/bin/bash -c "python external/mesa/src/broadcom/cle/gen_pack_header.py \
external/mesa/src/broadcom/cle/v3d_packet_v21.xml \
> gen/STATIC_LIBRARIES/libmesa_broadcom_genxml_intermediates/broadcom/cle/v3d_packet_v21_pack.h"
Traceback (most recent call last):
File "external/mesa/src/broadcom/cle/gen_pack_header.py", line 626, in <module>
p = Parser(sys.argv[2])
IndexError: list index out of range
header-gen macro is already defined by Intel genxml building rules
and the existing header-gen does not have the $(PRIVATE_VER) argument,
infact the bash command line logged in the building error is missing
exactly $(PRIVATE_VER) argument
Renaming the macro as pack-header-gen in src/broadcom/Android.genxml.mk
solves the building error, another possible way is to keep the gen rules
commands expanded and not use the macros.
Fixes: 7f80a9ff13 ("vc4: Introduce XML-based packet header generation like Intel's.")
Cc: "18.2" <mesa-stable@lists.freedesktop.org>
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
(cherry picked from commit 3341429d74)
When using Freecad, I was getting intermittent segfaults inside of
mesa. I traced it down to this path in st_cb_drawpixels.c where the
result of pipe_transfer_map wasn't being checked. In my case, it was
returning NULL because nouveau_bo_new returned ENOENT. I'm by no
means a mesa developer, but this patch solves the problem for me and
seems reasonable enough.
v2: Marek - also unmap the PBO and release the texture, and call
the make_texture function sooner for less cleanup
Cc: 18.1 18.2 <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 936e0dcd61)
