Initialization of driver has been moved to register_data_source() from
OnSetup() by: a739889789 ("pps: Report available counters when
gpu.counters* data source is registered")
With above change, pps will destroy driver when collecting data stops
(pps may keep running) then the driver will become nullptr when user try
to collect data again. This will cause segmentation fault in OnSetup().
So this remove driver = nullptr in OnStop() and init driver in OnSetup()
to make sure driver exists when pps-producer run more than once.
Fixes: a739889789 ("pps: Report available counters when gpu.counters*
data source is registered")
Signed-off-by: Julia Zhang <Julia.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36548>
The previous algorithm just looked at the dominator's loop header.
However, if you have multiple consecutive loops like:
function_impl {
loop {
// Stuff
}
loop {
// Other stuff
}
}
then it will look like the second loop is contained in the first loop
because the first loop's header dominates the second loop. This isn't
actually what we want. Instead, we want a node N to be considered part
of a loop with header H if H dominates N and H is reachable from N.
Fixes: 741f7067f1 ("nak: Add loop detection to the CFG")
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36524>
KHR_maintenance9 allows for the creation of VkDevices with no queues for the
purpose of offline compilation and other similar usages. Notably, devices with
0 queues aren't allowed to allocate memory, create command buffers, or create
fences/semaphores; this allows us to completely skip creating a nvkmd device
and going through the kernel for these objects.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35804>
We need to be able to create samplers without necessarily having to have to
upload them. This is to allow us later to create a VkDevice without having to
touch the kernel for VkDevice objects without VkQueues used for things like
shader compilation.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35804>
Previously, these were going through nir_lower_bit_size, which handles
upscaling from lower bit sizes to 32-bit only and is incorrect for higher sizes.
This change uses nir_lower_int64 instead, which handles them properly and
correctly.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35804>
Long term, we don't want to support nouveau gl on new cards. Remove
the fallback so users without zink will get software rendering
instead of nouveau gl.
For now, NOUVEAU_USE_ZINK will still select nouveau gl on cards where
that is possible, but that isn't really supported and will likely be
removed for a lot of cards in the future.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36971>
It is safe to allocate command buffer memory as MEM_LOCAL (VRAM or GART)
when we can map GPU memory (we trust NVKMD to force GART).
This reduces latency on pyrowave for compute dispatch (~1.90ms -> ~1.48ms),
likely as QMD and the root tables should not have been in GART in the first place.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36970>
It turns out that the `occlusion_query.syncobj` is used to set
state that later code relies on, and setting it to NULL causes
some Vulkan CTS tests to fail. Instead, we should explicitly check
for the mode being `MALI_OCCLUSION_MODE_DISABLED` to avoid using
an invalid `ptr` field.
Fixes: 24c692c981 ("panvk: fix a NULL pointer dereference in occlusion queries")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36794>
`clRetainDevice` and `clReleaseDevice` ignore the device argument, it
should be checked for validity and return `CL_INVALID_DEVICE` if it
fails.
`check_cl_device_type` fails if entrypoint is passed `0` as the device
type. Zero as an input for a bitwise and operation will always result
in a zero, so the utility function fails to return
`CL_INVALID_DEVICE_TYPE`.
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37008>
Strictly speaking, for an empty batch, there is no inherit/defined
ordering between the wait and signal operations within the batch. We
are relying on MESA impl defined behavior to transfer payloads of the
wait sempahores to the signal sempahore here.
Ideally we need a MESA internal hint to ensure transitivity, but since
this is on the legacy fallback path, it's not worth the effort. So here
we follow common wsi to use TRANSFER_BIT which avoids most unnecessary
stalls on the queue (an improvement over the previous ALL_COMMANDS_BIT).
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36855>
Samuel Pitoiset