commit 03dd9a88b0 introduced per surface
queues, but the display_sync for swrast_commit_backbuffer remained on
the old queue. This is likely to break when dispatching the correct
queue at the top of function (which can't dispatch the sync callback
we're waiting for).
The easiest known reproduction case is running weston-subsurfaces under
weston --use-pixman
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
(cherry picked from commit aa18a63512)
When creating a image from a texture, the image's dri_format is
set to the first plane's format, and used to look up for the
fourcc. e.g. for FOURCC_NV12 texture, the dri_format is set to
__DRI_IMAGE_FORMAT_R8, we end up with a wrong entry in function
intel_lookup_fourcc():
{ __DRI_IMAGE_FOURCC_R8, __DRI_IMAGE_COMPONENTS_R, 1,
{ { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 }, } },
instead of the correct one:
{ __DRI_IMAGE_FOURCC_NV12, __DRI_IMAGE_COMPONENTS_Y_UV, 2,
{ { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
{ 1, 1, 1, __DRI_IMAGE_FORMAT_GR88, 2 } } },
as a result, a wrong fourcc __DRI_IMAGE_FOURCC_R8 was returned.
To fix this bug, the image inherits the texture's planar_format that
has the original fourcc; Upon querying, if planar_format is set,
return the saved fourcc; Otherwise fall back to the old way.
v3: add a bug description and "cc mesa-stable" tag (Jason)
remove redundant null pointer check (Tapani)
squash 2 patches into one (James)
v2: fall back to intel_lookup_fourcc() when planar_format is NULL
(Dongwon & Matt Roper)
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Xiong, James <james.xiong@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
(cherry picked from commit f23b45dce3)
Scratch registers are reused every instructions.
Since vFace is reused, a new temporary register
should be used.
Fixes: https://github.com/iXit/Mesa-3D/issues/311
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: "17.3 18.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit d899826733)
The lighting constants were not declared previously,
but were accessed with indirect addressing, which is
illegal.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105442
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
CC: "17.3 18.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 39240926cd)
From the SPIR-V spec, OpTypeImage:
"Depth is whether or not this image is a depth image. (Note that
whether or not depth comparisons are actually done is a property of
the sampling opcode, not of this type declaration.)"
The sampling opcodes that specify depth comparisons are
OpImageSample{Proj}Dref{Explicit,Implicit}Lod, so we should set
is_shadow only for these (we were using the deph property of the
image until now).
v2:
- Do the same for OpImageDrefGather.
- Set is_shadow to false if the sampling opcode is not one of these (Jason)
- Reuse an existing switch statement instead of adding a new one (Jason)
Fixes crashes in:
dEQP-VK.spirv_assembly.instruction.graphics.image_sampler.depth_property.*
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 41ac0b1443)
Gen8+ use 48-bit address relocations so need to extend the sign
to 64-bit return value. Without it we have higher bits zeroed
and missing the negavive values.
Haswell and older use 32-bit deltas so are unaffected by this issue.
v2:
used int32_t fucntion parameter instead of explicit type conversion.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
Signed-off-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Tested-by: Andriy Khulap <andriy.khulap@globallogic.com>
Tested-by: Stuart Young <cefiar@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "18.0 17.3" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 98b860e311)
Buffers can be large, so we probably don't want to make them all 32x
bigger. But they can't be rendered to (at least in GL) so we don't
need this workaround to prevent page faults on mem<->gmem.
Cc: "18.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
(cherry picked from commit 2f175bfe5d)
We could alternatively fall back to using "old style" draw's for
mem<->gmem (ie. what <= a4xx do) when height is not aligned to 32,
but that is somewhat more work (and not really something that could
be applied to stable)
Cc: "18.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
(cherry picked from commit 1866f76f7b)
This fixes the fs-interpolateAtCentroid-block-array piglit test on i965.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 6018f5b079)
Found running "The Witness" in Wine. Without this patch, texture views created
on multi-sample textures would have a GL_TEXTURE_SAMPLES of 0. All things
considered such views actually work surprisingly well, but when combined with
(plain) multi-sample textures in a framebuffer object, the resulting FBO is
incomplete because the sample counts don't match.
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Henri Verbeet <hverbeet@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 0b73c86b80)
This is supposed to have both BASE and COMPONENT but num_indices was
inadvertantly set to 1.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit cc3a88e81d)
A recent commit (see below) triggered some cases where conditional
modifier propagation and dead code elimination would cause a MAD
instruction like the following to be generated:
mad.l.f0 null, ...
Matt pointed out that fs_visitor::fixup_3src_null_dest() fixes cases
like this in the scalar backend. This commit basically ports that code
to the vec4 backend.
NOTE: I have sent a couple tests to the piglit list that reproduce this
bug *without* the commit mentioned below. This commit fixes those
tests.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Fixes: ee63933a7 ("nir: Distribute binary operations with constants into bcsel")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105704
(cherry picked from commit 91225cb33f)
Cc: Maxin B. John <maxin.john@gmail.com>
Cc: Khem Raj <raj.khem@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Suggested-by: Jon Turney <jon.turney@dronecode.org.uk>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Cc: <mesa-stable@lists.freedesktop.org>
(cherry picked from commit cbee1bfb34)
[Juan A. Suarez: resolve trivial conflicts]
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Conflicts:
meson.build
Squashed with:
configure: use AC_CHECK_HEADERS to check for endian.h
The currently we use the singular CHECK_HEADER combined with explicit
append to the DEFINES variable. That is a legacy misnomer, since it
requires us to add $DEFINES to every piece that we build.
Using the plural version of the helper sets the HAVE_ macro for us, plus
ensures it's passed to the compiler - if config.h is available in there
(not in the case of mesa) otherwise on the command line.
In hindsight, we should replace all the AC_CHECK_{FUNC,HEADER} instances
with the plural version (or even the _ONCE suffixed version) and drop
the DEFINES hacks.
Fixes: cbee1bfb34 ("meson/configure: detect endian.h instead of trying
to guess when it's available")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105717
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Eric Engestrom <eric.engestrom@imgtec.com>
Tested-by: Clayton Craft <clayton.a.craft@intel.com>
(cherry picked from commit 5a75019ad0)
On the CI family, firmware requires the destory command have to be the
last command in the IB, moving feedback command after destroy is causing
issues on CI cards, so we have to keep the previous logic that moves
destroy back to the last command.
But as the original issue fixed previously, with the newer family like Vega10,
feedback command have to be included inside of the task info command along
with destroy command.
Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
Signed-off-by: Leo Liu <leo.liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit c4de2f0880)
There was a missing absolute value when
checking if the determinant was big enough.
Fixes: https://github.com/iXit/Mesa-3D/issues/292
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
CC: "17.3 18.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit dbc24835d7)
Stateblocks with NINESBT_ALL should track all textures.
For better performance they have a faster path which
copies all the required.
This path was only tracking ps textures.
Fixes: https://github.com/iXit/Mesa-3D/issues/303
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
CC: "17.3 18.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 71eae7940e)
Add support for GL_NUM_SHADING_LANGUAGE_VERSIONS
and glGetStringi for GL_SHADING_LANGUAGE_VERSION
v2:
- Combine similar functionality into
_mesa_get_shading_language_version() function.
- Change GLSL version return mechanism.
v3:
- Add return of empty string for GLSL ver 1.10.
- Move _mesa_get_shading_language_version() function
to src/mesa/main/version.c.
v4:
- Add OpenGL version check.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104915
Signed-off-by: Andriy Khulap <andriy.khulap@globallogic.com>
Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit a553c54abf)
We only have a cfg != NULL if we went through one of the paths that set
it, but my compiler doesn't figure that out.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 6411defdcd ("intel/cs: Re-run final NIR optimizations for each SIMD size")
(cherry picked from commit d25640c3a3)
If a shader does a tcs store with an indirect access, we
were only marking the first spot as used. For indirect access
we always now mark all slots used by the variable.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105464
Fixes: 94f9591995 (radv/ac: add support for TCS/TES inputs/outputs.)
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 27a5e5366e)
Emil Velikov: move hunks {radv,ac}_nir_to_llvm.c]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Conflicts:
src/amd/vulkan/radv_nir_to_llvm.c
I was going to have to add another parameter to this monster,
so we should just pass the nir_variable in, I can't find any
reason this would be a bad idea.
This needed for the next fix.
Fixes: 94f9591995 (radv/ac: add support for TCS/TES inputs/outputs.)
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 4f0c89d66c)
[Emil Velikov: move hunk {radv,ac}_nir_to_llvm.c]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Conflicts:
src/amd/common/ac_nir_to_llvm.c
src/amd/common/ac_shader_abi.h
src/amd/vulkan/radv_nir_to_llvm.c
This seems more correct to me, since if we have an array
of floats they'll be vec4 aligned, and if we do af[2],
we want the const index to increase by 2 slots in the non
compact case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105464
Fixes: 94f9591995 (radv/ac: add support for TCS/TES inputs/outputs.)
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit f9de2d409b)
[Emil Velikov: hunk belongs to another file {radv,ac}_nir_to_llvm.c]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Conflicts:
src/amd/vulkan/radv_nir_to_llvm.c
This is a terrible hack but it fixes CTS regressions. It's still
incredibly unclear exactly what is going wrong in the hardware to cause
this to be an issue so this isn't a good fix by any means. However, it
does fix tests so there is that.
Fixes: fb0e9b5197 "i965: Track the depth and render caches separately"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103746
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 8379bff6c4)
This is required to build wine with the nine patchset
Fixes: 6b4c7047d5
("meson: build gallium nine state_tracker")
Reported-by: Mike Lothian <mike@fireburn.co.uk>
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
(cherry picked from commit b7c6870f87)
With some sets of optimization flags, GCC will generate warnings like
this:
src/mesa/main/texparam.c:2327:27: warning: ‘*((void *)&ip+12)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
params[3] = ip[3];
~~^~~
src/mesa/main/texparam.c:2320:16: note: ‘*((void *)&ip+12)’ was declared here
GLint ip[4];
^~
ip is not initialized in cases where a GL error is generated. In these
cases, we should *not* write to the user's buffer, so this is actually a
bug. I wrote a new piglit test gl-3.0-texparameteri to show this bug.
I suspect that Coverity also detected this, but the scan site is
currently down.
Fixes: c2c507786 "main: Added entry points for glGetTextureParameteriv, Iiv, and Iuiv."
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit def0030e64)
Tested by our OpenCL team.
Fixes: 9c499e6759 "st/mesa: don't invoke st_finalize_texture & st_convert_sampler for TBOs"
Acked-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit db495b8962)
Otherwise SWR cannot be built with meson from an autotools generated
tarball, such as the 18.0.0-rc4 tarball.
Fixes: 16bf813830 ("meson/swr: re-shuffle generated files")
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: George Kyriazis <george.kyriazis@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 7258be91c5)
In 16631ca30e we fixed gen9 active components to account for padded
inputs in the URB, which we can have with SSO programs. To do that,
instead of going through the bitfield of inputs (which doesn't include
padding information), we compute the number of inputs from the size
of the URB entry.
Unfortunately, there are some special inputs that are not stored in
the URB and that we also need to account for. These special inputs
are identified and handled during calculate_attr_overrides().
Instead of keeping track of the exact number of inputs, we just
program active components for all possible inputs like we do in
anvil.
This fixes a regression in a WebGL program that uses Point Sprite
functionality (specifically, VARYING_SLOT_PNTC).
v2:
- Add 'Fixes' tag (Mark Janes)
- make no_vue_inputs int instead of uint32_t, and add const qualifier
to num_inputs variable (Ian)
v3:
- Do not try to count inputs correctly, just program all input
slots like we do in anvil (Ken)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105224
Fixes: 16631ca30e (i965/sbe: fix active components for SSO programs with over 16 inputs)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit bc73016703)
Nothing to do except using a busy wait loop. At least for old kernels.
A better implementation for newer kernels to come later.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105255
Fixes: f4e499ec79 "radv: add initial non-conformant radv vulkan driver"
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 2a404c6f92)
When looking up known glsl_type instances in the various hash tables, we
end up leaking the key instances used for the lookup, as the glsl_type
constructor allocates memory on the global mem_ctx. This patch changes
glsl_type to manage its own memory, which fixes the leak and also allows
getting rid of the global mem_ctx and its mutex.
v2: remove lambda usage (Tapani)
(+keep ASSERT_BITFIELD_SIZE, modify dummy ctor to initialize mem_ctx)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104884
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Simon Hausmann <simon.hausmann@qt.io>
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit fb5825e7ce)
Commit bit in the message descriptor (Bit 13) must be always set
to true in CNL+ for memory fence messages. It also fixes a piglit
GPU hang on cnl+ in simulation environment.
Piglit test: arb_shader_image_load_store-shader-mem-barrier
See HSD ES # 1404612949
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
(cherry picked from commit 56dc9f9f49)
This is just useless for two reasons:
1) flush_bits is not set accordingly, so nothing will be flushed
in BeginQuery().
2) we always flush caches in EndCommandBuffer(), so if a reset
is done in a previous command buffer we are safe.
Cc: "18.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Alex Smith <asmith@feralinteractive.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit c133a3411b)
This fixes some hangs seen where the recip_ieee opcodes would
end up split across the wrong slots.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit bf2af063c3)
This gives the scheduler visibility into the headers which should
improve scheduling. More importantly, however, it lets the scheduler
know that the header gets written. As-is, the scheduler thinks that a
texture instruction only reads it's payload and is unaware that it may
write to the first register so it may reorder it with respect to a read
from that register. This is causing issues in a couple of Dota 2 vertex
shaders.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104923
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
(cherry picked from commit ff4726077d)
This reverts commit f314a532fd.
This appears to introduce some blinking textures in UT2004. Not
sure exactly what's the root cause because we don't have much
information about the issue.
Anyway, this was just a micro optimization that actually breaks,
at least, one app almost one year later.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105436
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
(cherry picked from commit f02f1ad13f)
From the spec:
"When copying between compressed and uncompressed formats the
extent members represent the texel dimensions of the source
image and not the destination."
However, as per 7b890a36, we must still use the destination image type
when clamping the extent so that we copy the correct number of layers
for 2D to 3D copies.
Fixes: 7b890a36 "radv: Fix vkCmdCopyImage for 2d slices into 3d Images"
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Alex Smith <asmith@feralinteractive.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit fcf267ba08)
The vulkan API is not ideal as it does not allow us have a
shared limit.
Feral needs 15+6 for one of their games, and I'm not a fan
of overcommitting the limits, so increase the number of
dynamic uniform buffers to 16.
CC: <mesa-stable@lists.freedesktop.org>
CC: Alex Smith <asmith@feralinteractive.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 997306c031)
This is ported from the sb backend, there are some issues with
evergreen stacks on the boundary between entries and ALU_PUSH_BEFORE
instructions.
Whenever we are going to use a push before, we check the stack
usage and if we have to use the workaround, then we switch to
a separate push.
I noticed this problem dealing with some of the soft fp64 shaders,
in nosb mode, they are quite stack happy.
This fixes all the glitches and inconsistencies I've seen with them
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Tested-by: Elie Tournier <elie.tournier@collabora.com>
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 5d4fbc2b54)
Ken suggested that we might be underallocating scratch space on HD
400. Allocating scratch space as though there was actually 8 EUs
seems to help with a GPU hang seen on synmark CSDof.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 24b415270f)
Ken suggested that we might be underallocating scratch space on HD
400. Allocating scratch space as though there was actually 8 EUs
seems to help with a GPU hang seen on synmark CSDof.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104636
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105290
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Eero Tamminen <eero.t.tamminen@intel.com>
(cherry picked from commit 06e3bd02c0)
