The queue_family field is not an array, but a pointer.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9866c4e32b ("anv: Skip layout transition on the compute queue")
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26645>
Because gcc was complaining:
../../src/intel/tools/intel_hang_viewer.cpp: In function ‘void display_hang_stats()’:
../../src/intel/tools/intel_hang_viewer.cpp:365:31: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘std::vector<hang_bo>::size_type’ {aka ‘unsigned int’} [-Werror=format=]
365 | ImGui::Text("BOs: %lu", context.bos.size());
| ~~^ ~~~~~~~~~~~~~~~~~~
| | |
| long unsigned int std::vector<hang_bo>::size_type {aka unsigned int}
| %u
../../src/intel/tools/intel_hang_viewer.cpp:366:31: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘std::vector<hang_exec>::size_type’ {aka ‘unsigned int’} [-Werror=format=]
366 | ImGui::Text("Execs %lu", context.execs.size());
| ~~^ ~~~~~~~~~~~~~~~~~~~~
| | |
| long unsigned int std::vector<hang_exec>::size_type {aka unsigned int}
| %u
../../src/intel/tools/intel_hang_viewer.cpp:367:31: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘std::vector<hang_map>::size_type’ {aka ‘unsigned int’} [-Werror=format=]
367 | ImGui::Text("Maps: %lu", context.maps.size());
| ~~^ ~~~~~~~~~~~~~~~~~~~
| | |
| long unsigned int std::vector<hang_map>::size_type {aka unsigned int}
| %u
cc1plus: some warnings being treated as errors
I'm not sure if STL's size_type is defined by the spec to be anything
specific, but for the platforms we care about it seems to be size_t,
so change it to %z.
Fixes: 33fd93f3b1 ("intel/tools: hang viewer/editor")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26581>
The Blitter engine lacks support for 3 components color format so we can
just fallback to RCS companion command buffer for the blit operation.
Even though blitter supports 96-bit support it only supports linear
tiling. We can support other types of tiling by falling back to the RCS
companion command buffer.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26300>
There was a subtle bug related to CFG tracking. Namely, some branch
instructions may point *only* to the block after the DO instruction
for the loop. If the MOV instructions are in the DO block, the may not
have liveness properly tracked.
Like in !25132, having the MOV instructions in blocks that might
contain other instructions helps scheduling.
shader-db:
All Broadwell and newer Intel GPUs had similar results (Ice Lake shown)
total cycles in shared programs: 848577248 -> 848557268 (<.01%)
cycles in affected programs: 78256396 -> 78236416 (-0.03%)
helped: 361 / HURT: 18
fossil-db:
All Skylake and newer Intel GPUs had similar results (Ice Lake shown)
Totals:
Cycles: 15021501924 -> 15021372904 (-0.00%); split: -0.00%, +0.00%
Totals from 735 (0.11% of 656080) affected shaders:
Cycles: 676429502 -> 676300482 (-0.02%); split: -0.02%, +0.00%
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26439>
When calculating the system memory heap size, we report only 3/4 of
the total RAM size (or 1/2 for systems with less than 4GB of RAM).
In the memory budget extension query, we were reporting 90% of the
available system memory. If most of the memory in the system is free,
this could result in the total heap size being 3/4 of RAM, but the
memory available being 9/10 of RAM. But if the application tried to
allocate the memory reported as "available", it would exceed the heap
size. This can confuse some applications.
This patch makes the memory budget query clamp the available RAM to
the heap size, so it will never report more available than the heap
can provide. Unfortunately, this means that we'll report only 67.5%
of system memory as available (3/4 * 9/10). We may want to adjust
this estimate in the future.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26553>
This was mainly useful for older Gen7.x GPUs with 32-bit PPGTT, which
are now supported by hasvk rather than anv. The remaining platforms
which anv supports have 36, 47, or 48-bit PPGTT, which imposes a 3/4
limit of 48GB, 96TB, and 192TB of memory.
The GPUs with 36-bit PPGTT are Elkhart Lake and Jasper Lake, which
appear to be Atom CPUs that have a maximum supported memory
configuration of 32GB or less, so this limit should not matter there.
Nor is a multi-TB limit likely to matter on our other parts.
Drop this check to simplify the heap and memory budget calculations.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26553>
nir_emit_global_atomic should utilize lsc_op_num_data_values to
infer the number of operands for global atomic ops, following the same
pattern as nir_emit_surface_atomic
Fixes: 90a2137 ('intel/compiler: Use LSC opcode enum rather than legacy BRW_AOPs')
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26432>
'Tile Cache Flush Enable' and 'Generic Media State Clear' are now
reserved bits in gfx20+.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26403>
align is a function and when we want use it, the align variable will shadow it
So replace it with other names
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25997>
Batch bos are always allocated with ANV_BO_ALLOC_HOST_CACHED_COHERENT
so there is no need to do cflush calls.
But if we ever decide to change that anv_bo_needs_host_cache_flush()
will make sure cflush is called.
Outside of batch bos, this patch is also removing the
intel_flush_range() call from anv_QueuePresentKHR because
device->debug_frame_desc is offset of workaround_bo that is also
allocated as ANV_BO_ALLOC_HOST_COHERENT.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26457>
In platforms with LLC we can promote all bos to cached+coherent
without any performance penality.
On the up side CPU reads can hit cache this way.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26457>
As suggested by Lionel, here adding ANV_BO_ALLOC_HOST_COHERENT
and with that ANV_BO_ALLOC_HOST_CACHED_COHERENT is now defined by
(ANV_BO_ALLOC_HOST_COHERENT | ANV_BO_ALLOC_HOST_CACHED).
In some callers of anv_device_alloc_bo() was necessary to add
ANV_BO_ALLOC_HOST_COHERENT as no other flag was set and that
was the default behavior up to now.
A change that could look not related is the removal of the
intel_flush_range() in anv_device_init_trivial_batch(), that was done
because trivial_batch_bo is HOST_COHERENT so no flush is necessary.
And it did not made sense to make it ANV_BO_ALLOC_HOST_CACHED_COHERENT
as it was never read in CPU.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26457>
Kernel versions without DRM_I915_QUERY_MEMORY_REGIONS support will
take a different code path in i915_gem_create() that lacks the
i915_gem_set_caching() call to make cached bos in gen9 lp 1 way
coherent.
Fixes: fc0acf6d90 ("anv: Move i915 specific gem_set_caching to backend")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26457>
This fields are required to be set because those are used by
XY_FAST_COLOR_BLT instruction.
Right now it is not set causing applications to abort because
DestinationMOCS is required to be non-zero.
This fixes at least piglit@ext_external_objects-vk-image-display on MTL.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26502>
All these jobs are redundant and a waste of resources:
- the containers have already been built & pushed in the merge pipeline
- the mesa build variants have already all passed
- the driver tests have already all passed
None of these jobs are doing anything useful in this pipeline, but it
costs a factor of 2x to our infrastructure, so let's remove them.
In other words, the only job left in the post-merge pipeline is the
`pages` job that deploys the update to the website.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26451>
XY_BLOCK_COPY_BLT and XY_FAST_COLOR_BLT instruction supports AUX_CCS
surface mode. Stencil buffer compression is stencil data with CCS so we
can easily support that on blitter engine.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26167>
The standard block shapes (and by extension, the tiling formats they
require) are simply incompatible with getting a 2D view of a 3D image.
I couldn't find in the Vulkan spec anything related to what are the
expectations when trying to use both at the same time.
So here we "document" that this case is known non-standard. Please
notice that since we report residencyStandard3DBlockShape as true we
were actually supposed to support this case, but I can't see how this
would be possible, so set is_known_nonstandard_format to true so we
can avoid the assert() that comes right after.
Fixes the following when using Zink:
KHR-GL46.sparse_texture_tests.SparseTextureAllocation
Also "moves forward" the following test on Zink, so it now hits a
different assertion:
KHR-GL46.sparse_texture_tests.SparseTextureCommitment
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26454>
During vkGetPhysicalDeviceSparseImageFormatProperties(), check first
if the non-sparse version of the image is supported, and return in
case it's not.
On TGL, if we don't do that, we may hit the following assertion:
deqp-vk: ../../src/intel/isl/isl.c:2584: isl_surf_init_s: Assertion `!(info->usage & ISL_SURF_USAGE_CPB_BIT) || dev->info->has_coarse_pixel_primitive_and_cb' failed.
My TGL doesn't has_coarse_pixel_primitive_and_cb.
Fixes the following on TGL:
dEQP-VK.api.maintenance5.flags.sparse_image_format_props
dEQP-VK.api.maintenance5.flags.sparse_image_format_props2
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26454>
If the size here is not a multiple of the granularity (64kb) then
we'll miss our "pages" estimation by 1. We could fix this with
DIV_ROUND_UP() or by simply putting a "+1" there, but the upper layers
should now be preventing this case so let's just put the assertion
here.
Previously it was possible to hit this case with Zink by running
under certain conditions piglit/arb_sparse_buffer-basic.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26454>
From the spec:
"Resources can be bound at some defined (sparse block) granularity."
"The sparse block size in bytes for sparse buffers and
fully-resident images is reported as
VkMemoryRequirements::alignment. alignment represents both the
memory alignment requirement and the binding granularity (in bytes)
for sparse resources."
Not only the upper layer (the Spec) doesn't allow this, the lower
layers (both the vm_bind ioctl and TR-TT) also work on a granularity.
Just check for this case and return an error.
Before this check, what would happen was:
- for the vm_bind backend, the vm_bind ioctl would fail
- for the TR-TT backend, we'd understimate l1_binds_capacity and
fail an assertion, or we'd just silently bind 64kb instead of the
original size
Currently, some Zink tests such as piglit/arb_sparse_buffer-basic can
trigger this behavior, but we're working to fix Zink for this case
(and that commit may be merged before this one).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26454>
A previous patch already removed individual compilation of the inputs,
by simply concatenating the files. This patch removes the linking of
the remaining single object that's compiled.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26458>
A previous change concatenated multiple SPIR-V inputs to be
compiled together, so we have a single clc_binary to work on.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26458>
We had the unfortunate finding on a recent platform to learn that the
bindless sampler heap is not functioning as expected.
Nowhere in the documentation is the size of the heap written down. So
most people assumed that's the max number that we can program (4Gb).
The reality is that it's only 64Mb.
Though it is appearing like it's working properly for the whole 4Gb
range for most apps, this is only because the HW bounds checking
applied is broken. Instead of clamping anything beyong 64Mb, it's only
clamping the last 4Kb of each 64Mb region.
So this heap is useless for us to make a 4Gb region of both sampler &
surface states...
This change essentially turns off the bindless sampler heap on DG2+.
The only location where we can put SAMPLER_STATE elements is the
dynamic state heap. Unfortunately we cannot align the dynamic state
heap with the bindless surface state heap. So the solution is to
allocate sampler & surface states separately, each from the own heap
in the descriptor pool.
We now have to provide 2 sets of offsets for surfaces & samplers.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25897>
According to PRMs, to use self-modifying code correctly we have to
disable preparser before jumping to the generated commands, and re-enable
it with a first command in that buffer.
Old implementation did it wrong: for both inplace and inring generation
it disabled preparser before running the generation shader, had it
disabled during generation, and re-enabled it just before jumping to
the generated commands.
This usually didn't cause any trouble, because the generation shader and
generated draws are in different BOs, and the jump distance is greater than
the command FIFO depth. But we allocate them from the same pool,
so there are rare cases where the end of the BO with generation commands,
and the beginning of the BO with generated draws are adjacent. In such
cases, the wrong commands might be fetched.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10162
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26427>
