Would have at least prevented the crash the previous patch fixed.
Cc: 10.4, 10.5 <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=540970
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
(cherry picked from commit ade0b580e7)
When built with Gentoo's package manager, the Mesa source directory
exists seven directories deep. The path to the .test file is too long
and is silently truncated, leading to a crash. Just use PATH_MAX.
Cc: 10.4, 10.5 <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=540970
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
(cherry picked from commit f5e2aa1324)
This fixes piglit when using PIGLIT_PLATFORM=gbm
Tom Stellard:
- Fix ARGB2101010 format
Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
(cherry picked from commit 65c8965d03)
Since commit 28f3f8d, indices generator take a start parameter. However, some
index values have been left to start at 0.
This fixes the glean/fbo test with the virgl driver, and copytexsubimage
with freedreno.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 073a5d2e84)
This is a fix for a regression introduced in commit a9f8296d ("i965/fs:
Preserve the CFG in a few more places.").
The errata this code works around is described in a comment before the function:
"[DevBW, DevCL] Errata: A destination register from a send can not be
used as a destination register until after it has been sourced by an
instruction with a different destination register.
The framebuffer write's sources must be in message registers, which SEND
instructions cannot have as a destination. There's no way for this
errata to affect anything at the end of the program. Just remove the
code.
Cc: 10.4, 10.5 <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84613
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit e214000f25)
This takes "fbo-stencil blit GL_STENCIL_INDEX1/4/16" from crash to pass on
BDW.
Cc: 10.5 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit c4925d7f3b)
Previously, there were bugs where if the app set a scissor it could affect
the area of the texture that was downloaded. There was also potential that
the framebuffer SRGB state could affect downloads. This ensures that those
will get saved/restored and can't affect the texture download.
Cc: 10.5 <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89292
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit b1ab02d9c0)
We could do better by tracking scratch reads and writes.
Cc: 10.5 <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88793
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
(cherry picked from commit da20bf068e)
Previously, we compared our new GS-out VUE map to the existing *VS*-out
VUE map, which is bogus.
This would mostly manifest as redundant dirty flagging where the GS is
in use but the VS and GS output layouts differ; but there is a scary
case where we would fail to flag a GS-out layout change if it happened
to match the VS-out layout.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: "10.5, 10.4" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88885
(cherry picked from commit b51ff50a76)
It appears that all the other instructions that need it already use it.
This one just got missed.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit b8a1637119)
The header is included in ../xmlpool.h. With the latter of which used
directly in a number of places in mesa.
Note that we can also add it (alongside t_option.h) to noinst_HEADERS,
but neither solution fixes the issue that brough us here - namely:
Do not regenerate the headers, if it already exists.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
I.e. add shared-glapi/glapi_mapi_tmp.h to the SOURCES list. Otherwise
there will be no knowledge that the file is required by others for the
build. Thus autotools won't pick it up for the distribution tarball.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Not required. Additionally this had the side effect of generating the
file, despite it's existence.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Some of the files generated were not in the SOURCES variable, thus
although generated prior to compilation the dependency tracking was
incomplete. The latter of which resulted in the files missing from the
distribution tarball.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The file is auto-generated, and #included by formats.c. Let's rename it
to reflect the latter. This will also help up fix the dependency
tracking by adding it to the _SOURCES variable, without the side effect
of it being compiled (twice).
Cc: "10.4, 10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The length argument passed to sysctl was the size of the pointer
not the type. The result of this is sysctl calls would fail on
32 bit BSD/Mac OS X.
Additionally the wrong pointer was passed as an argument to store
the result of the sysctl call.
Cc: "10.4, 10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 7983a3d2e0)
When we schedule an instructions with undefined value, we
eventually will use 0, which is a constant, however sb wasn't
taking this into account and creating ops with illegal scalar
swizzles.
this replaces my fix for op3 in t slots.
Reviewed-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit e8e4437ed0)
Skylake+ doesn't support setting a depth buffer to a 1D surface but it
does allow pretending it's a 2D texture with a height of 1 instead.
This fixes the GL_DEPTH_COMPONENT_* tests of the copyteximage piglit
test (and also seems to avoid a subsequent GPU hang).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89037
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 5b29b2922a)
Nominated-by: Ian Romanick <idr@freedesktop.org>
There were some bugs, and the code was really difficult to follow. We
would optimize
min(max(x, b), 1.0) into max(sat(x), b)
but not pay attention to the order of min/max and also do
max(min(x, b), 1.0) into max(sat(x), b)
Corrects four shaders from Champions of Regnum that do
min(max(x, 1), 10)
and corrects rendering of Mass Effect under VMware Workstation.
Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89180
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit cb25087c7b)
If the renderer supports the core profile the query returned incorrectly
0x8 as value, because it was using (1U << __DRI_API_OPENGL_CORE) for the
returned value.
The same happened with the compatibility profile. It returned 0x1
(1U << __DRI_API_OPENGL) instead of 0x2.
Internal DRI defines:
dri_interface.h: #define __DRI_API_OPENGL 0
dri_interface.h: #define __DRI_API_OPENGL_CORE 3
Those two bits are supposed for internal usage only and should be
translated to GLX_CONTEXT_CORE_PROFILE_BIT_ARB (0x1) for a preferred
core context profile and GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB (0x2)
for a preferred compatibility context profile.
This patch implements the above translation in the glx module.
v2: Fix the incorrect behavior in the glx module
Cc: "10.3 10.4 10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 6d164f65c5)
Corrects the way that _mesa_meta_pbo_TexSubImage and
_mesa_meta_pbo_GetTexSubImage handle 1D_ARRAY textures. Fixes a failure in
the Piglit arb_direct_state_access/gettextureimage-targets test.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Tested-by: Laura Ekstrand <laura@jlekstrand.net>
Cc: "10.4, 10.5" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 546aba143d)
Changes PBO uploads and downloads to use a tall (height * depth) 2D texture
for blitting. This fixes the bug where 2D_ARRAY, 3D, and CUBE_MAP_ARRAY
textures are not properly uploaded and downloaded.
Removes the option to use a 2D ARRAY texture for the PBO during upload and
download. This option didn't work because the miptree couldn't be set up
reliably.
v2: Review from Jason Ekstrand and Neil Roberts:
-Delete the depth parameter from create_texture_for_pbo
-Abandon the option to create a 2D ARRAY texture in create_texture_for_pbo
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Cc: "10.4, 10.5" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit ccc5ce6f72)
This moves the line setting immutability for the texture to after
_mesa_initialize_texture_object so that the initializer function will not
cancel it out. Moreover, because of the ARB_texture_view extension, immutable
textures must have NumLayers > 0, or depth will equal (0-1)=0xFFFFFFFF during
SURFACE_STATE setup, which triggers assertions.
v2: Review from Kenneth Graunke:
- Include more explanation in the commit message.
- Make texture setup bug fixes into a separate patch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Cc: "10.4, 10.5" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 06084652fe)
poc counter should be reset with IDR frame,
otherwise there would be a re-order issue with
frames before and after IDR
v2: add commit message
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 9c7b343bc0)
With earlier commit (install-lib-links: don't depend on .libs directory)
we moved the location of the file from .libs/ to the current dir.
Although we did not attribute that in the former case autotools was
doing us a favour and removing the file. Explicitly remove the file at
clean-local time, otherwise we'll end up with dangling files.
Cc: "10.3 10.4 10.5" <mesa-stable@lists.freedesktop.org>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit fece147be5)
The zoffset and depth values were not being considered when calling
error_check_subtexture_dimensions().
Fixes 2 dEQP tests:
* dEQP-GLES3.functional.negative_api.texture.texsubimage3d_neg_offset
* dEQP-GLES3.functional.negative_api.texture.texsubimage3d_invalid_offset
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.4 10.5" <mesa-stable@lists.freedestkop.org>
(cherry picked from commit 2aa71e9485)
In current code, color format is always hardcoded to
__DRI_IMAGE_FORMAT_ARGB8888 when buffer or DRI image is
allocated in function calls, get_back_bo and dri2_get_buffers,
regardless of current target's color format. This problem
may leads to incorrect render pitch calculation, which
eventually ends up with wrong offset of pixels in
the frame buffer when the image is in different color format
from dri surf's, especially with different bpp. (e.g. RGB565-16bpp)
Attached code patch simply adds RGB565 and XRGB8888 cases to two
functions noted above to resolve the issue.
v2: added a case of XRGB8888, format and bpp selection is done
via switch-case (not "if-else" anymore)
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 1e96eece30)
Broken by a27b74819a.
This fix is critical and should be ported to stable ASAP.
Cc: 10.5 10.4 <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 7820a11e3d)
Squashed with commit
radeonsi: fix a warning caused by previous commit
Cc: 10.5 10.4 <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 050bf75c8b)
It looks like a bug to me.
Cc: 10.5 10.4 10.3 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 0feb0b7373)
This reverts 73c2b0d18c.
It doesn't seem to be reliable. It's probably missing a wait packet or
something, because it's just a register write and doesn't wait for anything.
SURFACE_SYNC at least seems to wait until the flush is done. Just guessing.
Let's not complicate things and revert this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88561
Cc: 10.5 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 7692704b14)
Previously we were using a B/UB source in an Align16 instruction, which
is illegal. It for some reason works on all platforms, except Broadwell.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86811
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit e0137fd6f7)
The saturate propagation pass recognizes that the second instruction
below does not interfere with an attempt to propagate the saturate
modifier from instruction 3 to 1.
1: add(8) dst0 src0 src1
2: mov.sat(8) dst1 dst0
3: mov.sat(8) dst2 dst0
Unfortunately, we did not consider the case of instruction 2 having a
source modifier on dst0. Take for instance:
1: add(8) dst0 src0 src1
2: mov.sat(8) dst1 -dst0
3: mov.sat(8) dst2 dst0
Consider such an instruction to interfere. Increase instruction counts
in Anomaly 2, which could be a bug fix depending on the values the first
instruction produces.
instructions in affected programs: 53228 -> 53934 (1.33%)
HURT: 360
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 7f8dd91d16)
This is safer and matches the conditional_mod propagation pass.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 871ad3f08b)
Use pipe_sampler_view_reference() instead of ordinary assignment.
Also add a new sanity check assertion.
Fixes piglit gl-1.0-drawpixels-color-index test crash. But note
that the test still fails.
Cc: "10.4, 10.5" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
(cherry picked from commit 62a8883f32)
If a fragment program wrote to more than one color buffer, the
first fragment color got replicated to all dest buffers. This
fixes 5 piglit FBO tests, including fbo-drawbuffers-arbfp.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45348
Cc: "10.4, 10.5" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 89c96afe3c)
This snippet can be included in Makefiles that may, depending on the
project configuration, not actually build any installable libraries.
In that case we don't have anything to depend on and this part of
the makefile may be executed before the .libs directory is created,
so do not depend on it being there.
Cc: "10.3 10.4 10.5" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
(cherry picked from commit 5c1aac17ad)
Otherwise for non-default installations the build will fail to find the
headers and error out.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 8a71fd8d49)
