We continue in the code to do some more things with the rhs, including
setting a constant initializer. If the type is wrong, this causes some
confusion down the line, leading to assertions. This makes sure that the
rhs processing continues to flow as-if the type was correct to start
with (even though the state has been marked as an error state).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101766
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
Vulkan allows you to do a submit whose only job is to wait on and
trigger semaphores. The easiest way for us to support that right
now is to insert a dummy execbuf.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This patch adds an implementation based on DRM BOs. We don't actually
advertise the extension yet because we want to add a couple more paths
first.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
From CL 2.0 Section 5.11 (Event Objects):
clSetEventCallback returns CL_SUCCESS if the function is executed successfully. Otherwise, it
returns one of the following errors:
...
CL_INVALID_VALUE if pfn_event_notify is NULL or if command_exec_callback_type is
not CL_SUBMITTED , CL_RUNNING or CL_COMPLETE .
Fixes: OpenCL CTS test_conformance/events/test_events callbacks
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Changed all register and instruction names, works the same.
v2: Rebase on build system changes (by anholt)
v3: Fix build on clang (by anholt, reported by Rob)
Signed-off-by: Jonas Pfeil <pfeiljonas@gmx.de>
Tested-by: Rob Herring <robh@kernel.org>
If you don't pass this, the compiler refuses to compile the assembly for
pre-v7 CPUs. This also keeps us from building identical, non-NEON code on
aarch64 and x86.
Fixes: a373f77662 ("vc4: Use a wrapper file to set VC4_BUILD_NEON instead of CFLAGS.")
v2: Fix Android build by just appending NEON_C_SOURCES when
ARCH_ARM_HAVE_NEON.
Tested-by: Rob Herring <robh@kernel.org>
We need to link librt for u_thread.h's clock_gettime() call.
Fixes: b822d9dd67 ("gallium/util: move u_queue.{c,h} to src/util")
Reviewed-by: Matt Turner <mattst88@gmail.com>
BLEND_STATE packing was modified to be variable-length in:
9670124e31 genxml: Make BLEND_STATE command support variable length array.
The initial gen10.xml still had the old, fixed-length style
definition for BLEND_STATE. So gen10_upload_blend_state would
overwrite the packed BLEND_STATE_ENTRYs with its own fixed array
of all-zero entries when packing BLEND_STATE. This caused
BLEND_STATE upload to not work at all.
Fixes: aa416f515a ("i965/genxml: Add gen10.xml")
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Gallium drivers use this code path so we need to account for
bindless after all.
Fixes: 365d34540f ("mesa: correctly calculate the storage offset for i915")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
For memobj imports we weren't setting the surface to 0, which
meant sometimes we'd end up with tile_swizzle garbage, which
would corrupt rendering.
This seems to fix the image corruption on the imported memory
objects in vrdashboard for me.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When generating the storage offset for struct members we need
to skip opaque types as they no longer have backing storage.
Fixes: fcbb93e860 ("mesa: stop assigning unused storage for non-bindless opaque types")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101983
Reviewed-by: Dave Airlie <airlied@redhat.com>
When generating the storage offset for struct members we need
to skip opaque types as they no longer have backing storage.
Fixes: fcbb93e860 ("mesa: stop assigning unused storage for non-bindless opaque types")
V2: simplify since bindless will never be supported in this code
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101983
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Rename modifier to be more smart (Jason)
FINISHME: Use the kernel's final choice for the fb modifier
bwidawsk@norris2:~/intel-gfx/kmscube (modifiers $) ~/scripts/measure_bandwidth.sh ./kmscube none
Read bandwidth: 603.91 MiB/s
Write bandwidth: 615.28 MiB/s
bwidawsk@norris2:~/intel-gfx/kmscube (modifiers $) ~/scripts/measure_bandwidth.sh ./kmscube ytile
Read bandwidth: 571.13 MiB/s
Write bandwidth: 555.51 MiB/s
bwidawsk@norris2:~/intel-gfx/kmscube (modifiers $) ~/scripts/measure_bandwidth.sh ./kmscube ccs
Read bandwidth: 259.34 MiB/s
Write bandwidth: 337.83 MiB/s
v2: Move all references to the new fourcc code(s) to this patch.
v3: Rebase, remove Yf_CCS (Daniel)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Instead of always doing a full resolve, only resolve the bits that are
needed. This means that we only do a partial resolve when the miptree
modifier is I915_FORMAT_MOD_Y_TILED_CCS.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
v2: move is_aux into if block. (Jason)
Use else block instead of goto (Jason)
v3: Fix up logic for is_aux (Ben)
Fix up size calculations and add FIXME (Ben)
v4 (Jason Ekstrand):
Use the aux_pitch in the image instead of calculating it
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
This code will disable actually creating these buffers for the scanout,
but it puts the allocation in place.
Primarily this patch is split out for review, it can be squashed in
later if preferred.
v2:
assert(mt->offset == 0) in ccs creation (as requested by Topi)
Remove bogus is_scanout check in miptree_release
v3:
Remove is_scanout assert in intel_miptree_create. It doesn't work with
latest codebase - not sure it ever should have worked.
v4:
assert(mt->last_level == 0) and assert(mt->first_level == 0) in ccs setup
(Topi)
v5 (Jason Ekstrand):
- Base the decision to allocate a CCS on the image modifier
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Previously images did not support any auxiliary compression surfaces
(CCS, MCS, or HiZ). That's about to change. This patch just adds the
fields to __DRIimageRec to make auxiliary surfaces possible.
v2 (Jason Ekstrand):
- Add an aux_pitch parameter as well as aux_offset
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
intel_miptree_texture_aux_usage() takes an isl_format, but we are
passing a mesa_format. clang warns:
brw_blorp.c:305:52: warning: implicit conversion from enumeration
type 'mesa_format' to different enumeration type
'enum isl_format' [-Wenum-conversion]
intel_miptree_texture_aux_usage(brw, src_mt, src_format);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~
Fixes: fc1639e46d ("i965/blorp: Use texture/render_aux_usage for blits")
Cc: "17.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The picture_id was assumed to be a frame number so in 0-31.
But the vaapi client gstreamer-vaapi uses the surfaces handles
as identifier which are unsigned int.
This bug can happen when using a lot of vaapi surfaces within
the same process. Indeed Mesa/st/va increments a counter for the
surface ID: mesa/util/u_handle_table.c::handle_table_add which
starts from 0 and incremented by 1 at each call.
So creating more than 32 surfaces was a problem.
The following bug contains a test that reproduces the problem
by running a couple of vaapih264enc in the same process. The
above also explains why there was no pb when running them in
separated processes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102006
Signed-off-by: Julien Isorce <jisorce@oblong.com>
Tested-by: Tomas Rataj <rataj28@gmail.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-and-tested-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Since we don't iterate to a fixed point, we can end up in situations
where we have a SAT instruction + a long immediate. This is not legal.
However since it's immediately computable, just run unary straight away
to handle the situation.
Fixes: 24a799ad35 ("nv50/ir: fix ConstantFolding with saturation")
Reported-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
While technically correct, this can lead to e.g. getImmediate assuming
that it can walk up the value chain. It could be fixed to not do this,
but it seems easier and less error-prone to just not link the two values
to save on one LValue object.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
otherwise there is corruption in most apps.
Fixes: 0fe0320 radeonsi: use optimal packet order when doing a pipeline sync
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This fixes corrupted shadows in Unigine Valley.
The corruption disappeared when I stopped setting IMG_DATA_FORMAT_24_8
for depth.
Cc: 17.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
When using dmabuf import, make sure that the modifier is actually
allowed to add planes to the base format, as implied by the comment.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Mesa will map user defined vertex input attributes to slots
starting at VERT_ATTRIB_GENERIC0 which gives us room for only 16
slots (up to GL_VERT_ATTRIB_MAX). This sufficient for GL, where
we expose exactly 16 vertex attributes for user defined inputs, but
in Vulkan we can expose up to 28 (which are also mapped from
VERT_ATTRIB_GENERIC0 onwards) so we need to account for this when
we scope the size of the array of attribute workaround flags
that is used during the brw_vertex_workarounds NIR pass. This
prevents out-of-bounds accesses in that array for NIR shaders
that use more than 16 vertex input attributes.
Fixes:
dEQP-VK.pipeline.vertex_input.max_attributes.*
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
The cloning was introduced in f81ede4699 to fix a problem with
shaders including IR that was owned by builtins.
However the approach of cloning the whole function each time we
reference a builtin lead to a significant reduction in the GLSL
IR compilers performance.
The previous patch fixes the ownership problem in a more precise
way. So we can now remove this cloning.
Testing on a Ryzen 7 1800X shows a ~15% decreases in compiling the
Deus Ex: Mankind Divided shaders on radeonsi (which take 5min+ on
some machines). Looking just at the GLSL IR compiler the speed up
is ~40%.
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The main motivation for this is that threaded compilation can fall
over if we were to allocate IR inside constant_expression_value()
when calling it on a builtin. This is because builtins are shared
across the whole OpenGL context.
f81ede4699 worked around the problem by cloning the entire
builtin before constant_expression_value() could be called on
it. However cloning the whole function each time we referenced
it lead to a significant reduction in the GLSL IR compiler
performance. This change along with the following patch
helps fix that performance regression.
Other advantages are that we reduce the number of calls to
ralloc_parent(), and for loop unrolling we free constants after
they are used rather than leaving them hanging around.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
