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
Allow to upload the CbCr plane of an NV12 image into a GL texture.
Signed-off-by: Julien Isorce <jisorce@oblong.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
When support for allocating GBM BOs with modifiers was added,
glamor_fd_from_pixmap() was changed so that it would return an error if
it got a bo with modifiers set from glamor_fds_from_pixmap(). The
problem is that on systems that support BOs with modifiers,
glamor_fds_from_pixmap() will always return BOs with modifiers.
This means that glamor_fd_from_pixmap() was broken entirely, which broke
a number of other things including glamor_shareable_fd_from_pixmap(),
which meant that modesetting using multiple GPUs with the modesetting
DDX was also broken. Easy reproducer:
- Find a laptop with DRI prime that has outputs connected to the
dedicated GPU and integrated GPU
- Try to enable one display on each using the modesetting DDX
- Fail
Since there isn't a way to ask for no modifiers from
glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap()
function used by both glamor_fds_from_pixmap() and
glamor_fd_from_pixmap() that calls down to the appropriate
glamor_egl_fd*_from_pixmap() function.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
glamor_fds_from_pixmap returns 0 on error, but we were treating that as
success, continuing with uninitialized stride and fd values.
Also bail if the offset isn't 0, same as in dri3_fd_from_pixmap.
v2:
* Reduce to a simple one-liner fix (Emil Velikov)
Fixes: c8c276c956 "glamor: Implement PixmapFromBuffers and
BuffersFromPixmap"
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
This matches what glamor_egl_fds_from_pixmap and dri3_fds_from_pixmap do
and what proc_dri3_buffers_from_pixmap expects.
Fixes: c8c276c956 "glamor: Implement PixmapFromBuffers and
BuffersFromPixmap"
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Hi,
I upgraded Xwayland and the assorted libraries from git masters today,
and noticed that glamor wouldn't work anymore on i.MX6/etnaviv. The
error was:
No provider of glVertexAttribDivisor found. Requires one of:
Desktop OpenGL 3.3
OpenGL ES 3.0
GL extension "GL_ANGLE_instanced_arrays"
GL extension "GL_ARB_instanced_arrays"
GL extension "GL_EXT_instanced_arrays"
GL extension "GL_NV_instanced_arrays"
The problem is that etnaviv offers GLSL 140 on GL 2.1 and glamor
rendering assumes that glVertexAttribDivisor() is always available on
GLSL>=130, which is not the case here. Forcing GLSL 120 makes glamor
work fine again on this platform. After chatting with ajax in
#xorg-devel, the following solution was proposed.
This is my first time of submitting a patch, so please excuse me and
advise if I'm doing it wrong ;)
Cheers
Lukas (mntmn)
Reviewed-by: Eric Anholt <eric@anholt.net>
We were mixing stdint and CARD* types, causing compiler warnings on
32-bit. Just switch over to stdint, which is what we'd like the server
to be using long term, anyway.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
They're part of the 1.20 RC1 ABI, and actually used by external drivers.
Also, requiring drivers which don't support the new functionality in
DRI3 1.2 to switch to the new interfaces seems unreasonable.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Implement function added in DRI3 v1.1.
A newest version of libepoxy (>= 1.4.4) is required as earlier
versions use a problematic version of Khronos
EXT_image_dma_buf_import_modifiers spec.
v4: Only send scanout-supported modifiers if flipping is possible
v5: Fix memory corruption in XWayland (uninitialized pointer)
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
It relies on GBM >= 17.1.0 where we can import BO with multiple
planes and a format modifier (GBM_BO_IMPORT_FD_MODIFIER).
v2: Properly free fds in Xwayland
[Also add glamor_egl_ext.h to Makefile.am for distcheck's sake - ajax]
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This makes it work properly with OpenGL based desktop
compositing, as tested with EGL and GLX based compositing
under OpenGL-2/3, and also artifact free with XRender
based 2D compositing.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
GLES spells this extension as GL_OES_vertex_array_object, but it is
functionally equivalent to the GL_ARB version. Mesa has supported both
since 9.0, let's go ahead and require it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
text data bss dec hex filename
2134764 45210 128704 2308678 233a46 build/hw/kdrive/ephyr/Xephyr.before
2129972 45210 128704 2303886 23278e build/hw/kdrive/ephyr/Xephyr.after
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Improves Raspberry Pi 3 x11perf -copywinwin500 from ~480/sec to
~700/sec.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
All that was left here was updating the FBO's size. However, the FBO
size was always set correctly already through
glamor_set_pixmap_texture() from whoever had attached a new BO to the
pixmap.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This means we no longer get "s" for on-screen drawing in glamor_debug,
and there's only "m" (CPU memory) or "f" (Any GPU memory, aka FBOs).
That seems fine to me.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
glamor_create_pixmap() would return a NullPixmap if the given size is
larger than the maximum size of a pixmap.
But glamor_get_pixmap_texture() won't check if the given pixmap is
non-null, leading to a segfault if glamor_create_pixmap() failed.
This can be reproduced by passing Xephyr a very large screen width,
e.g.:
$ Xephyr -glamor -screen 32768x1024 :10
(EE)
(EE) Backtrace:
(EE) 0: Xephyr (OsSigHandler+0x29)
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
(EE) 2: Xephyr (glamor_get_pixmap_texture+0x30)
(EE) 3: Xephyr (ephyr_glamor_create_screen_resources+0xc6)
(EE) 4: Xephyr (ephyrCreateResources+0x98)
(EE) 5: Xephyr (dix_main+0x275)
(EE) 6: /lib64/libc.so.6 (__libc_start_main+0xf1)
(EE) 7: Xephyr (_start+0x2a)
(EE) 8: ? (?+0x2a) [0x2a]
(EE)
(EE) Segmentation fault at address 0x0
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
Aborted (core dumped)
Bugzilla: https://bugzilla.redhat.com/1431633
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
In glamor_init(), if the minimum requirements are not met, glamor may
fail after setting up its own CloseScreen() and DestroyPixmap()
routines, leading to a crash when either of the two routines is called
if glamor failed to complete its initialization, e.g:
(EE) Backtrace:
(EE) 0: Xwayland (OsSigHandler+0x29)
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
(EE) 2: Xwayland (glamor_sync_close+0x2a)
(EE) 3: Xwayland (glamor_close_screen+0x52)
(EE) 4: Xwayland (CursorCloseScreen+0x88)
(EE) 5: Xwayland (AnimCurCloseScreen+0xa4)
(EE) 6: Xwayland (present_close_screen+0x42)
(EE) 7: Xwayland (dix_main+0x4f9)
(EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf1)
(EE) 9: Xwayland (_start+0x2a)
Restore the previous CloseScreen() and DestroyPixmap() vfunc handlers in
case of failure when checking for the minimum requirements, so that if
any of the requirement is not met we don't leave the CloseScreen() and
DestroyPixmap() from glamor handlers in place.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1390018
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The extension came out in 2000, and all Mesa-supported hardware that
can do glamor supports it. We were already relying on the ARB version
being present on desktop.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
glUniform4ui is available starting in GL{,ES} 3.0. Technically it's
also in EXT_gpu_shader4, but that's not worth supporting. There was also
a MESA_shading_language_130 spec proposed at one point; if that ever
gets finished, we can update epoxy to know about it and fix up the
feature check.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This function is used by the modesetting driver to implement DRI2 and
shouldn't fail on systems that don't support DRI3.
v2: Drop stale commit message wording, fix compiler warning (by anholt)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Add glamor_shareable_fd_from_pixmap function to get dma-buf fds suitable
for sharing across GPUs (not using GPU specific tiling).
This is necessary for the modesetting driver to correctly implement
the DRI2 SharePixmapBacking callback.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
With no users of the interface needing the readmask anymore, we can
remove it from the argument passed to these functions.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
It is a modest performance improvement (2.7% on Intel), with the
significant downside that it keeps extra pixmap contents laying around
for 1000 BlockHandlers without the ability for the system to purge
them when under memory pressure, and tiled renderers don't know that
we could avoid reading their current contents when beginning to render
again. We could use the FB invalidate functions, but they aren't
always available, aren't hooked up well in Mesa, and would eat into
the performance gains of having the cache.
[ajax: rebased to master]
Reviewed-by: Adam Jackson <ajax@redhat.com>
The screen block and wakeup handlers are the only ones which provide a
well known ordering between the wrapping layers; placing these as
close as possible to the server blocking provides a way for the driver
to control the flow of execution correctly.
Switch the shadow code to run in the screen block handler so that it
now occurrs just before the server goes to sleep.
Switch glamor to call down to the driver after it has executed its own
block handler piece, in case the driver needs to perform additional
flushing work after glamor has called glFlush.
These changes ensure that the following modules update the screen in
the correct order:
animated cursors (uses RegisterBlockAndWakeupHandlers dynamically)
composite (dynamic wrapping)
misprite (dynamic wrapping)
shadow (static wrapping)
glamor (static wrapping)
driver (static wrapping)
It looks like there's still a bit of confusion between composite and
misprite; if composite updates after misprite, then it's possible
you'd exit the block handler chain with the cursor left hidden. To fix
that, misprite should be wrapping during ScreenInit time and not
unwrapping. And composite might as well join in that fun, just to make
things consistent.
[v2] Unwrap BlockHandler in shadowCloseScreen (ajax)
[v3] ephyr: Use screen block handler for flushing changes
ephyr needs to make sure it calls glXSwapBuffers after glamor finishes
its rendering. As the screen block handler is now called last, we have
to use that instead of a registered block/wakeup handler to make sure
the GL rendering is done before we copy it to the front buffer.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
A1 and A8 pixmaps are usually stored in the Red channel to conform
with more recent GL versions. When using these pixmaps as mask values,
that works great. When using these pixmaps as source values, then the
value we want depends on what the destination looks like.
For RGBA or RGB destinations, then we want to use the Red channel
for A values and leave RGB all set to zero.
For A destinations, then we want to leave the R values in the Red
channel so that they end up in the Red channel of the output.
This patch adds a helper function, glamor_bind_texture, which performs
the glBindTexture call along with setting the swizzle parameter
correctly for the Red channel. The swizzle parameter for the Alpha
channel doesn't depend on the destination as it's safe to leave it
always swizzled from the Red channel.
This fixes incorrect rendering in firefox for this page:
https://gfycat.com/HoarseCheapAmericankestrel
while not breaking rendering for this page:
https://feedly.com
v2: Add change accidentally left in patch for missing
glDisable(GL_COLOR_LOGIC_OP).
Found by Emil Velikov <emil.l.velikov@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63397
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Some drivers are calling glFinish, they really should be doing this.
This also is needed for some reverse prime scenarios.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
For pictures without alpha, and for most other formats for GLES2, we
would make a temporary FBO, make another temporary texture, upload our
GLAMOR_MEMORY pixmap to the texture, then run the "finish access" shader
across it to swizzle its values around into the temporary FBO (which we
would use for a single Render operation and then throw away).
We can simplify everything by using GL_ARB_texture_swizzle (or its
GLES3 counterpart). It's just not worth the complexity to try to
improve the performance of this already low-performance path (SHM
pixmaps + Render) on GLES2.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Glamor works out from the profile if it is
core.
This flag is used to disable quads for rendering.
v1.1: split long line + make whitespace conform (Michel)
v1.2: add GL 3.1 version defines
v2: move to having glamor work out the profile.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
GL_RED is supported by core profiles while GL_ALPHA is not; use GL_RED
for one channel objects (depth 1 to 8), and then swizzle them into the
alpha channel when used as a mask.
[airlied: updated to master, add swizzle to composited glyphs and xv paths]
v2: consolidate setting swizzle into the texture creation code, it
should work fine there. Handle swizzle when setting color as well.
v3: Fix drawing to a8 with Render (changes by anholt, reviewed by airlied).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
It's been on the list to add dual source blending support to avoid the
two pass componentAlpha code. Radeon has done this for a while in
EXA, so let's add support to bring glamor up to using it.
This adds dual blend to both render and composite glyphs paths.
Initial results show close to doubling of speed of x11perf -rgb10text.
v2: Fix breakage of all of CA acceleration for systems without
GL_ARB_blend_func_extended. Add CA support for all the ops we
support in non-CA mode when blend_func_extended is present. Clean
up some comments and formatting. (changes by anholt)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Core contexts require the use of vertex array objects, so switch both glamor
and ephyr/glamor over.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
According to Nicolai Hähnle, the relevant specification says "All
messages are initially enabled unless their assigned severity is
DEBUG_SEVERITY_LOW", so we need to explicitly disable the messages we
don't want to get. Failing that, we were accidentally logging e.g.
shader stats intended for shader-db.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93659
Tested-by: Laurent Carlier <lordheavym@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
One less layering violation (EGL should call glamor, if anything, not
the other way around).
v2: Move glamor.c's DestroyPixmap wrapping up above the
glamor_egl_screen_init() call, since glamor.c's DestroyPixmap
needs to be the bottom of the stack (it calls fb directly and
doesn't wrap). Caught by Michel.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The spec allows general undefined behavior when GL_OOM is thrown. But
if the driver happens to throw the error at this point, it probably
means the pixmap was just too big, so we should delete that texture
and have this pixmap fall back to software.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
We're using the former only as the latter is present. Thus in some cases
we might incorrectly error out if it's missing.
Namely - glamor_glx, glamor_egl without gbm, EGL_KHR_gl_texture_2D_image
or EGL_EXT_image_dma_buf_import.
Fixes 58d54ee82df(glamor: explicitly check for GL_OES_EGL_image)
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Suggested-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Otherwise we'll fail miserably later on as we try to use
glEGLImageTargetTexture2DOES.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Fixes a regression since a2a2f6e34b. I
missed this in testing on x86, because we never fail to allocate an
FBO. We do hit this path on VC4, though.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Without this, the context of another screen may be current, or no context
at all if glamor_egl_init failed for another screen.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that it's always non-null when the pixmap is non-null, we don't
need so much of this. glamor_get_pixmap_private() itself still
accepts a NULL pixmap and returns NULL, because of glamor_render.c
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This avoids a lot of screwing around to attach our privates later. It
means that non-glamor pixmaps now gain 120 bytes of glamor privates on
64-bit (which has quite a bit of fixable bloat), and glamor pixmaps
take one less pointer of storage (not counting malloc overhead).
Note that privates start out zero-filled, which matches the callocs we
were doing when making our own privates, and in the case of an fb
pixmap that has a priv where it didn't before, the type ends up being
GLAMOR_MEMORY as we would want.
v2: Clarify that the GLAMOR_MEMORY enum must be 0 (as it was
previosuly), so that the new pixmap private behavior is as
expected. Suggested by keithp.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Keith Packard <keithp@keithp.com>
This should help people debugging when glamor does something stupid on
their driver.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
It was apparently accidentally dropped in keithp's removal of _nf
functions in 90d326fcc6.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Improves text rendering from about 284k glyphs per second to 320k
glyphs per second. There's no GL extension for probing this, because
of the philosophy of "Don't expose whether things are really in
hardware or not."
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
