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>
Useful when video decoders only output NV12. Currently
glamor Xv only supports I420 and YV12.
Note that Intel's sna supports I420, YV12, YUY2, UYVY, NV12.
Test: xvinfo | grep NV12
Test: gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! xvimagesink
v2: Combine the two texture2Ds on u_sampler.
Signed-off-by: Julien Isorce <jisorce@oblong.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Andrea Cavalli
Zoltán Böszörményi
Dave Airlie
Jose Maria Casanova Crespo
Olivier Fourdan
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
Julien Isorce