We've had about 1/day of the texelfetch group in the IRC flake reports
since apr 23, and tex-miplevel-selection that I marked before is actually
all the subtests it looks like. Also, you can't include the ",Fail" if
you want to actually match a test name.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10597>
Since the second source is always a constant that is known to be a
number, this should have the same performance as
GALLIVM_NAN_BEHAVIOR_UNDEFINED.
A lofty goal is to eventually remove GALLIVM_NAN_BEHAVIOR_UNDEFINED.
There's still a lot of (mostly implicit) users, and I don't feel like
tackling that right now. :)
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10532>
If it is known that one of the source must be a number, then the (more
efficient) GALLIVM_NAN_RETURN_OTHER_SECOND_NONNAN path can be used.
v2: s/know to be/known to be/. Noticed by Roland.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10532>
Like softpipe in mesa!10419, llvmpipe suffers from improper handling
of NaN in nir_op_fmax and nir_op_fmin. nir_op_fsat is already handled
correctly. OpenCL strictly requires the "NaN cleansing" behavior, so
all of the functionality is in place. Just make the graphics APIs use
the OpenCL path.
The majority of the possible performance penalty incurred here should
be resolved in the next commit.
v2: Add updated checksum for bgfx/39-assao.rdc trace. Rendering goes
from mostly garbage to looking correct to me.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10532>
I don't know what I was thinking when I wrote 939bf7a419 ("tgsi_exec:
Fix NaN behavior of min and max") and d1c0f62b42 ("tgsi_exec: Fix NaN
behavior of saturate"). I knew that C99 had fmin and fmax... I just
forgot to use them.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10532>
There's a recently discovered HW bug affecting hardware at least as far
back as Skylake where, if the LOD is out-of-bounds for any SIMD lane,
then garbage may be returned in all SIMD lanes. The easy solution is to
set lower_txs_lod so that we always have a constant LOD of 0 which we
know a priori is always in-bounds. Fortunately, not many shaders
actually use textureSize() with LOD.
Shader-db results on Ice Lake:
total instructions in shared programs: 19948537 -> 19948564 (<.01%)
instructions in affected programs: 3859 -> 3886 (0.70%)
helped: 0
HURT: 7
One of the shaders is in Civilization: Beyond Earth, and the rest are
all in Civilization VI.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10538>
The source_depth_to_render_target flag can get set on old gen4-5 HW in a
few cases which are independent of the app writing gl_FragDepth. It
should be safe to just use fetch_payload_reg in that case instead of
depending in interpolation setup. This fixes a bug with certain very
simple shaders where we might end up not including the depth when we
should have.
While we're here, rework the logic around setting src_depth and add a
comment so it's more clear what's going on.
Fixes: 6d4070f3dd "intel/compiler: add support for fragment coordinate..."
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10596>
Somehow this was missed, but when we emit a query start/stop we need
have something that will need to be flushed in the batch.
Detected due to TC assert, but this had the potential to cause problems
in the non-TC case as well.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10599>
Add a helper to both set batch->needs_flush and clear ctx->last_fence so
that the two related bits of state do not get out of sync.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10599>
Declare a meson dependency for libpanfrost and wrap some key functions
within an extern C block allowing proper compilation by C++ compilers.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10462>
We only do it on Android for now, to keep the driver working with older
renderers on X11.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10556>
This also guarantees that physical_dev->extension_spec_versions[X] is
set when extension X is supported.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10556>
Native extensions are those do not require direct renderer support.
Passthrough extensions are those require direct renderer support.
Native extensions usually require translation to other extensions that
the renderer supports.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10556>
Add VN_EXTENSION_TABLE_INDEX for use with VK_ANDROID_native_buffer spec
version override.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10556>
Split up into two functions, one initializes the renderer extension
table and one initializes the supported extension table.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10556>
Mostly docs and cleanups, except that renderer_version is now also
capped by the xml version.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10556>
Add vn_instance::renderer_version to indicate the maximum renderer
instance version we can use internally. It is not all that useful
because we only use 1.1 instance features and VN_MIN_RENDERER_VERSION is
set to 1.1, but whatever.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10556>
Use VN_MAX_API_VERSION for the instance version such that we don't
suddenly advertise 1.3 when the header is updated to 1.3 for example.
Use it to cap the device version as well.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10556>
When we fail, we should not close gem_handle when there is already a bo
with the same gem handle.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10592>
Do not set mmap_size to info.size. We do not track the size of the BO
anymore.
This fixes
dEQP-VK.api.external.memory.dma_buf.suballocated.device_only.fd_properties
where the test allocates a 1KB VkDeviceMemory, export and call
vkGetMemoryFdPropertiesKHR. It can happen that bo->mmap_size is less
than the aligned info.size.
FWIW, the test fails because it violates a VU:
VUID-vkGetMemoryFdPropertiesKHR-fd-00673
fd must be an external memory handle created outside of the Vulkan API
Fixes: 88f481dd74 ("venus: make sure gem_handle and vn_renderer_bo are 1:1")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10592>
It was treated as VK_ERROR_OUT_OF_HOST_MEMORY because
vn_get_intercepted_attachments would return NULL. This fixes various
dEQP tests.
Fixes: 174fca5498 ("venus: handle VK_IMAGE_LAYOUT_PRESENT_SRC_KHR transfer")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10592>
Instead of using a separate outputs array, make the "end" instruction
(or chmask) take the outputs as sources. This works better for the new
RA, because it better models the fact that outputs are consumed all at
the same time. With the old model, each output collect would be assumed
dead after it was processed and subsequent collects could use it when
inserting shuffle code, which wouldn't work, and the new RA also deletes
collect instructions after lowering them to moves so the information
would be gone after RA.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
We need a stable order in order to create phi instructions. In the
future we can make this more sophisticated in order to make manipulating
the CFG easier, but for now that only happens after RA, so we won't have
to worry about it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
Originally I wrote this to support multiple ir3 blocks per NIR block,
but this turned out to be more useful for creating a stable ordering to
the predecessors. We compute the predecessors ourselves, rather than
relying on NIR, so that the array of predecessors we create in the next
commit has a stable order we can rely on when creating phi nodes.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
There's an optimization here to sink direct (i.e. not relative) reads of
an array past unrelated direct writes. However, since each write
actually reads, modifies, and then writes again to the array, this means
that we need to read the latest updated array. The old RA used the array
id instead of the SSA information, so it didn't care, but the new RA
uses ->instr instead and ignores the array id because arrays are now SSA
so it needs to be correct.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
This wasn't using the same calculation that add_reg_dep() was using to
get the index into state->regs, so it was using the wrong register. Fix
this by folding it into add_reg_dep().
This shouldn't fix anything, because it's just used for scheduler
priorities, but it should reduce nop's and syncs.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
a0.x is written as a half-reg, but just interpreting it as "hr61.x" will
result in it overlapping with r30.z in merged mode, which is not what
the hardware does at all. This introduced a spurious dependency on
a write to r30.z which resulted in an assert tripping. Just pretend it's
a full reg instead.
This fixes
spec@arb_tessellation_shader@execution@variable-indexing@vs-output-array-vec3-index-wr-before-tcs
with the new RA.
Fixes: 0f78c32 ("freedreno/ir3: post-RA sched pass")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
Scheduling don't like address being in the different block from
the instruction.
Fixes a crash in the trace of "War Thunder" (DX11)
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10355>
iteration needs to be added to the offset now
Fixes: dae3113c3d ("gallium: split drawid out of pipe_draw_info and as a separate draw_vbo param")
Tested-by: Mark Janes <markjanes@swizzler.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10555>
There were two bugs which crep in here as part of 64551610d1:
forgetting that exec sizes in HW are in log2 space and having the
exec_size condition for the subtype backwards.
Fixes: 64551610d1 "intel/compiler: rework message descriptors..."
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10588>
