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>
Make sure to cast with the deref type that contains more information
than the returned type because it's valid in SPIR-V.
This fixes dEQP-VK.binding_model.descriptor_heap.graphics.*_vectors and
also the PositiveGpuAV.HeapWithUntypedPointers VVL test.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41469>
We were previously assuming that potentially stale divergence data was
valid. On some paths the register pressure estimator would recalculate
this, but, as is obvious from the results, not always.
v2: Add an assertion in brw_from_nir_emit_impl to ensure we don't end
up in this situation again.
v3: Call nir_divergence_analysis from
brw_nir_lower_deferred_urb_writes. This fixes assertion failures (the
assertion added in v2) in basically every graphics shader. The
altnerative was to call it from brw_compile_vs, brw_compile_gs, and
brw_compile_tes.
shader-db:
All Intel platformms had similar results. (Lunar Lake shown)
total instructions in shared programs: 17050403 -> 17054033 (0.02%)
instructions in affected programs: 296344 -> 299974 (1.22%)
helped: 0 / HURT: 376
total cycles in shared programs: 876063126 -> 875817316 (-0.03%)
cycles in affected programs: 78627328 -> 78381518 (-0.31%)
helped: 91 / HURT: 276
LOST: 1
GAINED: 10
fossil-db:
All Intel platformms had similar results. (Lunar Lake shown)
Totals:
Instrs: 913770429 -> 916075391 (+0.25%); split: -0.00%, +0.26%
CodeSize: 14647414640 -> 14726176320 (+0.54%); split: -0.02%, +0.56%
Cycle count: 102308091527 -> 102290664775 (-0.02%); split: -0.26%, +0.24%
Spill count: 3469632 -> 3469124 (-0.01%); split: -0.08%, +0.07%
Fill count: 5007038 -> 4998674 (-0.17%); split: -0.51%, +0.34%
Max live registers: 192568853 -> 192595355 (+0.01%); split: -0.00%, +0.02%
Max dispatch width: 48713168 -> 48712880 (-0.00%); split: +0.00%, -0.00%
Non SSA regs after NIR: 140252767 -> 140253718 (+0.00%)
Totals from 223099 (11.11% of 2007586) affected shaders:
Instrs: 314077245 -> 316382207 (+0.73%); split: -0.01%, +0.75%
CodeSize: 5335583824 -> 5414345504 (+1.48%); split: -0.06%, +1.54%
Cycle count: 45868025821 -> 45850599069 (-0.04%); split: -0.58%, +0.54%
Spill count: 2062649 -> 2062141 (-0.02%); split: -0.14%, +0.11%
Fill count: 3343019 -> 3334655 (-0.25%); split: -0.76%, +0.51%
Max live registers: 36762498 -> 36789000 (+0.07%); split: -0.02%, +0.09%
Max dispatch width: 5542224 -> 5541936 (-0.01%); split: +0.03%, -0.03%
Non SSA regs after NIR: 43727142 -> 43728093 (+0.00%)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> [v1]
Fixes: 1bff4f93ca ("brw: Basic infrastructure to store convergent values as scalars")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41370>
In Gfx9 the enum value was changed to mean SIMD8 double precision, so
drop the old unused enum. At least on Gfx9 there is an extension bit
to set to use the old SIMD4x2 mode, we can recover if we ever need this
in the future.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41457>
FullyCovered will need to know if conservative rasterization is enabled,
so pass it on to the shader.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Caleb Callaway <caleb.callaway@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38879>
Add a new intrinsic to read the raw shading rate provided to the FS
payload, and lower load_frag_shading_rate in NIR using it.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Caleb Callaway <caleb.callaway@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38879>
We'll need the raw coverage mask provided to the fragment shader in a
future patch.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Caleb Callaway <caleb.callaway@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38879>
We create driver param instructions once we encounter their first use
and cache them for further uses. This creates problems when the first
use occurs in a block that doesn't dominate all further uses. This was
hit in practice with a driver param that was used both in the preamble
and in the main shader.
Fix this by simply not caching driver params. Since they are simply movs
from const regs, ir3_cp or ir3_cse should clean up most cases of
multiple uses.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 8b0b81339b ("freedreno/ir3: add NIR compiler")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15418
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41484>
Implements shader-based global blending and pre-multiplied alpha support
to YUV compositing, allowing for transparent overlays and alpha-channel
based transparency with RGBA overlays.
Handle pre-multiplied alpha images by un-multiplying the pre-multiplied
alpha colours, to allow for straight-alpha (which is easier to
implement) to be applied.
Thanks nyanmisaka for the help, and for pointing out the difference
between pre-multiplied alpha and straight alpha.
Thanks David Rosca and Benjamin Cheng for improvements to the code and
spotting errors.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/12977
Signed-off-by: Thong Thai <thong.thai@amd.com>
Reviewed-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41090>
Fix typos in the size of proj, and chroma_proj, in the GLSL pseudo-code
comment portion of cs_create_shader.
Thanks Benjamin Cheng <benjamin.cheng@amd.com> for finding it.
Signed-off-by: Thong Thai <thong.thai@amd.com>
Reviewed-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41090>
Instead of expecting just 1 address bit to be flipped by 1 coordinate bit,
expect any address bits to be flipped by 1 coordinate bit. If multiple
coordinate bits flip the same address bit, that means all those coordinate
bits are XOR'd.
v2: also print 128bpp
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41431>
It may have been accidentally left in the code.
If there is any doubt about this, then the reason is the same
as accepting screen=NULL in context_create or any other function.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41429>
