Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_render.c:1577:21:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 6a4ec30af4)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_dash.c:152:10:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit c6522229b8)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
We know that if gc->tileIsPixel is false, then gc->tile.pixmap must be
a valid pixmap, but gcc's static analyzer doesn't and needs to be told.
Silences false positive reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_core.c:205:19:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit a79bdc495e)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
Unlike GetPictureScreen(), GetPictureScreenIfSet() checks if the
private key is registered, and returns NULL if it is not.
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor.c:926:5:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘ps’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 69b48423bd)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>
This reverts commit 0a1ee643b2.
This is causing a number of regressions on existing setups:
* Reverse PRIME with the NVIDIA proprietary driver, where software
rendering is used instead of the NVIDIA GLX library with hardware
acceleration
* Performance issues with AMDGPU
* Rendering with 10-bit output with AMDGPU
Revert the change that is causing these regressions in the stable branch.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1848
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2104>
The EXT_blend_func_extended extension on ESSL always requires explicit
request to allow two FS out variables because of limitations of the ESSL
language, which is mentioned as the No.6 issue of the extension's
specification.
Fix this by adding the extension request.
The original behavior on GLES3 is slightly against the specification of
GL_EXT_blend_func_extended extension, however Mesa and older version of
PowerVR closed drivers will just ignore this issue. Newest PowerVR
closed driver will bail out on this problem, so it deems a fix now.
Fixes: ee107cd491 ("glamor: support GLES3 shaders")
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
(cherry picked from commit eba15f1ba7)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
The supported color depths is a hardcoded list for now, so we
need to honor the value exposed there otherwise we'll get
inconsistencies between what glXGetFBConfigs and XListDepths
report to applications.
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
(cherry picked from commit 5397854877)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
This way the caller knows if the conversion failed.
While at it, check for width/height at the same time.
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
(cherry picked from commit 87afcc7699)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
This rewrites the shader so that we use the same (more flexible) CSC as
we have for I420 and NV12. This also fixes the reverse of odd/even which
caused chroma shift.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
(cherry picked from commit 39c8a6f367)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
UYVY videos should be aligned by 2 to avoid breakups in the shader
Fixes: 832b392f7 - glamor: xv: enable UYVY acceleration
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
(cherry picked from commit eb26f32368)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
Check actual BPP by render_format in upload_boxes, not by drawable BPP.
It is required when we used different BPP formats for storing and
rendering (for example, in the case of UYVY).
The problem of UYVY size lies inside method of glamor downloading boxes.
When we set GLAMOR_CREATE_FORMAT_CBCR, it actually uses 16-bit GL and
Pixman formats, but before this change in glamor_download_boxes, that
function deduces GL and Pixman formats from BPP, which is wrong in this
case (will be deduced to 32).
When GL and Pixman format BPP is identical to drawable BPP, this change
does nothing, but when it is different - it will prioritize Pixman
format, not the format deduced from BPP.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1730
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
(cherry picked from commit 75f56b7923)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
As a preparation to one-plane formats (for example, UYVY), second
texture definition is moved inside a format switch, and all allocations
now also done inside a texture switch.
No functional change.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
(cherry picked from commit ffd7151b10)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
Xv currently calls glamor_xv_free_port_data at the end of every putImage.
This leads to shader recompilation for every frame, which is a huge performance loss.
This commit changes behaviour of glamor_xv_free_port_data, and its now is called only
if width, height or format is changed for xv port.
Shader management also done in a port now, because if shaders will be
stored in core glamor and try to be reused, this can lead to a bug if we
try to play 2 videos with different formats simultaneously.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
(cherry picked from commit 81ef43dd4a)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
There is a no need to force a low version for XV shaders, it will
work on higher version too.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
(cherry picked from commit a8270fc5f0)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
This allows Xorg to use Glamor GLX when Glamor is requested,
and eliminates usage of DRI2 in case of Glamor.
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Emma Anholt <emma@anholt.net>
(cherry picked from commit a987fc7c36)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
This commit adds an ability to store a glvnd vendor in Glamor
structures, which can be used for initialize some vendor-based values
without hooking into DDX internals. Also this adds setting this value
into Xorg and Xwayland
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Emma Anholt <emma@anholt.net>
(cherry picked from commit 3caf7aa88d)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
It is useful to know on what context we are running, and
we need to show it into xorg.log
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
(cherry picked from commit c014f33b43)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
Some hardware (preferably mobile) working on GLES3 way faster than
on desktop GL and supports more features. This commit will allow using
GLES3 if glamor is running over GL ES, and version 3 is supported.
Changes are the following:
1. Add compatibility layer for 120/GLES2 shaders with defines in and out
2. Switch attribute and varying to in and out in almost all shaders
(aside gradient)
3. Add newGL-only frag_color variable, which defines as gl_FragColor on
old pipelines
4. Switch all shaders to use frag_color.
5. Previous commit is reverted, because now we have more than one GL ES
version, previous commit used to set version 100 for all ES shaders, which
is not true for ES 3
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
(cherry picked from commit ee107cd491)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
If texture can be uploaded to GL using glTexImage2D normally, but
cannot be read back using glReadPixels, we still can accelerate it,
but we cannot create pixmap with FBO using this texture type. So,
add a flag to avoid such creations.
This allow us to accelerate 8-bit glyph masks on GL ES 2.0, because those
masks are used only as textures, and in next stages are rendered on RGBA
surfaces normally, so, we do not need to call glReadPixels on them.
This is needed for correctly working fonts on GL ES 2.0, due to inability
to use GL_RED and texture swizzle. We should use GL_ALPHA there, and
with this format we cannot have a complete framebuffer. But completed
framebuffer, according to testing, is not required for fonts anyway.
Also it fixes all 8-bit formats for GLES2.
Fixes#1362Fixes#1411
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Martin Roukala <martin.roukala@mupuf.org>
(cherry picked from commit e573d4ca03)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
GLES3.2 spec, page 126:
> The variable gl_PointSize is intended for a shader to write
> the size of the point to be rasterized. It is measured in pixels.
> If gl_PointSize is not written to, its value
> is undefined in subsequent pipe stages.
If glamor shader is use points, we should define gl_PointSize for GLES.
On Desktop GL, it "just work" due to default gl_PointSize is 1.
As @anholt requested, define this only for minimal amount of shaders
(point and glyphbit ones), to make sure than performance will not
affected
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
(cherry picked from commit f273c960c1)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
If there is no quads to draw, then we have a possibility to call
glDrawElements with type as zero, which will generate
GL_INVALID_ENUM error. While this error is harmless, it is annoying.
Signed-off-by: Konstantin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit baaddf47d5)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
For now, it sets .version=120, which prevents shader from compiling on ES.
We just force version of shaders to be always 100 on ES, because we use
only 120 shaders on ES anyway, and all shaders works.
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
(cherry picked from commit dcba460af3)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
ARB_blend_func_extended may be exposed even without GLSL 1.30.
In order to use it we need GLES2 shaders that are available if
ARB_ES2_compatibility is exposed.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
(cherry picked from commit 05b8401eeb)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
In GLES2, we cannot do GL_RED or GL_RG without GL_EXT_texture_rg.
So, add check for GL_EXT_texture_rg to make it working. Also add
a yuv2 pixman format into render.h to make Xv yuv rendering works.
Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
(cherry picked from commit 65392d27d7)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
glUniformMatrix3fv is used with argument transpose set to GL_TRUE.
According to the Khronos OpenGL ES 2.0 pages transpose must be GL_FALSE.
Actually we can just return transformed matrix from
_glamor_gradient_convert_trans_matrix (@anholt suggest),
so @uvas workaround is not required
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
(cherry picked from commit a59531533f)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
Multiplanar GBM buffers can point to different objects from each plane.
Use the _for_plane API when possible to retrieve the correct prime FD
for each plane.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Simon Ser <contact@emersion.fr>
Tested-by: Guido Günther <agx@sigxcpu.org>
(cherry picked from commit e5b09f7a2c)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
Check the fd for validity before giving a success return code.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Simon Ser <contact@emersion.fr>
Tested-by: Guido Günther <agx@sigxcpu.org>
(cherry picked from commit 95944e2b99)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1636>
If glamor_link_glsl_prog() fails, we may jump to the failed code path
which frees the variable vs_prog_string and fs_prog_string.
But those variables were already freed just before, so in that case we
end up freeing the memory twice.
Simply move the free at the end of the success code path so we are sure
to free the values only once, either in the successful of failed code
paths.
Fixes: 2906ee5e4 - glamor: Fix leak in glamor_build_program()
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 34ea020344)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1767>
For 24 and 32 bit depth pictures xserver uses PICT_x8r8g8b8 and PICT_a8r8g8b8 formats,
which must be backed with GL_BGRA format. It is present in OpenGL ES 2.0 only with
GL_EXT_texture_format_BGRA8888 extension. We require such extension in glamor_init,
so, why not to make use of it?
Fixes#1208Fixes#1354
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
(cherry picked from commit 24cd5f34f8)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1546>
