radv will lower this intrinsic before gets to llvm, so we just need to
implement it in radeonsi.
The tes version will be used in tess lower too.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16705>
Also add radv and radeonsi implementation. Will be used in tess lowering.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16705>
Create nir passthrough shader with explicit input/output and vertex
output count so that it can be handled by compiler same as user tcs.
The drawback is we create more si_shader_selector with different
input/output and vertex output count which was handled by compiler
backend before.
As fixed function tcs can be handled like user tcs, we don't need
the dedicated fixed_func_tcs_shader state either.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16705>
We can do this parse with original nir instead of shader key pass
applied nir in si_get_nir_shader.
This can free si_get_nir_shader to just use si_shader as parameter.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16705>
We tracked this down with the HW teams back in 2020 and there's now a
documented workaround. Comments from the HW team say this applies all
the way through XeHP but we're not sure beyond that.
This is a bug that we hit but the Windows drivers didn't because Jason
decided to allocate our memory structures from the top end of the VMA
range explicitly to catch bugs like this, while Windows allocates from
zero and up, so they would need to allocate more than 2GB of dynamic
state before running into it.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4880
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17216>
this should be simpler to read through and maintain while providing
the same results as well as some possible perf and compile time improvements
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17192>
update_barriers has steadily grown more and more complex when the original
idea was for it to be a small function to handle deferred jit barriers and
simplify sync in patterns like bind_ubo -> draw -> buffer_subdata -> draw
instead, track the pending barrier info at bind time so that the stages and
access are already updated by the time draw/compute are reached
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17192>
this avoids the scenario where the full bo size isn't accounted for because
no variable for the block has been created
cc: mesa-stable
affects:
KHR-GL33.shaders.uniform_block.random.all_per_block_buffers.3
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17217>
GL_MAP_UNSYNCHRONIZED_BIT depends on the app having its threading
handled correctly. This allows us to force disable the bit when
they get it wrong.
CC: 22.1 22.0 <mesa-stable>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17199>
these values should have all been set during pipeline compositing above,
so reapplying the values is at best, redundant, and at worst, broken
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17219>
only the viewMask parameter of VkPipelineRenderingCreateInfoKHR can
be accessed in the fragment stage, so for pipeline libraries it should
be assumed that zs attachments exist for the purpose of copying dynamic
state values, and then these dynamic states will naturally be pruned
during final pipeline construction if the attachments turn out to not
be present
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17219>
[Alyssa: Add a default CPU implementation of pipe->clear_buffer(). This hook is
mandatory for OpenCL support. Even though this implementation isn't optimal by
any means, having a conformant default available in core will lower the barrier
of entry to OpenCL support.]
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16044>
It is now unused. We cannot yet remove the streamout functionality in u_blitter
as r600g still uses it for clear_buffer on GPUs older than Evergreen.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17142>
r600g is the only user of util_blitter_copy_buffer in tree, which implements
buffer copies with streamout. This path for r600g was added in 8ac9801669
("r600g: accelerate buffer copying"), a commit from 2012. At that point there
was no DMA path for buffer copies. Since then, a DMA path has been added,
conditional only on the kernel version -- not the hardware. It appears the
required kernel support has been mainline for at least 4 years now. Mesa 22.2
doesn't need to provide optimal performance on an old kernel -- for performance,
a DMA-capable kernel should be used, and for compatability, the CPU fallback
(used for unaligned buffers as it is) is still available. Remove the streamout
path "in the middle" that appears ~unused today.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17142>
error message:
```
../../src/gallium/winsys/d3d12/wgl/d3d12_wgl_framebuffer.cpp:231:42: error: no matching function for call to 'operator new(sizetype, d3d12_wgl_framebuffer*&)'
231 | new (fb) struct d3d12_wgl_framebuffer();
| ^
<built-in>: note: candidate: 'void* operator new(long long unsigned int)'
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16084>
Because we may compile mesa with both rtti=enabled and rtti=disabled because of LLVM
Fixes errors:
../../src/gallium/drivers/d3d12/d3d12_video_enc_h264.cpp:777:7: error: 'dynamic_cast' not permitted with '-fno-rtti'
777 | dynamic_cast<d3d12_video_bitstream_builder_h264 *>(pD3D12Enc->m_upBitstreamBuilder.get());
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16084>
Reprogram SF CLIP viewport pointer by not skipping its
dirty flag bit.
Many thanks to Lin, Shuicheng <shuicheng.lin@intel.com>,
Jerez Plata, Francisco <francisco.jerez.plata@intel.com>,
Graunke, Kenneth W <kenneth.w.graunke@intel.com>,
and others for their great help.
Signed-off-by: Zhang, Jianxun <jianxun.zhang@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17171>
We had it set up for arm64 asan already, do it for everyone else too. In
cleaning up the duplication, this fixes a pasteo in rpi3 which had the
"artifacts: false" on the wrong job, causing it to do a slow download of
the mesa build from gitlab.
Doing this required also moving the ".use-debian/arm_test" in as well, so
that its "needs:" didn't overwrite ours if it appeared after us in the
consumer's "extends:"
Should save about 20 seconds on rpi3 jobs.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17146>
This was missing, and the added validation caught it.
Fixes: 708c47e663 ("nir: Validate nir_tex_instr::dest_type bitsize")
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17172>
As it turns out, MOVs weren't the only instructions that blocked precise
flags propagation in the transition to nir-to-tgsi.
This commit fixes some rendering regressions caused by a4a34cd3.
Fixes: a4a34cd3
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collanora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17144>
The RADEON_GEM_USERPTR_ANONONLY flag is hardcoded here which excludes
shared memory pages. DRM is actually capable of supporting shared file-
backed memory, but only if it's read-only. This mutability intent has to
be conveyed through the stack, so a flags argument is added to the winsys
regime to pass RADEON_FLAG_READ_ONLY.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16115>
