From OpenGL spec 8.6
"An INVALID_OPERATION error is generated if the object bound to
READ_FRAMEBUFFER_BINDING is framebuffer complete and its effective
value of SAMPLE_BUFFERS (see section 9.2.3.1) is one"
But some games might do this
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8425
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Illia Polishchuk <illia.a.polishchuk@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22147>
Some apps use glDiscardFramebuffer()/glInvalidateFramebuffer() when they
only kidding. Add a knob to disable that.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21916>
Also rename:
iface -> drawable
stfb -> drawable (where it means dri_drawable and not st_framebuffer)
stfbi -> drawable or pdrawable (if drawable exists)
pipe_frontend_drawable* is really just dri_drawable* for DRI, and WGL/GLX
have their own variants. This makes it easier to understand what kind of
object is being used.
I always wondered what st_framebuffer_iface, iface, stfbi, iface_stamp,
and iface_ID actually mean. Now those terms are gone forever.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20027>
This is the only one implemented by mesa/state_tracker.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20027>
Oh you didn't know that st_context had a screen object too?
Yeah, this code is full of surprises.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20027>
st_context_attribs is moved into st_context.h.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20027>
where PIPE_CONTEXT_* flags are available
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20027>
st_context_iface was the base class that st_context inherited.
Just use st_context.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20027>
It's equal to fscreen, which is almost next to it.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20027>
st_manager is really the base class of dri_screen, so let's call it
pipe_frontend_screen. That's a much better name than the vague "st_manager".
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20027>
Hopefully this doesn't break anything.
There are a lot of places that invalidate drawables, but no place attempted
to call the context directly like this. A few places don't even have
the context.
Explanation:
The DRI frontend uses a global atomic counter per drawable that is
incremented when that drawable changed buffers.
st_manager_validate_framebuffers checks for that atomic counter and
updates the framebuffer state if there is any change. This was called at
every state update, so likely before almost every draw (!!!).
This commit changes that. Everything is the same except that the change
of buffers will not be noticed until the beginning of the next frame or
when the framebuffer state update is triggered by something else.
The effect is that we don't waste time calling
st_manager_validate_framebuffers a million times per frame.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19775>
It's a global variable and have no need destroy
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19197>
As it's only accessed in st_manager.c, there is no need expose it
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19197>
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>
This patch plumbs the YUV color space and range provided through
EGL_EXT_image_dma_buf_import all the way to nir_lower_tex().
NIR already accounts for the YUV color space courtesy of commit
d8fdb8da. However, the color space was wired only for i965/i915 (see
6c11a799) and not for Gallium.
Tested-by: Andres Calderon Jaramillo <andrescj@chromium.org>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16651>
This allows us to force all shaders to offer shader features only
provided to compatibility shaders.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14040>
This allows specific per-application override.
The existing MESA_EXTENSION_OVERRIDE env variable is kept.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13364>
The GLSL spec says it's an error if a shader statically writes to these
2 variables.
Until this commit, Mesa refused to link a shader if it had an unused
function writing to one of these variables while another (used) function
wrote to the other.
This commit adds an option to perform dead function elimination after
the intra-stage linking step but before performing these checks.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12897>
This is basically the same workaround as in 9b577f2a88 (driconf, glsl: Add a
vs_position_always_invariant option) commit but for tesselation evaluation
shaders. Some applications do not mark outputs as precise in tesselation
evaluation shaders which can lead to different results in case some
optimizations were applied.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
Fixes: 09705747d7 ("nir/algebraic: Reassociate fadd into fmul in DPH-like pattern")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13027>
For being used by mesa state tracker.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12336>
This is similar to the transcode_etc flag in that it changes the ASTC
fallback (when present) to use DXT5 instead of RGBA8888. This reduces
the memory footprint of the app at the expense of a bit of correctness.
Because it's not quite correct, it's hidden behind a driconf option.
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10476>
The gallium context creation API embeds storage for a whole st_visual
even if the context is to have no config. no_config was being used to
signal this, but we can just as easily check that the color format is
non-NONE.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10045>
