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>
Like in 0e3f1252da ("glamor: Avoid using GL_QUADS on VC4")
this will avoid mesa to fallback doing conversion for QUADS primitives.
Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Currrently, when a GL error is triggered, glamor would log the error
which may not be sufficient to trace it back to the cause of the error.
Also dump the backtrace which may give more information as to where the
error comes from.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
When making a pixmap exportable, glamor will currently create a temporary
exported pixmap backed by a GBM bo, with the devKind updated to the stride of
the bo. However, when the backing of the exported pixmap is swapped into the
original, the devKind of the original is not updated.
Some GBM bos may get implicitly padded, in which case the devKind of the pixmap
will not match the stride of the backing bo. For example, an 800x600 pixmap will
have a devKind of 3200, but the bo's stride will be 3328. This can cause
corruption with PRIME, when the sink uses the wrong stride to display the shared
pixmap.
This commit changes glamor_make_pixmap_exportable() to update the devKind of the
original pixmap after it swaps exported pixmap's backing into it, keeping
everything consistent.
Fixes issue #1018.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(Using GLSL 1.30 or newer)
The width/height members of xRectangle are unsigned, but they were
being interpreted as signed when converting to floating point for the
vertex shader, producing incorrect drawing for values > 32767.
v2:
* Use separate GL_UNSIGNED_SHORT vertex attribute for width/height.
(Eric Anholt)
Reviewed-by: Eric Anholt <eric@anholt.net>
You will not find GL_ARB_* extensions in a GLES context by definition,
the droid you're looking for is named GL_KHR_debug.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Most (but not all) of these were found by using
codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The Etnaviv driver on GC2000 reports desktop OpenGL 1.3 but also OpenGL ES 2.0.
However, with the modesetting driver, GLES2 never gets a chance:
[ 11233.393] Require OpenGL version 2.1 or later.
[ 11233.393] (EE) modeset(0): Failed to initialize glamor at ScreenInit() time.
[ 11233.393] (EE)
Fatal server error:
[ 11233.395] (EE) AddScreen/ScreenInit failed for driver 0
Let's reject old desktop GL early on, just like XWayland seems to do.
This is perhaps a slightly bit more complicated that one would expect, since we
need to call eglMakeCurrent() before we query the GL version.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
It can't be used with older GLSL. Fixes a crash when attempting to
anyway.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/97
Fixes: e7308b6c77 "glamor: Add support for CA rendering in a single pass."
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This also removes an unnecesary call to glDrawBuffer.
Signed-off-by: Dor Askayo <dor.askayo@gmail.com>
Fixes: 0e9a0c20 - "xwayland: clear pixmaps after creation in rootless
mode"
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/933
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When a pixmap is created with a backing FBO, the FBO should be cleared
to avoid rendering uninitialized memory. This could happen when the
pixmap is rendered without being filled in its entirety.
One example is when a top-level window without a background is
resized. The pixmap would be reallocated to prepare for more pixels,
but uninitialized memory would be rendered in the resize offset until
the client sends a frame that fills these additional pixels.
Another example is when a new top-level window is created without a
background. Uninitialized memory would be rendered after the pixmap is
allocated and before the client sends its first frame.
This issue is only apparent in OpenGL implementations that don't zero
the VRAM of allocated buffers by default, such as RadeonSI.
Signed-off-by: Dor Askayo <dor.askayo@gmail.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/636
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Define EGL_NO_X11 everywhere were we also define MESA_EGL_NO_X11_HEADERS,
EGL_NO_X11 is the MESA_EGL_NO_X11_HEADERS equivalent for the egl headers
shipped with libglvnd.
This fixes the xserver not building with the libglvnd-1.2.0 headers:
In file included from /usr/include/EGL/eglplatform.h:128,
from /usr/include/epoxy/egl_generated.h:11,
from /usr/include/epoxy/egl.h:46,
from glamor_priv.h:43,
from glamor_composite_glyphs.c:25:
/usr/include/X11/Xlib.h:222:2: error: conflicting types for 'GC'
222 | *GC;
| ^~
In file included from glamor.h:34,
from glamor_priv.h:32,
from glamor_composite_glyphs.c:25:
../include/gcstruct.h:282:3: note: previous declaration of 'GC' was here
282 | } GC;
| ^~
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
DDX such as Xorg, Xwayland & Xephyr do not destroy the pixmap before
they call into CloseScreen. At the same time Xvfb (support for glamor
coming with later commit) do.
As such the pixmap will be NULL and we'll crash out.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
DDX such as Xorg, Xwayland & Xephyr do not destroy the pixmap before
they call into CloseScreen. At the same time Xvfb (support for glamor
coming with later commit) do.
As such the pixmap will be NULL and we'll crash out.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Currently we wrap the EGL CloseScreen/DestroyPixmap callbacks after the
glamor ones. Thus upon teardown, we'll end calling things in the wrong
order.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
As of last commit, all of glamor_egl ix xf86 agnostic, so adjust the
includes and drop the GLAMOR_FOR_XORG instances.
Note the macro is still used for glamor_xv_init() which pulls xf86.
v2: Drop GLAMOR_FOR_XORG guards (Michel Dänzer)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Currently we parse through xf86Info.debug to check if we the modifiers
should be disabled. Handle that within DDX and pass GLAMOR_NO_MODIFIERS
into the glamor_init() flags.
This allows individual DDX control over the setting - say when modifiers
are woking OK with one implementation and not the other.
Most importantly, this removes the final xf86 piece from the codebase.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Move from the xf86 specific ScrnInfoRec::privates, to the dix private
handling. Since there's no FreeScreen function in ScreenPtr, fold the
former within the existing CloseScreen.
Users, such as modesetting are updated, and out of tree drivers will
need equivalent, yet trivial, patch.
Note: we need to ensure that the screen private is unset and the screen
callbacks are restored in our CloseScreen function.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The following two members of glamor_egl_screen_private has been unused
for a little while now.
CreateScreenResources
CloseScreen
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Much of glamor already use LogMessage() so we might as well be
consistent. This effectively paves the way of making glamor-egl xf86
agnostic.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
If a pixmap is not exportable, `glamor_gbm_bo_from_pixmap()` would fail
and the modesettings driver would consequently fail to do its page flip,
which both prevents Present from working and also fill up the logs with
error messages such as:
(EE) modeset(0): Failed to get GBM bo for flip to new front.
(EE) modeset(0): present flip failed
Refactor the code so that `glamor_gbm_bo_from_pixmap()` takes care of
making the pixmap exportable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Yuxuan Shui yshui@hadean.com
See-also: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/131
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/68
Fixes: 86b2d8740a "glamor: Reallocate pixmap storage without modifiers
if necessary"
Chnage the API for `glamor_set_pixmap_texture()` to return a status,
so that the caller can know whether it succeeded or not.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Desktop GL can handle arbitrary rops here, GLES can't. The switch
statement attempts to optimize some cases that GLES can still handle if
we precompute the right pixel value, but we were then throwing that
pixel value away and using gc->fgPixel anyway. Fix this, and now
xts-render passes against glamor+gles.
We had various helper functions trying to come up with the
internalformat/format/type/render formats for pixmaps, and it's much
nicer to just detect what those should be once at startup. This gives
us a chance to do the right thing for GLES.
It also, notably, fixes our format/type for depth 15 and 16 setup for
desktop GL, so that we actually allocate 16bpp (GL_RGB/565) on most
drivers instead of 32bpp (GL_RGB/UBYTE).
GLES still has regressions over desktop (2 regressions in llvmpipe
XTS, many in rendercheck), but I think this is a good baseline.
Signed-off-by: Eric Anholt <eric@anholt.net>
For GLES, we're going to need a lot more logic for picking the
iformat/format/type of texture setup, so we'll want the pixmap's depth
and is_cbcr flag.
Signed-off-by: Eric Anholt <eric@anholt.net>
"format" is a bit of a confused term (internalformat vs GL format),
and all we really needed was "is this GL_RED?"
Signed-off-by: Eric Anholt <eric@anholt.net>
If `_glamor_create_tex()` fails to allocate the FBO because of
GL_OUT_OF_MEMORY error, the `pixmap_priv->fbo` is NULL.
However, `glamor_get_pixmap_texture()` doesn't actually check whether
the `pixmap_priv->fbo` is NULL and will segfault with a NULL pointer
dereference trying to access the `pixmap_priv->fbo->tex`.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/647
We currently support two modes of operation for RW PBO buffers: one
that allocates a pack buffer with GL memory and one that uses system
memory when the former is not supported.
Since allocation with system memory is less likely to fail, add a
fallback to system memory when GL memory failed instead of bailing
out.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
glamor_prepare_access can fail for a few reasons, especially when
failing to allocate a PBO buffer. Take this in account and bail in
the copy helpers that call the helper when a failure happens.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Packed buffer allocation (which happens at glBufferData time with the
buffer bound) can fail when there is no GL memory left.
Pick up the error when it happens, print a proper error message, do
some cleanup and bail.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
When uploading a picture to a texture, glamor_upload_picture_to_texture
calls glamor_pixmap_ensure_fbo to ensure that there is backing FBO.
The FBO will be allocated if the picture's drawable pixmap does not have
one already, which can fail when there is no GL memory left.
glamor_upload_picture_to_texture checks that the call succeeded and will
enter the failure path if it did not. However, unlike many other
functions in glamor, this one has ret set to TRUE initially, so it needs
to be set to FALSE when a failure happens.
Otherwise, the error is not propagated and the failure path return TRUE.
This leads to a fault when trying to access the FBO pointer later on.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
As long as the storage format is compatible.
v2:
* Remove explicit cases for formats handled by the default case.
Reviewed-by: Eric Anholt <eric@anholt.net>
0a9415cf apparently can tickle bugs in the GL stack where glGetString
returns NULL, presumably because the eglMakeCurrent() didn't manage to
actually install a dispatch table and you're hitting a stub function.
That's clearly not our bug, but if it happens we should at least not
crash. Notice this case and fail gently.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Mesa started supporting GL_OES_EGL_image on llvmpipe in 17.3, after this
commit:
commit bbdeddd5fd0b797e1e281f058338b3da4d98029d
Author: Gurchetan Singh <gurchetansingh@chromium.org>
Date: Tue Aug 1 14:49:33 2017 -0700
st/dri: add drisw image extension
That's pretty cool, but it means glamor now thinks it can initialize on
llvmpipe. This is almost certainly not what anyone wants, as glamor on
llvmpipe is pretty much uniformly slower than fb.
This fixes both Xorg and Xwayland to refuse glamor in such a setup.
Xephyr is left alone, both because glamor is not the default there and
because Xephyr+glamor+llvmpipe is one of the easier ways to get xts to
exercise glamor.
The (very small) downside of this change is that you lose DRI3 support.
This wouldn't have helped you very much (since an lp glamor blit is
slower than a pixman blit), but it would eliminate the PutImage overhead
for llvmpipe's glXSwapBuffers. A future change should add DRI3 support
for the fb-only case.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Olivier Fourdan
Povilas Kanapickas
Mario Kleiner
Zoltán Böszörményi
Dave Airlie
Jose Maria Casanova Crespo
Alex Goins
Michel Dänzer
Adam Jackson
Alan Coopersmith
Lubomir Rintel
Kenneth Graunke
Dor Askayo
Hans de Goede
Emil Velikov
Eric Anholt
Paul Kocialkowski
Rohan Garg
Michel Dänzer