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>
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>
With a patch to mesa to expose rgb565 pbuffers even on a server with
only depth 24 and 32 visuals, fixes
dEQP-EGL.functional.render.single_context.gles2.rgb565_pbuffer. Those
pbuffers (or at least something renderable with 565) are required by
the current CTS for GLES3, and having the server support DRI3 on those
pixmaps means that we can avoid having a different path for EGL
pbuffers compared to pixmaps.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
KMS drivers are not required to support GEM. In particular, vmwgfx
doesn't support flink and handles and names are identical.
Getting a bo name should really be part of a lower level API, if needed,
but in the mean time work around this by setting the name identical to
the handle if GEM isn't supported.
This fixes modesetting driver dri2 on vmwgfx.
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.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")
This was left disabled in 1.20.0, it's time to start being sure it
works.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniels@collabora.com>
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.
Reviewed-by: Adam Jackson <ajax@redhat.com>
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>
If dmabuf_capable is false, because the server "dmabuf_capable"
debug flag isn't set, treat it as successfull query with zero
returned formats, instead of failure.
This allows the servers cache_formats_and_modifiers() function
to cache the fact that formats are not supported during the
current server generation, instead of pointless retesting at
every invocation.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Images which are one pixel wider than a multiple of 8 are being handled
incorrectly. Other drivers round up the width to a multiple of two
before they start calculating. Do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=795235
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
It makes it perfectly clear that we should not be modifying them.
Should help highlight issues like the one fixed with previous commit.
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
dri3_screen_info is the user provide dispatch. Something that we do
not and should not change.
When using the _ptr typecast + const the compiler barfs at us
(rightfully so), so use the _rec one.
[Silence a new const mismatch warning too - ajax]
Fixes: 5631382988 ("dri3: Add DRI3 extension")
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Add a fd_from_pixmap (singular) hook to go with fds_from_pixmap, which
will ensure that the pixmap is allocated without modifiers and is thus
exportable to non-modifier-aware clients.
This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
If we try to allocate with particular modifiers but it fails, try to
fall back to non-modifier allocations.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
If we need a pixmap's storage to be exported to a context in which we
aren't aware of modifiers, reallocate the buffer again without
modifiers.
This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Rather than calling make_exportable from the get_bo entrypoint, make
sure that someone has already explicitly requested the pixmap be
exportable.
This is technically an ABI break in that it changes observable
behaviour, but no driver other than modesetting has ever used get_bo.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Keep track of whether or not we fed modifiers into GBM when we allocated
a BO. We'll use this later inside Glamor, to reallocate buffer storage
if we allocate buffer storage using modifiers, and a non-modifier-aware
client requests an export of that pixmap.
This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
With the appearance of the this new Option the X Server would crash if the
option is not set.
Default dmabuf_capable to off/FALSE for now - a user without knowledge about
this option does not want to enable it until its save.
Fixes: d11d5bb80 ("glamor: Hide new DRI behind Option "Debug" "dmabuf_capable")
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
... for xfree86, at least for now. Things appear to work for Xwayland
but not yet for modesetting. Hopefully we can fix that before 1.20 but
in the meantime this makes testing both paths easier than a rebuild.
Signed-off-by: Adam Jackson <ajax@redhat.com>
With earlier commit the required version was bumped to 2.4.89, thus the
guards always evaluate to true.
Fixes: e4e3447603 ("Add RandR leases with modesetting driver support
[v6]")
Cc: Keith Packard <keithp@keithp.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
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>
Using modifier might allow the driver to use a more optimal format
(e.g. tiled/compressed). Let's try to use those if possible.
v2: Don't filter out multi-plane modifiers
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>
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>
Specifically for xrgb2101010 format.
Tested on KDE Plasma-5 with XRender based composite
acceleration backend. Much smoother and faster.
(v2) Dropped argb2101010, because of depth 32 confusion with
argb8888, as pointed out by Eric. Thanks!
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
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>
This plumbs the full width color for solid pictures through to fb, exa,
and glamor. External drivers and acceleration code may wish to make a
similar change for sufficiently new servers.
v2: Don't break ABI (Michel Dänzer)
v2.1: Use the (correct) full color in fb too (Michel Dänzer)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
- Avoid some needlessly complex equations for calculating the color at a
point in a gradient field.
- Avoid calculating certain values multiple times.
- Use similar variable names across the two versions of the get_color
function where practical.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When compositing a no-reflect gradient, 'before' the gradient is empty,
but 'after' the gradient is padded with the final color. Both sides are
supposed to be empty.
This is fixed by moving the virtual stops to match the first and last
client-supplied stops for no-reflect gradients, then causing everything
'before' the initial virtual stop and 'after' the final virtual stop to
emit rgba(0,0,0,0). This does not impact gradients using the other
reflect modes.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
If _pt_distance is negative, it causes the final distance to be negative
in the repeat-reflect case. Moving the scaling by _pt_distance earlier
avoids this problem, and simplifies some equations as a bonus.
Bugzilla: https://bugs.freedesktop.org/98508
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
[ Michel Dänzer: Adapt to glamor changes since 1.19 ]
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
SAMPLE is a GLSL keyword in newer OpenGL version.
This fix issue with gnome-shell and playing video using xv
Signed-off-by: Corentin Rossignon <corentin.rossignon@gmail.com>
Bugzilla: https://bugs.freedesktop.org/104405
Reviewed-by: Adam Jackson <ajax@redhat.com>
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>
Roundhouse kick replacing the various (sizeof(foo)/sizeof(foo[0])) with
the ARRAY_SIZE macro from dix.h when possible. A semantic patch for
coccinelle has been used first. Additionally, a few macros have been
inlined as they had only one or two users.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-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>
glamor_compute_transform_clipped_regions() uses a temporary box32
internally which is copied back to a box16 to init the regions16,
thus causing a potential overflow.
If an overflow occurs, the given region is invalid and the pixmap
init region will fail.
Simply check that the coordinates won't overflow when copying back to
the box16, avoiding a crash later down the line in glamor.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=101894
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Fabrice Bellet <fabrice@bellet.info>
Reviewed-by: Adam Jackson <ajax@redhat.com>
COMPOSITE_REGION() can pass NULL as a source picture, make sure we
handle that nicely in both glamor_composite_clipped_region() and
glamor_composite_choose_shader().
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=101894
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Unlike the previous two fixes, this one introduces new GL calls and
statechanges of the scissor. However, given that our Render drawing
already does CPU side transformation and inefficient box upload, this
shouldn't be a limiting factor for Render acceleration.
Surprisingly, it improves x11perf -comppixwin10 -repeat 1 -reps 10000
on i965 by 3.21191% +/- 1.79977% (n=50).
v2: Make the jump to the exit land after scissor disable.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Like the previous fix to rectangles, this reduces the area drawn on
tiled renderers by letting the CPU-side tile setup know what tiles
might be drawn at all.
Surprisingly, it improves x11perf -copypixwin1 -repeat 1 -reps 10000
on i965 by 2.93185% +/- 1.5561% (n=90).
v2: Drop extra glamor_bounds_union_box() from previous debugging
(caught by Mark Marshall).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com> (v1)
Scissors provide a critical hint to tiled renderers as to what tiles
need to be load/stored because they could be modified by the
rendering.
The bounds calculation here is limited to when we have a small number
of rects (large enough to cover rounded window corners, but probably
not xeyes) to avoid overhead on desktop GL.
No performance difference on i965 with x11perf -rect1 -repeat 1 -reps
10000 (n=50)
v2: Clamp rectangle bounds addition.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The extensions listed have not been needed in a while. Replace with the
only remaining requirement.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The code that needed it was introduced with commit 7cfd9cc232 ("Add
DRI3 support to glamor") back in 2013. And was nuked a couple of years
ago with commit 51984dddfc ("glamor: Delay making pixmaps shareable
until we need to.")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This function creates a temporary pixmap to hold data being moved from
the source to the destination. However, it labeled all of the
variables associated with this as src_, which makes it confusing to
read the code. Rename them tmp_ instead. Also fix the comment
describing the function to note that it copies from CPU to GPU, not
GPU to GPU.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The previous values happened to work in basic cases, but not in general
if the destination is a subwindow or has a border.
Fixes crash with xli, which moves a large subwindow inside a smaller
parent window for scrolling.
No regressions with xterm, x11perf -copyplane or the xscreensaver
phosphor hack.
Bug: https://bugs.debian.org/857983
Reviewed-by: Keith Packard <keithp@keithp.com>
Fixes subtle breakage which could sometimes trigger after a server reset
with multiple screens using glamor:
Screen A enters glamor_close_screen last and calls various cleanup
functions, which at some point call glamor_make_current to make sure
screen A's GL context is current. This sets lastGLContext to screen A's
&glamor_priv->ctx. Finally, glamor_close_screen calls
glamor_release_screen_priv, which calls free(glamor_priv).
Later, screen B enters glamor_init, which allocates a new glamor_priv.
With bad luck, this can return the same pointer which was previously
used for screen A's glamor_priv. So when screen B's glamor_init calls
glamor_make_current, lastGLContext == &glamor_priv->ctx, so MakeCurrent
isn't called for screen B's GL context, and the following OpenGL API
calls triggered by glamor_init mess up screen A's GL context.
The observed end result of this was a crash in glamor_get_vbo_space
because glamor_priv->vbo didn't match the GL context, though there might
be other possible outcomes.
Assigning the actual GL context pointer to lastGLContext prevents this
by preventing the false negative test in glamor_make_current.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
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>
The function hasn't been doing anything useful since keithp's resource
freeing fixes in 2014.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
GLES2 support has been requested multiple times, and we've had this
code laying around trying to implement it. The GLES2 implementation
is not quite there yet (some pixel transfer failures), but it
shouldn't take much fixing at this point.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Those extensions don't exist. There's only surfaceless_context.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Indirect GLX uses its own context and doesn't care what glamor is
using.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Using flink is banned on render nodes, and they needlessly expose our
screen pixmap contents to any authenticated client. This also
incidentally drops the dependency on EGL_MESA_drm_image.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Emil Velikov
Olivier Fourdan
Adam Jackson
Eric Anholt
Paul Kocialkowski
Rohan Garg
Michel Dänzer
Dave Airlie
Julien Isorce
Thomas Hellstrom
Lyude Paul
Lukas F. Hartmann
Mario Kleiner
David Woodhouse
Daniel Stone
Tobias Klausmann
Louis-Francis Ratté-Boulianne
Jeff Smith
Hawking Zhang
Corentin Rossignon
Daniel Martin
Emil Velikov
Keith Packard