If we ever want to stop depending on the EXEC_OBJECT_PINNED to detect
when something is pinned (like for VM_BIND), having a helper will reduce
the code churn. This also gives us the opportunity to make it compile
away to true/false when we can figure it out just based on compile-time
GFX_VERx10.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13610>
Starting with 3b363d5b55 ("anv: Assume syncobj support"), we assume
syncobj support and no longer use the execbuf sync_file API directly so
there's no point in checking for it. For the one physical device check
this deletes, we can assume has_exec_fence is always true because every
kernel with syncobj support also has sync_file.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13610>
Soft-pin is but one possible mechanism for pinning buffers. We're
working on another called VM_BIND. Most of the time, the real question
we're asking isn't "are we using soft-pin?" but rather "are we using
relocations?" because it's relocations, and not soft-pin, that cause us
all the extra pain we have to write code to handle. This commit flips
the majority of those checks around. The new helper is currently just
the exact inverse of the old use_softpin helper.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13610>
When the client calls vkMapMemory(), we have to align the requested
offset down to the nearest page or else the map will fail. On platforms
where we have DRM_IOCTL_I915_GEM_MMAP_OFFSET, we always map the whole
buffer. In either case, the original map may start before the requested
offset and we need to take that into account when we clflush.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13610>
This is left-over from the days where we didn't use BO pointers and had
them embedded and we didn't have a nice allocation API. Now that block
pools get their memory via anv_device_alloc_bo(), they really should be
using anv_device_release_bo() to tear it down. This is equivalent in
this case because anv_device_release_bo() does the following:
1. Decrements refcount. The pool holds the only reference so it will
proceed onto the clean-up steps
2. Unmaps it, if needed. This is the same as the tear-down code today
except anv_device_release_bo() will avoid doing an unmap if it's
been created via userptr. The current code probably unmaps the
userptr which is wrong but pretty harmless since it happens on a
tear-down path.
3. Unmaps the CCS range from the AUX-TT, if any. There is none, so
this is a no-op.
4. Frees the VA range if it's not pinned and doesn't have a fixed VA
assignment. These BOs always either have a fixed VA range (softpin)
or aren't pinned (relocations).
5. Closes the GEM handle. Same as the current code.
In short, anything created using the BO API should probably be destroyed
that way. We were getting away with hand-rolling it because this is a
simple case. Why did we do it this way? It dates back to before the
more formlized BO cache and BO API in ANV.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13610>
The anv_bo_finish helper is explicitly supposed to be capable of tearing
down partially completed BOs as long as the flag and metadata parameters
are set correctly.
Reviwed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13610>
We don't current enable post sync operations, but it is probably
better to set them to "internal" MOCS than to remove the non-zero
checking for this genxml field.
Reworks:
* Fix COMPUTE_WALKER in cmd_buffer_trace_rays (s-b Jason)
Fixes: 7b78b2fcac ("intel/genxml: Assert that all MOCS fields are non-zero on Gfx7+")
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13624>
On GFX version 12.5+ with COMPUTE_WALKER, this is the limit based on the
size of the HW packet. On older HW, we can technically go a bit bigger
but there's not much point. Technically, some hardware can support a
scalar workgroup size up to 2048 but most apps don't go any bigger than
1024.
As discussed on the merge request page, the current limit assumes
SIMD32, but it is unclear if we want to encourage applications to use
SIMD32 if it may lead to additional register spilling in shader
programs. Many applications have likely tuned for a limit of 1024
based on the OpenGL minimum limit, so it might not gain much by
advertising more than 1024.
Reworks:
* Jordan: Use MIN2 and limit total invocations as well.
* Jordan: Add second paragraph to commit message based on merge
request discussion.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13538>
A bit difficult to find what commit introduced the issue because of
all the renaming, but it was my bug :)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10015>
When a device has its first slice/subslice fused off, we can't use the
number of slices/subslices to iterate the mask array.
v2: Fix spelling (Marcin)
Use size_t for iterator (Marcin)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reported-by: Matt Roper <matthew.d.roper@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5601
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10015>
Rather than having 2 paths to set the slice/subslice/eu masks, reuse
the other internal functions. This simplifies finding bugs within this
code :
* If we have i915 query topology support, update_from_topology() is
called.
* If we don't have query topology support but we have getparam for
slice/subslice/EU, we generate a topology data and call
update_from_topology()
* If we have no kernel support to query any kind of topology, we
generate the values return by the kernel for slice/subslice/EU and
call update_from_masks() which in turns calls
update_from_topology()
v2: Fixup typo (Adam)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10015>
Patch moves initialization of variable so that we have fd when calling
wsi initialization.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12305>
Instead of checking for MESA_SHADER_COMPUTE (and KERNEL). Where
appropriate, also use gl_shader_stage_is_compute().
This allows most of the workgroup-related lowering to be applied to
Task and Mesh shaders. These will be added later and "inherit" from
cs_prog_data structure.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13629>
Enum values for MESA_SHADER_TASK and MESA_SHADER_MESH are larger than
MESA_SHADER_FRAGMENT, so can't rely on the them for ordering anymore.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13637>
We could decouple the locations in the array from the gl_shader_stage
enum values, but for now this is convenient.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13637>
The code is correct, but compiler can't see it. Initialize the value
to NULL and assert on it if the function succeeds. It both helps the
compiler and make the code slightly more robust.
```
../src/intel/vulkan/anv_queue.c: In function ‘anv_QueueSubmit2KHR’:
../src/intel/vulkan/anv_queue.c:932:16: warning: ‘impl’ may be used uninitialized in this function [-Wmaybe-uninitialized]
932 | result = anv_queue_submit_add_timeline_wait(queue, submit,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
933 | &impl->timeline,
| ~~~~~~~~~~~~~~~~
934 | value);
| ~~~~~~
../src/intel/vulkan/anv_queue.c:899:31: note: ‘impl’ was declared here
899 | struct anv_semaphore_impl *impl;
| ^~~~
```
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13638>
Fix defect reported by Coverity Scan.
Uninitialized pointer field (UNINIT_CTOR)
uninit_member: Non-static class member error is not initialized
in this constructor nor in any functions that it calls.
Fixes: 7558340ebb ("intel/compiler: Add helpers to select SIMD for compute shaders")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13608>
brw_simd_select return type is int.
Fix defect reported by Coverity Scan.
Unsigned compared against 0 (NO_EFFECT)
unsigned_compare: This less-than-zero comparison of an unsigned value is never true. selected_simd < 0U.
Fixes: 7dda0cf2b8 ("intel/compiler: Use SIMD selection helpers for CS")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13606>
Fixes dEQP-VK.reconvergence.*nesting* tests.
There are cases when cmod is set to an instruction that cannot have
conditional modifier. E.g. following:
find_live_channel(32) vgrf166:UD, NoMask
cmp.z.f0.0(32) null:D, vgrf166+0.0<0>:D, 0d
is optimized to:
find_live_channel.z.f0.0(32) vgrf166:UD, NoMask
v2:
- Add unit test to check cmod is not set to 'find_live_channel' (Matt Turner)
- Update flag_subreg when conditonal_mod is updated (Ian Romanick)
Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5431
Fixes: 32b7ba66b0 ("intel/compiler: fix cmod propagation optimisations")
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13268>
This is a new blitter command introduced on Tigerlake and expanded
substantially on XeHP. XY_BLOCK_COPY_BLT is actually fast, unlike
the legacy blitter commands. iris will use this in the future, and
anv hopefully could use it for a transfer queue someday as well.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13520>
We're going to want to use the blitter again on newer hardware,
which means we need to be able to use genxml to emit those commands.
Acked-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13520>
This asserts that the value supplied is non-zero. Useful for things
like MOCS fields on modern platforms where we really want to avoid
setting it to 0 (uncached).
mbz types cannot be flagged as nonzero.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is disabled stream output targets, MOCS shouldn't matter, as
there's no actual buffer to be cached.
That said, it should be harmless to set MOCS for these null stream
output buffers; we can just assume a MOCS for generic internal buffers.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
