This will be used for representing gl_FragCoord in NIR and reducing
payload registers pushed.
HSW results:
total instructions in shared programs: 9940636 -> 9948574 (0.08%)
instructions in affected programs: 852560 -> 860498 (0.93%)
total cycles in shared programs: 314804525 -> 314900080 (0.03%)
cycles in affected programs: 39786599 -> 39882154 (0.24%)
LOST: 5
GAINED: 11
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25190>
This was leftover dead code from 4bb6e6817e ("intel: Use a system value
for gl_FragCoord") -- the sysval doesn't do any interpolation and doesn't
have sources that could use a barycentric.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25190>
This generates one extra instruction to set the rounding mode to RTE due
to f2f16_rtne in the lowering. This changes the result for
fquantize2f16(65505.0) from 65536 to 65504, which fixes SPIR-V
conformance for this value:
If Value is positive with a magnitude too large to represent as a
16-bit floating-point value, the result is positive infinity. If Value
is negative with a magnitude too large to represent as a 16-bit
floating-point value, the result is negative infinity.
SPIR-V doesn't specify whether this overflow check is before or after
rounding, but IEEE specifies rounding first, which is what produces our
65504.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25552>
There's no need for a per driver HMI implementation since the
vk_icdGetInstanceProcAddr implementation can well populate the required
entrypoints for Android icd.
Changes have to be done in this single commit for simplicity. Otherwise,
I would have to create a separate android shared library in the runtime
like how vk_instance is handled today, so that the target is able to
check per driver enablement def. However, after all drivers have
migrated over within this MR, we still have to clean those up. So I
decided to just do those in a single commit instead.
v2: avoid preloading u_gralloc in vulkan hal open
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v1)
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Drop explicit u_gralloc init since it will be initialized upon the
initial vk_android_get_ugralloc.
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
u_gralloc will be initialized upon the initial vk_android_get_ugralloc.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
u_gralloc will be initialized upon the initial vk_android_get_ugralloc.
v2: drop explicit gralloc init
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v1)
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Initialize u_gralloc once upon the initial init or get call. We'll skip
updating the backend drivers for this since most usages will be cleaned
up later.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
...to avoid mixing up with type name and local returns from getter.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
I'm seeing crash reports from the wild where it's not necessarily clear why
something failed, and it'd be nice to have the PSO desc on the stack when
something failed. It ends up being fatal anyway (we don't gracefully drop
draw calls, and I don't think we should).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35614>
Technically this won't produce valid results, but it will at least compile and
will probably be good enough, which is better than where we are right now,
which is that shaders fail to validate.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35614>
u_blitter sets a viewport transform with depth range [-1,1], which is
outside the [0,1] range that is allowed by opengl.
The mali hardware docs state that setting the LOW_DEPTH_CLAMP register
outside of [0,1] is undefined behavior. We haven't observed any problems
with this so far, but better to fix it.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Fixes: 810135fb42 ("gallium/u_blitter: Fix depth.")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35225>
We are reading accel header parameter those are updated by CS, so we
need to apply flushes to make L3 coherent with CS.
This fixes ray query tests on MTL:
- dEQP-VK.ray_query.*.serialization.*
Cc: mesa-stable
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35590>
The per-MRT blend enables are in RB_MRT_CONTROL regs, this field is a
bitmask of whether we need to read in the MRT's current color in order to
perform the blending/colormask/logicop.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34991>
There are currently two places where we have to handle values that are
logically 64b: 64b atomics and 64b global addresses. For the former, we
ingest the values as 64b from NIR, while the latter uses 2x32b values.
This commit makes things more consistent by using 64b NIR values for
global addresses as well.
Of course, we could also go the other way around and use 2x32b values
everywhere, which would make things consistent as well. Given that ir3
doesn't actually have 64b registers, and 64b values are represented by
collected 2x32b registers, this could actually make more sense.
In the end, both methods are mostly equivalent and it probably doesn't
matter too much one way or the other. However, the reason I have a
slight preference for ingesting things as 64b is that it allows us to
use more of the generic NIR intrinsics, which use 1-component values for
64b addresses or atomic values. This commit already makes
global_atomic(_swap)_ir3 obsolete and I'm planning to create generic
intrinsics to support ldg.a/stg.a as well.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
This implements the common pattern of splitting-off a scalar value from
a vector. It handles both 64b (via ir3_64b) and normal register scalars.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
64b values occupy 2 registers but we receive them as a single component
value from NIR. Since there are many places that assume a 1:1
relationship between components and instructions, this can be error
prone as we have to remember to double the number of components whenever
a 64b value is involved.
This commit tries to improve on this situation by representing 64b
values as a collect of 2 registers, restoring the 1:1 mapping between
NIR components and ir3 instructions. This commit only adds some helpers
to create 64b values and access their individual components but doesn't
actually use them yet. This will happen in a follow-up commit.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
When creating a collect with a source that is itself a collect, flatten
the latter's sources into the new collect. This is mainly useful for
collects used for 64b values, as we can treat them just like non-64b
values when collecting them.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
We want to start lowering certain NIR instructions to collects (e.g.,
instructions with a 64b def) which means that ir3_get_src_shared has to
support collects. Since we can't mov the result of a collect, implement
this by converting its sources and creating a new collect.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
