That remove the need of a special case for timestamp and will allow some
simplification for MME copies.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41507>
We only need some counters when the user request to track certain
queries, let's not keep them enabled all the time.
Following the proprietary driver here, unsure if that will have any
impact.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41507>
Like the proprietary driver, let's clear counters at the beginning of a
query.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41507>
We are going to conditionally change SET_ZPASS_PIXEL_COUNT and
SET_STATISTICS_COUNTER in queries handling.
To prepare for that we now use the MME shadow RAM to restore the
previous state.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41507>
This avoid relying on semaphore releases when we have multiple queries
being reset.
NVIDIA proprietary driver is performing the same however it do fill the
full report instead (as it also contain the available part packed with
it)
Signed-off-by: Mary Guillemard <mary@mary.zone>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41507>
Instead of trying to wait for each available values to be zeroed, we now
use NV906F_SET_REFERENCE.
NV906F_SET_REFERENCE behaves like a FE WFI+MEMBAR on the command
processor itself, ensuring ordering.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41507>
Small PS have their VGPR usage equal to the number of input VGPRs,
and this reduces it.
4 input VGPRs removed in most cases.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41226>
Small PS have their VGPR usage equal to the number of input VGPRs,
and this reduces it.
1 input VGPR removed from the PS prolog in most cases.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41226>
Small PS have their VGPR usage equal to the number of input VGPRs,
and this reduces it.
2 input VGPRs removed from the PS prolog in most cases.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41226>
Small PS have their VGPR usage equal to the number of input VGPRs,
and this reduces it.
4 input VGPRs removed in most cases.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41226>
This was missing and it slightly improves code generation.
8 is always correct with maximum sample shading.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41226>
The VGPR indices will be dynamic. This replaces hardcoded VGPR indices
with enums in the PS prolog key.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41226>
Color interpolation (INTERP_MODE_NONE) has unknown barycentrics
and it could be flat shading at runtime.
It's a problem when shader_info is expected to match what's actually
used.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41226>
Seems I accidentally added two copies of the same test-name in
6661c59981 ("pan/ci: add some more flakes"), with the former one
missing the last character. This didn't cause any harm, because this
doesn't match any tests. But let's clean it up.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41020>
This reverts commit d5916cb3ca.
The GL_ARB_ES3_compatibility spec, says the following:
> Issues
>
> 1) OpenGL-ES 3.0 contains several features that have been deprecated from
> the latest OpenGL Core specification. These were retained in OpenGL-ES
> 3.0 in order to provide backwards compatibility with OpenGL-ES 2.0. Those
> features are:
>
> [snip]
>
> * Legacy pixel formats - all ALPHA, LUMINANCE, LUMINANCE_ALPHA
>
> [snip]
>
> Should we bring these features back into the OpenGL 4.x Core specification
> so that it is a complete super-set of OpenGL-ES 3.0?
>
> RESOLVED: No, these will not be brought back into OpenGL 4.x Core. Apps
> written for OpenGL-ES 3.0 that want to also be compatible with OpenGL
> should make sure they don't use these features.
So, it seems pretty clear that we shouldn't have included these formats
here. So let's remove them.
Turns out, this is a CTS bug, see this for more details:
https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/6191
Fixes: d5916cb3ca ("mesa: check for ARB_ES3_compatibility in format checks")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38656>
During development of EXT_present_timing feature, we had to change
from CLOCK_MONOTONIC time domain to PRESENT_STAGE_LOCAL_EXT, and that is the only domain
reported to applications as being supported.
This case was missed when reporting the timestamps,
where applications can now get confused because we report the "actual" present timing
domain instead of PRESENT_STAGE_LOCAL_EXT as would be expected.
At the time, VVL didn't seem to catch this error in bringup-tests, but it does now.
The only known impact is some goofyness in VVL, but it's possible that some application would
have been broken by this bug.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: 47d69664d8 ("vulkan/wsi: Add common infrastructure for EXT_present_timing.")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41465>
The Vulkan spec says:
If a fragment shader entry point statically uses an input variable
decorated with a BuiltIn of SampleId or SamplePosition,
sample shading is enabled and a value of 1.0 is used instead of minSampleShading.
If a fragment shader entry point statically uses an input variable decorated
with Sample, sample shading may be enabled and a value of 1.0 will be
used instead of minSampleShading if it is.
This means we have to overwrite the command buffer state entirely.
Cc: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41482>
This toggles a single, low-value print. Let's drop it to simplify things
a bit.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41129>
This function isn't exported, so applications can't, in fact use it. So
let's simplify the internals a bit here, remove the helper.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41129>
This feature has been left to bitrot for a long time, and no longer
works consistently. Here's a few examples of things I found:
- Lots of newer GL commands never implement these
- It's very inconsistent what level of details about the command is
logged: some print arguments, some print details about arguments, some
print return-values, some print the function name, some print a
slightly incorrect function name.
- Interactions with GL_KHR_no_error is entirely random; some no-error
functions report, and some does not.
Realistically, this mechanism hasn't worked for a long time, and nobody
seems to care. If a user wants to trace what OpenGL calls are done, we
have tools like apitrace that are better suited for this purpose anyway.
Let's just rip it out. Since VERBOSE_TEXTURE is just a subset of
VERBOSE_API, rip that out as well.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41129>
Most of these flags are no longer used, so let's remove them.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41129>
This isn't very useful as-is for a few reasons:
1. It only does something in debug-builds, which is not what most users
(or application developers) is using.
2. It's undocumented.
3. Most of the information printed here is trivial to figure out with
tools like glxinfo.
4. It's missing output for platforms like x86-64 and ARM...
So let's just axe this, it's unlikely anyone uses it.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41129>
This warning effectively warns users about needless calls to
glGetGraphicsResetStatusARB(), which is nice. But it's currently gated
behind the undocumented VERBOSE_API flag, which also prints a whole lot
of API-call tracing, making this useful message drown in the noise.
So let's instead make this use the _mesa_perf_debug macro, which will
notify applications through the appropriate channels (GL_KHR_debug),
making it more likely to be picked up by developers.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41129>
This message was incorrect from the time it was introduced; the function
can return other error messages. If that happened in reality or not was
a bit more unsure, but that's not a good reason to make a blanket
statement like this. In either case, we do track properly now, and we
have for a long time.
The other, similar message in this function is correct.
Fixes: 916bc4491a ("mesa: Implement proper tracking logic for glGetGraphicsResetStatusARB")
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41129>
Caused hangs in the following CTS test with CB enabled:
dEQP-VK.renderpasses.dynamic_rendering.primary_cmd_buff.random.seed1_geometry_tessellation_multiview
Fixes: 50cc9c723c ("tu/u_trace: Prevent cloning stale RB_DONE_TS results")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41490>
