We handle linear 2D arrays internally for blit shaders, so we need textureSize
to work for these. That requires some special casing, because there's a line
stride where the layer count would otherwise be. But it's not too bad.
Fixes
dEQP-GLES3.functional.shaders.texture_functions.texturesize.sampler2darray_*
when forcing linear textures.
Since we clamp array access to the maximum layer, we need textureSize() to work
for even the most basic array texturing. So this should fix blits from linear 2D
arrays as well, which finally unlocks support for compressed arrays/cubes/3D
textures.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
The first two sources are floats, the latter two sources and destination (and
hence the opcode) are not. Reflect that when packing and optimizing. Noticed
while debugging a silly dEQP test.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
From the commit message of 94f7c011d6 ("v3d: Track write reference to the
separate stencil buffer."), anholt says:
Otherwise, a blit from separate stencil may fail to flush the job that
initialized it, or new drawing could fail to flush a blit reading from
stencil.
Fixes
dEQP-GLES3.functional.fbo.blit.depth_stencil.depth32f_stencil8_stencil_only
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
Our staging resources need to be LINEAR, however we don't support LINEAR with
DEPTH_STENCIL. The APIs don't actually require this, we just need to make sure
we don't generate internal staging blits to linear depth/stencil resources. For
uploading to compressed depth/stencil textures, we could use a depth/stencil
staging (since we can read from linear depth/stencil). However, for downloading
from compressed depth/stencil, we can't use a depth/stencil staging (since we
can't write linear depth/stencil). So, to handle both cases in a unified way,
just use colour blits for depth/stencil resources, using a compatible colour
format. This wouldn't be ok for an application to do itself, but within the
driver we know that it's safe, since there's no difference in memory between
depth/stencil and colour on AGX. In particular, Z16 is compressed exactly the
same as R16, Z8 as R8, and so on.
Fixes depth/stencil compression.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
Otherwise framebuffer->width ends up being wrong with u_blitter, this is what
other drivers do. If we needed to render to depth/stencil with u_blitter, this
would cause us trouble.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
We go to initialize the disk cache before we've compiled any shaders so
agx_compiler_debug is 0 at this point. Don't try to read it, instead go through
sa safe getter that will do the right thing.
Fixes: 5e9538c12e ("agx: isolate compiler debug flags")
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
When an empty batch is submitted, nothing happens. However, this batch
may have taken over writer status for some BOs which still have a
pending submitted batch that hasn't finished yet. If we drop writer
status at this point, two bad things happen:
- We spuriously clear bo->writer_syncobj, which breaks syncing on
post-facto BO exports
- We break agx_sync_writer(), since we no longer know about the old
writer to properly block on it.
To fix this (hopefully rare) case, take advantage of bo->writer_syncobj
to find the currently submitted writer batch again, and revert the
writer to it. If this turns out to be common and a performance issue
iterating through submitted batches for each written BO, we could
implement it with two writer batch arrays instead, one for active
writers and one for submitted writers... but hopefully that isn't
necessary.
This splits the cleanup path in agx_batch_cleanup() depending on whether
the cleanup is for a reset or proper completion. Since this is only used
within agx_batch.c, drop the public prototype while we're at it.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
These need the shader_base added to them. Fixes GEM_BIND errors after
usc_head provides VA without the VM_SHADER_START offset from returned
low VA.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
The typo is in the !__GLIBC__ case and was observed while building on
Alpine.
Fixes: 0a132b0640 ("asahi: Add a helper macro for debug/error messages")
Reported-by: mps
Tested-by: mps
Signed-off-by: Janne Grunau <j@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
This doesn't enable support for a7xx yet, but uses the new register pack
builders for registers that differ between a7xx and a6xx.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22837>
We need to excape the underscores for shadow_ref, as well as escape
non-math symbols.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21893>
This block isn't valid latex, so let's just use a pseudocode-block like
we do elsewhere here.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21893>
These are math-blocks, which is supposed to use math-notation for
conditionals. So let's change it to math notation.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21893>
While we're at it, use some alignment so the equations still reads
reasonably.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21893>
It's better to split these two equations in two than to try to write
extra text that needs lots of escaping. This fixes the LaTeX rendering
to be somewhat readable.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21893>
We need empty spaces here, otherwise LaTeX thinks it's one equation, and
puts it all back onto one line.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21893>
There's a mixture of indent styles here, with either two or three
spaces. We have standardized on three spaces for .rst-files in the
editorconfig, so let's apply that.
While we're at it, make sure math-blocks are indented into their
opcode-block. While the result might look the same most of the time,
this matters when we have textual explaination following math-blocks,
like we have in a few caess. If we don't indent the math there, we
end up with having to unindent the text following the math-block for it
not to count as a part of the math block, which looks very confusing
when reading the source code.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21893>
../src/microsoft/vulkan/dzn_image.c: In function ‘dzn_GetImageMemoryRequirements2’:
../src/microsoft/vulkan/dzn_image.c:918:91: error: passing argument 6 of ‘dzn_ID3D12Device12_GetResourceAllocationInfo3’ from incompatible pointer type [-Werror=incompatible-pointer-types]
918 | &image->castable_format_count, &image->castable_formats,
| ^~~~~~~~~~~~~~~~~~~~~~~~
| |
| DXGI_FORMAT **
In file included from ../src/microsoft/vulkan/dzn_private.h:67,
from ../src/microsoft/vulkan/dzn_image.c:24:
../src/microsoft/vulkan/dzn_abi_helper.h:64:107: note: expected ‘const DXGI_FORMAT * const*’ but argument is of type ‘DXGI_FORMAT **’
64 | const UINT *num_castable_formats, const DXGI_FORMAT *const *castable_formats,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
ninja: build stopped: subcommand failed.
Fixes: 71dbb3120a ("dzn: Use GetResourceAllocationInfo3 for castable formats")
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22877>
reason:
in some cases, bs buffer size could cause assertion,
and some bitstreams of certain resolutions could
not be decoded.
solution:
to align the bs buffer to 128.
fixes: 4f1646d73f
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22844>
We're about to manipulate these pools and dealing with the fix address
ranges is painful.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22847>
We want to add more heaps in the future and so not having to do
address checks to find out in what heap to release a BO is convinient.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22847>
All the supported platforms should have 36+ bits of virtual address
space.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22847>
These asserts were checking isl_format_layout against itself, change
to compare surface format layout against view format layout.
Fixes: 628bfaf1c6 ("intel/isl: Add some sanity checks for compressed surfaces")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22790>
With the following test :
dEQP-VK.spirv_assembly.instruction.terminate_invocation.terminate.no_out_of_bounds_load
There is a :
shader_start:
... <- no control flow
g0 = some_alu
g1 = fbl
g2 = broadcast g3, g1
g4 = get_buffer_size g2
... <- no control flow
halt <- on some lanes
g5 = send <surface>, g4
eliminate_find_live_channel will remove the fbl/broadcast because it
assumes lane0 is active at get_buffer_size :
shader_start:
... <- no control flow
g0 = some_alu
g4 = get_buffer_size g0
... <- no control flow
halt <- on some lanes
g5 = send <surface>, g4
But then the instruction scheduler will move the get_buffer_size after
the halt :
shader_start:
... <- no control flow
halt <- on some lanes
g0 = some_alu
g4 = get_buffer_size g0
g5 = send <surface>, g4
get_buffer_size pulls the surface index from lane0 in g0 which could
have been turned off by the halt and we end up accessing an invalid
surface handle.
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/20765>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22690>
There is no need to use alloc_vertices_and_primitives anymore,
because it will be compiled to sendmsg anyway.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22690>
