The code is a bit simpler to follow. We add new files so rarely, that
it shouldn't be much of a burden add new items.
Reworks:
* Iván Briano recommended to use array of names rather than more
complicated filename parsing.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40103>
This makes use of VK_KHR_pipeline_executable_properties and
VK_EXT_subgroup_size_control to query supported subgroup sizes and to
query which one the driver picks for a given pipeline.
This fixes OpenCL subgroups on drivers with multiple supported subgroup
sizes.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37169>
This might introduce some flakiness due to the inherent "only one process
can have HyperZ lock" feature. So it might not catch regressions reliably,
but probably better than no coverage at all.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39914>
AMD docs support this:
R5xx Acceleration v1.5 says safest handling for ZFUNC changes is to disable
HiZ except specific LESS/LEQUAL and GREATER/GEQUAL transitions.
ATI OpenGL Programming and Optimization Guide advises avoiding ALWAYS when
trying to benefit from HiZ so that would imply fglrx also disables HiZ
there.
On RV530 this fixes the following dEQPs:
dEQP-GLES2.functional.fragment_ops.interaction.basic_shader.43
dEQP-GLES2.functional.fragment_ops.interaction.basic_shader.74
Fixes: 12dcbd5954 ("r300g: enable Hyper-Z by default on r500")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8093
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39914>
The DISCARD_WHOLE_RESOURCE path in vc4_map_usage_prep() replaces the
resource's BO with vc4_resource_bo_alloc(). As the RCL resolves
rsc->bo at job submit in vc4_submit_setup_rcl_surface(), any pending
write job would store to the new BO instead of the old one, corrupting
the new written data.
This is the same bug that was fixed in v3d in the previous commit.
Fixes: 18ccda7b86 ("vc4: When asked to discard-map a whole resource, discard it.")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40180>
The DISCARD_WHOLE_RESOURCE path in v3d_map_usage_prep() replaces the
resource's BO with v3d_resource_bo_alloc(). As the RCL resolves
rsc->bo at job submit in emit_rcl() any pending write job would
store to the new BO instead of the old one, corrupting the new
written data.
This is adressed by flushing all pending write jobs affecting the
resource before replacing its BO.
This fixes multiple tests where data copied to a renderbuffer was
overwritten by a previos GPU clear. Test are from the subgroup:
dEQP-GLES31.functional.copy_image.non_compressed.viewclass_32_bits.*
Fixes: 45bb8f2957 ("broadcom: Add V3D 3.3 gallium driver called "vc5", for BCM7268.")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40180>
Excluding fields which are copied in ac_gpu_info.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40042>
We currently use a custom kernel in blu/linux to run the ci for svga,
instead switch to the kernel used by other drivers.
Signed-off-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40016>
Expose the extension, feature bit, and properties for
VK_ARM_scheduling_controls on CSF architectures (>= v10).
The only supported scheduling control flag is
VK_PHYSICAL_DEVICE_SCHEDULING_CONTROLS_SHADER_CORE_COUNT_ARM, which
allows applications to limit the number of shader cores used by a
queue via VkDeviceQueueShaderCoreControlCreateInfoARM.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40063>
Extract VkDeviceQueueShaderCoreControlCreateInfoARM from the queue
create info pNext chain and use shaderCoreCount to limit
max_compute_cores and max_fragment_cores in the panthor group create
ioctl. The core masks remain unchanged, letting the kernel pick which
cores to schedule on.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40063>
Coverity notes that we break out of the loop walking the analysis_ranges
early if n_push_ranges >= max_push_buffers, so it notes that
n_push_ranges could already be 3 or 4 (depending on whether we're doing
mesh), and that then if we need the padding we insert another, which
would write past the end of the array.
I don't think this is actually possible in practice, but we can add an
assert to both keep coverity happy and detect that this has actually
happened.
CID: 1681478
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40147>
