These are duplicates from a few lines up
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11703>
These are duplicates from a few lines up
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11703>
Per OpenGL Shading Language, section 8.11. "Atomic Memory Functions"
first argument "mem" of all atomicOP functions is inout.
The same is true for ARB_shader_storage_buffer_object and
GL_INTEL_shader_atomic_float_minmax
For implicit conversion of inout parameters it is required for type
to support bi-directional conversion, since there is no such types
in glsl - implicit conversion is effectively prohibited.
Alternatively we could have marked atomic_var parameter of built-in
atomicOP functions as inout, however it opens another can of worms
during NIR lowerings.
Fixes: ea0a1f5beb
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2837
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4887>
This commit adds the actual implementations, allowing to diverge while
still sharing code that depends on pool functionality.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11695>
The Gallium and Vulkan drivers will soon use different memory pool
implementation, but some pieces in libpanfrost depend on pan_pool. Let's
split the implementation so we have common bits still available while
letting the drivers implement what really matters: the allocation logic.
All the generic pieces are prefixed pan_pool, and what will become the
gallium implementation is prefixed panfrost_pool. We'll then duplicate
the panfrost_pool bits in panvk and prefix it with panvk_pool, and
implementations will start diverging from there.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11695>
Pass a memory pool to pan_blit_ctx_init() instead of creating a new pool.
Useful for Vulkan since the descriptor pool is at the command buffer
level and is thus shared by all blit batches. Doing this will save us a
BO ownership transfer.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11695>
The transient_bo has already been added to the BO list, no need to call
panfrost_batch_add_bo() a second time on the same BO.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11695>
The code was using a prim assembler after the tess stage, however
tess prims aren't necessarily the output prim types, so just put
the prim ids into the vertices at tess stage, and skip prim assembly.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11000>
This ensures space for the extra outputs is calculated in the
tes vertex outputs.
dEQP-VK.pipeline.misc.primitive_id_from_tess
Fixes: dacf8f5f5c ("draw: hook up final bits of tessellation")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11000>
This fixes a possible problem if a non-indexed draw comes in first
in a new batch, then the batch might not emit the index buffer.
I'm unsure if we see this, I just spotted it trying to fix alacritty
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11705>
+ 9.31% drawover:gdrv0 iris_dri.so [.] iris_binder_reserve_3d
+ 2.36% drawover:gdrv0 iris_dri.so [.] iris_binder_reserve_3d
If the app never uses compute, then the compute bindings bit will always
be dirty causing these two paths never get shortcuts.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11699>
Even with the wrap mode forced to REPEAT, we get undefined results in
CelShading when the Y channel is unwritten since the beginning of the
program.
I dropped the coords==0 case in the process, since that's not possible and
made the 1D case confusing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11457>
This was used in the heuristics for deciding whether to CPU map,
but those have since been deleted, so this is now unused.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11644>
If the caller has asked for a coherent BO with snooping, and the kernel
fails to set it for whatever reason, we were happily returning them a
non-coherent buffer. This isn't what they wanted and could lead to
surprising results.
Better to simply fail the allocation. Probably.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11644>
On integrated GPUs without LLC, we enable snooping when someone requests
coherency for a buffer. (With LLC, it's already coherent.)
For discrete GPUs...if someone requests coherency, we allocate the
buffer in SMEM and resort to WC maps rather than WB maps with CPU
caches enabled. There's no snooping to enable, and calling this ioctl
is nonsensical, and may fail.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11644>
