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>
