Commit Graph

993 Commits

Author SHA1 Message Date
Konstantin baaddf47d5 glamor: fixes GL_INVALID_ENUM errors on ES if there is no quads
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>
2023-09-19 13:42:34 +03:00
Michel Dänzer d1f142891e glamor: Ignore destination alpha as necessary for composite operation
If the destination drawable is a window with effective depth 24 backed
by a depth 32 pixmap.

Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1575
2023-09-12 16:57:16 +02:00
Michel Dänzer d4e11f4c92 glamor: Make glamor_solid_boxes take a DrawablePtr
Instead of a PixmapPtr. Gives better results if the window depth
doesn't match the backing pixmap depth.

Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1565
2023-07-20 10:14:56 +02:00
Michel Dänzer 3e044b1e64 glamor: Add and use glamor_drawable_effective_depth helper
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
2023-07-20 10:14:56 +02:00
Michel Dänzer 16aa40f1c8 glamor: Use DrawablePtr in struct copy_args
Will give better results if the window depth doesn't match the backing
pixmap depth.
2023-07-18 09:34:39 +00:00
Michel Dänzer 5371690891 glamor: Fix up alpha channel if needed in glamor_upload_boxes
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.
2023-07-18 09:34:39 +00:00
Michel Dänzer 78e0bb500e glamor: glamor_prep_pixmap_box → glamor_prep_drawable_box
Pass the DrawablePtr directly to glamor_download_boxes. This will allow
for better results if the window depth doesn't match the backing pixmap
depth.
2023-07-18 09:34:39 +00:00
Michel Dänzer ff27ffa1c1 glamor: Eliminate glamor_fini_pixmap
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.
2023-07-18 09:34:39 +00:00
Michel Dänzer a504f65d89 glamor: Take DrawablePtr instead of PixmapPtr in up/download_boxes
Will allow for better results if the window depth doesn't match the
backing pixmap depth.
2023-07-18 09:34:39 +00:00
Michel Dänzer 5893de5a22 glamor: Make program APIs take DrawablePtrs instead of PixmapPtrs
Will give better results if the window depth doesn't match the backing
pixmap depth.
2023-07-18 09:34:39 +00:00
Michel Dänzer 0ed2d69217 glamor: Remove unused transfer functions
Never used AFAICT.
2023-07-18 09:34:39 +00:00
Olivier Fourdan c24910d0e1 glamor: Fix build without GBM
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>
2023-04-12 10:27:32 +02:00
Joshua Ashton 89163917e1 glamor: Don't glFlush/ctx switch unless any work has been performed
`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
2023-03-17 12:38:23 +00:00
Dave Airlie 86598739ba glamor: handle EXT_gpu_shader4 in dual source blend paths
Fixes: a955286869 ("glamor: add EXT_gpu_shader4 support")
Acked-by: Emma Anholt <emma@anholt.net>
2023-02-10 07:38:11 +10:00
Jeremy Huddleston Sequoia 16e7cdba48 rootless: Use screen_x and screen_y instead of pixmap pointer hacks
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>
2023-01-20 17:10:54 +00:00
Ivan A. Melnikov 711d491729 glamor: Don't initialize on softpipe
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>
2023-01-19 20:06:04 +00:00
Konstantin dcba460af3 glamor: fix XVideo run with GLES
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>
2022-12-01 08:41:57 +00:00
Vasily Khoruzhick 05b8401eeb glamor: use dual source blend on GL 2.1 with ARB_ES2_compatibility
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>
2022-12-01 08:41:57 +00:00
Yuriy 65392d27d7 glamor: fix CbCr format handling
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>
2022-12-01 08:41:57 +00:00
Konstantin a59531533f glamor: transpose gradients transparently
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>
2022-12-01 08:41:57 +00:00
Konstantin 24cd5f34f8 glamor: make use of GL_EXT_texture_format_BGRA8888
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 #1208
Fixes #1354

Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
2022-12-01 08:41:57 +00:00
Corentin Noël fdebbc60d8 glamor: Only check for llvmpipe renderer
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>
2022-11-30 21:52:47 +00:00
Lucas Stach e5b09f7a2c glamor_egl: properly get FDs from multiplanar GBM BOs
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>
2022-10-28 12:38:20 +00:00
Lucas Stach 95944e2b99 glamor_egl: handle fd export failure in glamor_egl_fds_from_pixmap
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>
2022-10-28 12:38:20 +00:00
Jonathan Gray 5ac6319776 glamor: fix free of uninitialised pointers
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()")
2021-12-03 20:54:46 +11:00
Povilas Kanapickas c97397dc47 Remove autotools support
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
2021-10-27 13:15:40 +03:00
Adam Jackson ecdf21035e glamor: Assume EGL in glamor_context
Reviewed-by: Emma Anholt <emma@anholt.net>
2021-09-15 19:14:23 +00:00
Adam Jackson 7d5b4c5405 glamor: Require EGL_KHR_no_config_context
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>
2021-09-15 19:14:23 +00:00
Adam Jackson ea92cd2272 glamor: Don't open-code epoxy_glsl_version()
Reviewed-by: Emma Anholt <emma@anholt.net>
2021-09-15 19:14:23 +00:00
Adam Jackson 07fa12ad1d ephyr/glamor: Port to EGL
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>
2021-09-15 19:14:23 +00:00
Olivier Fourdan 2906ee5e4a glamor: Fix leak in glamor_build_program()
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>
2021-09-15 11:06:44 +02:00
Povilas Kanapickas e59e24c877 glamor: Fix handling of 1-bit pixmaps
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>
2021-09-09 23:59:06 +00:00
Mario Kleiner 7c63c582a1 Revert "glamor: Enable modifier support for xfree86 too"
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>
2021-09-01 18:51:02 +00:00
Zoltán Böszörményi fb5322ce28 glamoregl: Initialize glamor on the main device
This allows e.g. an UDL device (driven by llvmpipe) to be automatically
set up with GPU acceleration via reverse PRIME.

The result is e.g.:

  # DISPLAY=:0.2 xrandr --listproviders
  Providers: number : 2
  Provider 0: id: 0xec cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 1 outputs: 1 associated providers: 1 name:modesetting
  Provider 1: id: 0x12c cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 1 name:Intel

Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
2021-07-30 00:27:39 +00:00
Dave Airlie a955286869 glamor: add EXT_gpu_shader4 support
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>
2021-07-07 08:42:09 +10:00
Dave Airlie a2f5b917f5 glamor: add glamor_glsl_has_ints wrapper
This should make adding gpu shader4 support cleaner

Reviewed-by: Adam Jackson <ajax@redhat.com>
2021-07-07 08:41:50 +10:00
Jose Maria Casanova Crespo 9adb13e296 glamor: Avoid using GL_QUADS on V3D
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>
2021-06-14 21:36:13 +02:00
Olivier Fourdan 3b265c59a6 glamor: Dump backtrace on GL error
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
2021-05-11 14:08:58 +02:00
Alex Goins 7a7e55c5c1 glamor: Update pixmap's devKind when making it exportable
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>
2020-11-04 10:21:11 -08:00
Michel Dänzer add3df2001 Consolidate fourcc.h
Move the copy in hw/xfree86/common to include/, and remove the one in
hw/kdrive/src/.

Fixes DIX glamor code including an xfree86 DDX header.
2020-09-15 11:43:16 +02:00
Michel Dänzer 032af35657 glamor: Fix glamor_poly_fill_rect_gl xRectangle::width/height handling
(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>
2020-08-24 17:39:34 +02:00
Adam Jackson b22b4da980 glamor: Fix debugging callback setup on GLES
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>
2020-08-18 21:53:20 +00:00
Alan Coopersmith 23e83724df Fix spelling/wording issues
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>
2020-07-05 13:07:33 -07:00
Lubomir Rintel 26004df63c glamor_egl: Reject OpenGL < 2.1 early on
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>
2020-01-08 15:20:10 +00:00
Michel Dänzer 5bfca0038e glamor: Only use dual blending with GLSL >= 1.30
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>
2019-12-20 12:35:28 +01:00
Kenneth Graunke 195c2ef8f9 glamor: Add a function to get the driver name via EGL_MESA_query_driver
This maps to eglGetDisplayDriverName if EGL_MESA_query_render is
supported, otherwise it returns NULL.
2019-11-26 01:13:45 -08:00
Dor Askayo ebf549db2d glamor: make sure the correct FBO is cleared
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>
2019-11-22 17:12:03 +01:00
Dor Askayo 0e9a0c203c xwayland: clear pixmaps after creation in rootless mode
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>
2019-11-07 12:25:42 +01:00
Hans de Goede 741bd73429 glamor/xwayland: Define EGL_NO_X11
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>
2019-11-04 20:49:33 +01:00
Michel Dänzer 535f14656a Revert https://gitlab.freedesktop.org/xorg/xserver/merge_requests/235
Caused assertion failures / crashes with Xorg.

Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/916
2019-10-14 12:48:24 +02:00