In order to build grl, we need to get the device_info struct from the
PCI ID, but for pre-production platforms we don't want to enable them
unless INTEL_FORCE_PROBE is set.
Setting it when running intel_clc allows us to get the device_info
struct when the pre-production hardware is not ready to be enabled by
default.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29273>
This environment variable allows some Intel devices that are
unsupported to be forced to run. These devices have incomplete
support, and therefore might not work at all.
Reworks:
* José: Simplify scan_for_force_probe() with strtok()
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29273>
For example:
CHIPSET(0x56a0, dg2_g10, "DG2", "Intel(R) Arc(tm) A770 Graphics", FORCE_PROBE)
For now if a PCI ID has FORCE_PROBE set, then we refuse to start the
device.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29273>
The queueFlags of the associated queue may have more flags than just the
type of queue it is, based on what that queue supports, like sparse or
protected content. Check that the queue is a blitter engine instead.
Fixes a bunch of dEQP-VK.api.copy_and_blit.core.*_transfer on MTL with
ANV_SPARSE=0
Fixes: 17b8b2cffd ("anv: Add support for a transfer queue on Alchemist")
Reviewed-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/29336>
Vulkan stencil image views of combined stencil Z32_S8 buffers can result
in a PIPE_FORMAT_X32_S8X24_UINT format being passed to the stencil view.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29382>
cmd_prepare_tiler_context() is just a wrapper around
cmd_get_tiler_context(), and cmd_get_tiler_context() is only called
from cmd_prepare_tiler_context().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29382>
pan_preload_fb() will use pre-frames on Bifrost. Pass NULL preload_jobs
and assert that num_preload_jobs is zero.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29382>
The old mipmap generation code has a few problems:
1. It open-codes the format conversion, which is error prone, and it's
hard to know if we're missing some formats. Manual inspection shows
that we're indeed missing some less commonly used formats.
2. When downsampling between two miplevels with the same width (e.g a
width of one), the code would read from outside the image.
3. It averages sRGB textures in gamma space. Whilte that's legal in GL
(the filtering algorithm is undefined), it doesn't produce very good
results. And it's not the same thing as util_gen_mipmap() does.
4. Similarly, it uses a box-filter for the stencil values. And while
that's actually what the spec recomments (regardless of format), it's
absolutely *not* what most applications would want. Using nearest
sampling would make more sense.
5. It has requirements about the type and format returned by
_mesa_uncompressed_format_to_type_and_comps() which other call-sites
in mesa doesn't have. This is the real reason I want to get rid of
it, because it ends up complicating the GLES read formats / types.
So, let's rewrite all of this, fixing all of the above. The result is
quite a bit shorter, and if this ends up being less performant, it's
unlikely that this matters, because we almost always use the GPU
accelerated code-path provided by util_gen_mipmap() anyway.
The new code works by a few identities: It uses the pack / unpack
helpers to convert the texture to a few reasonable intermediate formats,
so we keep the amount of open-coded averaging to a minimum. To do this
without heap-allocations, we introduce a concept of a "span", which has
a max fixed size, that can trivially be allocated on the stack.
We also add some more requirements to keep things sane; the higher level
do_row functions only allow the dest image to be half of the source
width or one (whichever is larger). This matches the high-level needs of
mipmap generation. The lower level do_span() function is a bit more
flexible, because that turns out to be helpful when implementing
do_span_3D(), where we want to avoid collapsing the inner dimension
twice.
Tested-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29380>
Rework:
* José: Restore "Register Poll Mode" default to "Memory Poll"
* José: Other minor formatting changes to match other genxml
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29264>
Reworks:
- Rohan: Use a uint for the surface format since we're dropping the
SURFACE_FORMAT enum from genxml
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29264>
The code for checking flow control did not realize that
`LD_TEX` and `LD_TEX_IMM` were memory accesses, and hence was
not inserting waits where these were necessary. This showed up
as flakes in KHR-GLES31.core.shader_image_load_store.basic-glsl-misc-fs
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29363>
Same sequence LLVM uses for llvm.amdgcn.s.barrier.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29330>
