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>
Attempting to run fvwm on a x61/965gm with xserver 1.21.1 with the
modesetting driver on OpenBSD/amd64 would cause the xserver to
reliably crash.
I tracked this down to the free() calls introduced in
2906ee5e4a
(d1ca47e124 in branch).
clang also warns about this:
glamor_program.c:296:13: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:290:9: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:288:9: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:277:13: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:296:13: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:290:9: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:288:9: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:277:13: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 2906ee5e4 ("glamor: Fix leak in glamor_build_program()")
(cherry picked from commit 5ac6319776)
Fix the possible leak of `vs_prog_string` and `fs_prog_string` in case
of failure, as reported by covscan.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 2906ee5e4a)
Since 8702c938b3 the pixmap formats are
handled in a single place. In the process of conversion the difference
between pixmap formats that can be uploaded and those that can be
rendered on GL side has been lost. This affects only 1-bit pixmaps: as
they aren't supported on GL, but can be converted to a R8 or A8 format
for rendering (see glamor_get_tex_format_type_from_pictformat()).
To work around this we add a separate flag that specifies whether the
format actually supports rendering in GL, convert all checks to use this
flag and then add 1-bit pixmap formats that don't support rendering in
GL.
Fixes: 8702c938b3
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1210
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
This reverts commit 9b89994110.
Turns out that defaulting glamor_egl->dmabuf_capable = TRUE
breaks kms page-flipping on various Mesa+Linux/DRM-KMS+hardware
combos, resulting in broken presentation timing, degraded performance
and awful tearing. E.g., my testing shows that X-Server master +
Mesa 21.2 + Linux 5.3 on Intel Kabylake has broken pageflipping.
Similar behaviour was observed in the past on RaspberryPi 4/400
with VideoCore-6 by myself and others, and iirc by myself on some
AMD gpu's, although my memories of the latter are a bit dim.
Cfe. https://gitlab.freedesktop.org/mesa/mesa/-/issues/3601 and
possibly https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/254
for related problems.
The reason for pageflip failure on the modesetting-ddx under
DRI3/Present seems to be the following sequence:
1. Atomic modesetting for the modesetting-ddx is broken and therefore
both disabled by default in the modesetting-ddx itself and also
force-disabled by the Linux kernel since quite a while. If the kernel
detects drmSetClientCap(fd, DRM_CLIENT_CAP_ATOMIC, 1); from the
X-Server, it will reject the request, as a countermeasure to all the
past and current brokeness.
2. Without DRM_CLIENT_CAP_ATOMIC we don't get the implied universal
planes support (DRM_CLIENT_CAP_UNIVERSAL_PLANES).
3. Without DRM_CLIENT_CAP_UNIVERSAL_PLANES, drmModeGetPlaneResources()
will only return overlay planes, but not primary- or cursor planes.
4. As modesetting-ddx drmmode_crtc_create_planes() function can only
operate on primary planes, but can't get any from drmModeGetPlaneResources(),
the drmmode_crtc_create_planes() mostly turns into a no-op, never
executes populate_format_modifiers() and therefore the Linux kernels
DRM-KMS driver is not ever queried for the list of scanout/pageflip
capable DRM format modifiers. Iow. the drmmode_crtc->formats[i].modifiers
list stays empty with zero drmmode_crtc->formats[i].num_modifiers.
5. The list from step 4 provides the format+modifiers for intersection
which would get returned by the X-Servers DRI3 backend as response to
a xcb_dri3_get_supported_modifiers_window_modifiers() request. Given
an empty list was returned in step 4, this will lead to return of an
empty modifiers list by xcb_dri3_get_supported_modifiers_window_modifiers().
6. Both Mesa's DRI3/Present OpenGL backbuffer allocation logic and iirc
Mesa/Vulkan/WSI/X11's swapchain image allocation logic use the list
from xcb_dri3_get_supported_modifiers_window_modifiers() for format+
modifier selection for scanout/pageflip capable buffers. Cfe. Mesa's
dri3_alloc_render_buffer() function.
Due to the empty list, the Mesa code falls back to the format+modifiers
reported by xcb_dri3_get_supported_modifiers_screen_modifiers()
instead. This list contains all modifiers reported by GLAMOR as
result of glamor_get_formats() and glamor_get_modifiers(), which
in turn are query results from Mesa eglQueryDmaBufFormatsEXT()
and eglQueryDmaBufModifiersEXT(). Iow. all format+modifiers which
are supported for rendering are considered for the OpenGL backbuffers
and Vulkan swapchain buffers.
7. Depending on kms driver + gpu combo and Mesa version, such buffers
are often not direct-scanout / pageflip capable, and so pageflipping
can't be used for DRI3/Present of fullscreen windows. Whenever the
system has to fallback to copies instead of pageflips, the results
are broken presentation timing, degraded performance and quite
horrible tearing, as the current DRI3/Present implementation does not
perform any hardware synchronization of copy presents to the start
of vblank or similar.
By defaulting glamor_egl->dmabuf_capable = FALSE instead, as the server
1.20 branch does, we avoid this failure:
1. glamor_get_modifiers() turns into a no-op and returns false, not
reporting any supported dmabuf modifiers to the servers DRI3 code,
ie. the servers cache_formats_and_modifiers() function can't retrieve
and cache any format+modifiers. Therefore the servers DRI3 code now
also reports an empty format+modifiers list when Mesa does a
xcb_dri3_get_supported_modifiers_screen_modifiers() query.
2. Mesa's buffer allocation code therefore falls back to using the old
DRI image extensions createImage() function to allocate buffers
with use flags __DRI_IMAGE_USE_SCANOUT | __DRI_IMAGE_USE_BACKBUFFER
and our OpenGL backbuffers / Vulkan swapchain images get allocated
in a direct-scanout / pageflip capable format. Pageflipping works,
timing and performance is good, presentation is tear-free.
Please consider merging this for branching the X-Server 1.21 branch.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
This enables a number of the GLSL 1.30 paths on GPUs that have
EXT_gpu_shader4 but don't have GLSL 1.30 exposed.
(Intel gen4/5 mainly)
Reviewed-by: Adam Jackson <ajax@redhat.com>
