This commit adds RGB565 format to XVideo with reuse of RGBA32 shader
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>
This commit adds RGBA32 format to XVideo along with shader for handling it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>
This commit adds UYVY format in XVideo for Glamor
along with shader support.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
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>
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>
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>
The recent commit a563f530 - "glamor/glxprov: Stop exposing non-db
(-capable) configs" was aiming at reducing the number of advertised
visuals for optimizing GLX initialization.
Unfortunately, GL applications which rely exclusively on single-buffered
visuals will fail to find a suitable visual with this.
Revert the commit to expose the single-buffered visuals and restore the
compatibility with applications which rely on single-buffered configs.
This reverts commit a563f530f6
Signed-off-by: Konstantin <ria.freelander@gmail.com>
Xephyr now gained an ability to use glamor glx provider.
Unfortunately, without DRI3, we end up with same llvmpipe as before
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
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>
This code is almost entirely ddx-agnostic already, and I'd like to use
it from the other EGL glamor consumers. Which, right now that's just
Xorg, but soon it'll be Xephyr too.
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>
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>
This allows to choose between Glamor on OpenGL and Glamor on OpenGL ES
via an option.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
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>
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>
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>
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>
Consider the following window hierarchy, from ancestors to descendants:
A
|
B
|
C
If both A & C have depth 32, but B has depth 24, C must effectively
behave as if it had depth 24, even if its backing pixmap has depth 32
as well.
Fixes the xmag issue described in the GitLab issue below.
Issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1564
It's needed for a depth 24 window backed by a depth 32 pixmap, to make
sure the window's pixels sample alpha as 1.0.
v2:
* Make sure glamor_finish_access doesn't pass in a NULL pointer.
Pass the DrawablePtr directly from glamor_finish_access to
glamor_upload_boxes. This will allow for better results if the window
depth doesn't match the backing pixmap depth.
The functions glamor_egl_fd_from_pixmap()/glamor_egl_fds_from_pixmap()
are not available without GBM support.
So if GBM is not available or too old, the code would fail to link
trying to find the references to those functions.
Make sure we skip that code when glamor is built without GBM.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
`glamor_make_current` is always called before any calls to GL.
Apply some dirty-tracking to whenever we call `glamor_make_current` so
that we can avoid a decent amount of redundant GL work on each
Dispatch cycle.
Gamescope previously was waking up an empty Xwayland server with an
XQueryPointer and I noticed a significant amount of churn doing
redundant GL work.
This has been addressed on the Gamescope side as well, but avoiding any
useless GL context switches and flushes when glamor is doing nothing
is still beneficial for CPU and power usage on portable devices.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Emma Anholt <emma@anholt.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com
This updates rootless to treat pixmaps consistently with COMPOSITE,
using the screen_x and screen_y values rather than doing hacky math.
This will allow for proper bounds checking on a given PixmapRec.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
There are systems where softpipe is the default renderer,
e.g. when llvmpipe is not is not available. Using glamor
on such systems is never a good idea.
This mirrors what commit 0a9415cf79
did for llvmpipe.
Closes: #1417
Signed-off-by: Ivan A. Melnikov <iv@altlinux.org>
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>
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>
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>
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>
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>
The virgl driver exposes the name of the host renderer which might be llvmpipe.
In this case we still need glamor to be initialized.
Only check if the renderer starts with llvmpipe (which is what llvmpipe exposes).
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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>
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>
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()")
This is not actually a change for xwayland with gbm, or for xfree86 with
big-GL, but we do change them as well to use EGL_NO_CONFIG_KHR
explicitly.
Reviewed-by: Emma Anholt <emma@anholt.net>
There's no real benefit to using GLX, and the other DDXes are using EGL
already, so let's converge on EGL so we can concentrate the fixes in one
place.
We go to some effort to avoid being the thing that requires libX11 here.
We prefer EGL_EXT_platform_xcb over _x11, and if forced to use the
latter we'll ask the dynamic linker for XGetXCBConnection and
XOpenDisplay rather than link against xlib stuff ourselves. Xephyr is
now a pure XCB application if it can be.
Reviewed-by: Emma Anholt <emma@anholt.net>
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>
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>
Alexey
Yuriy Vasilev
Konstantin
Adam Jackson
Balló György
Jeffy Chen
Michel Dänzer
Olivier Fourdan
Joshua Ashton
Dave Airlie
Jeremy Huddleston Sequoia
Ivan A. Melnikov
Vasily Khoruzhick
Corentin Noël
Lucas Stach
Jonathan Gray
Povilas Kanapickas
Mario Kleiner
Zoltán Böszörményi
Jose Maria Casanova Crespo
Alex Goins
Alan Coopersmith
Lubomir Rintel
Kenneth Graunke
Dor Askayo
Hans de Goede
Emil Velikov
Eric Anholt
Paul Kocialkowski
Rohan Garg
Michel Dänzer