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>
Even if the pixmap's storage has alpha, it may have been uploaded with
garbage in the alpha channel, so we need to force the shader to set
alpha to 1. This was broken way back in
355334fcd9.
Fixes rendercheck -t composite -f x8r8g8b8.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
replicated a bug from last time we did a copy optimization: CopyArea
is only defined for matching depths. This is only a problem at 15 vs
16 depth right now (24 vs 32 would also have matching Render formats,
but they should work) but be strict in case we store other depths
differently in the future.
Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4
v2: Drop excessive src->depth == dst->depth check that snuck in.
v3: Switch back to src->depth == dst->depth
v4: Touch up commit message (s/bpp/depth).
Signed-off-by: Eric Anholt <eric@anholt.net>
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>
v2: Fix "orignal" too (review feedback by ajax, change by anholt)_
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
When a GPU gets hotplugged while X is already running, glamor_egl_init()
gets called and changes the current egl context, without updating
lastGLContext, potentially causing the next glamor call on another GPU to
run in the wrong context.
This causes glamor to e.g. crash in the next glamor_create_pixmap() call
(called through the master's screen->CreatePixmap), note this is not the
only troublesome entry point I've seen other backtraces when using a
compositing window manager.
Set lastGLContext to NULL to force the next glamor_make_current() call
to set the right context.
Note that we cannot use glamor_make_current() here to replace the
eglMakeCurrent() call and update lastGLContext for us because
glamor_make_current takes a glamor_priv struct as argument and that
has not been created yet when glamor_egl_init() gets called.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
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>
This can significantly speed up at least some CopyPlane cases, e.g.
indirectly for stippled fills.
v2:
* Make temporary pixmap the same size as the destination pixmap
(instead of the destination drawable size), and fix coordinate
parameters passed to fbCopyXtoX and glamor_upload_boxes. Fixes
incorrect rendering with x11perf -copyplane* and crashes with the
xscreensaver phosphor hack.
v3:
* Make the change a bit more compact and hopefully more readable by
re-using the existing src_* locals in the bitplane case as well.
Reported-by: Keith Raghubar <keith.raghubar@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Eric Anholt <eric@anholt.net>
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>
This new libXfont API eliminates exposing internal X server symbols to
the font library, replacing those with a struct full of the entire API
needed to use that library.
v2: Use libXfont2 instead of libXfont_2
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>
Fixes incorrect clipping for redirected windows which don't happen to be
located at the top left corner of the screen.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96742
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
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>
Nice of FreePicture to take a void * instead of a PicturPtr so that
this error wasn't caught by the compiler.
Noticed when resetting the X server left a dangling pixmap around.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Current Mesa Git master checks that the EGL display actually supports
the API passed to eglBindAPI, which can only succeed after
eglInitialize.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96344
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Commit b64108fa ("glamor: Check for composite operations which are
equivalent to copies") failed to copy conditions from exaComposite which
ensure that the composite operation doesn't access outside of the source
picture.
This fixes rendercheck regressions from the commit above.
Reviewed-by: Keith Packard <keithp@keithp.com>
Patch b64108fa30 added a short cut that
identifies composite operations that can be performed with a simple
copy instead.
glamor_copy works in absolute coordinates, so the dx and dy values
passed in need to be converted from drawable-relative to absolute by
adding the drawable x/y values.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.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>
glamor_make_current is supposed to be called before any GL APIs.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
If the logic op gets left enabled, it overrides the blending
operation, causing incorrect contents on the display.
v2: Disable only on non-ES2, but disable even for PictOpSrc
v3: Found another place this is needed in
glamor_composite_set_shader_blend
v4: Remove change dependent on new glamor_set_composite_texture
API. This belongs in a different patch.
Found by Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Increases x11perf -compwinwin500 numbers by a factor of 10 for me with
radeonsi.
Conditions copied from exaComposite().
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
RENDER requires that sampling outside of any source/mask picture results
in alpha == 0.0.
The OpenGL border colour cannot set alpha = 0.0 if the texture format
doesn't have an alpha channel, so we have to use the RepeatFix handling
in that case.
Also, only force alpha = 1.0 when sampling inside of RGBx source/mask
pictures.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94514
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@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>
When using PictOpSrc, the destination is wrongly shifted back to (0, 0).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94568
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
I'm pretty sure Eric suspected this could cause a problem, and we
couldn't find a test. Well loading feedly in firefox seems to trigger
badness that this solves.
bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94554
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Without this, we may be manipulating the context of another screen.
In a system with two GPUs using glamor, this fixes lots of
(EE) glamor256: GL error: GL_INVALID_OPERATION in glBindTexture(non-gen name)
spew since 0b4c0c75 ('glamor: Replace "finish access" shader with texture
swizzling').
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
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>
The glamor_pixmap_ensure_fbo() in glamor_pixmap_upload_prepare() will
always fail on a large pixmap, so we can just be explicit about
bailing out here and then dump the rest of this garbage.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Pixman is quite qualified to allocate our temporary memory, and all we
need to do is decide what formats to convert from and to.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
There was only a pretty special case that could have even worked --
you've got a GLES2 renderer, you've got a SHM pixmap, it's 1555 (not
the usual 565 for 16-bit), and you're little endian (BE was broken,
since GL's 5_5_5_1 picks the 1 bit from the lowest bit of the short,
and on BE we weren't doing the conversion path that swaps around the
channels). This is just not worth the complexity.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
These just smash your 2_10_10_10 data into 8888, despite what the
comments said. That's not valid rendering, so just ditch this path
and fall back to software. One might also note in the code being
removed here that the REVERT_UPLOADING_10_10_10_2 path wasn't even
connected.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
It clarifies what the difference is between the two paths, and would
potentially encourage us to handle GLES extensions that expose
additional types.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
glamor_composite_choose_shader() may upload our scratch pixmaps to get
a Render operation completed. We don't want to hang onto GL memory
for our scratch pixmaps, since we'll just have to reallocate them at a
new w/h next time around, and the contents will be updated as well.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
glamor_upload_sub_pixmap_to_texture() only had the one caller, so we
can merge it in, fix its silly return value, and propagate a bunch of
constants.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
We were using the destination pixmap depth to determine the source
picture format.
Fixes incorrect text rendering with some MATE desktop GTK3 themes.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94246
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
The former takes explicit screen and depth parameters instead of
deriving them from a pixmap.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
We already take src_y into account when uploading the src data by
starting at the top line of the src data when uploading.
Adjust src_y accordingly when rendering.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For hardware that doesn't do actual jumps for conditionals (i915,
current vc4 driver), this reduces the number of texture fetches
performed (assuming the driver isn't really smart about noticing that
the same sampler is used on each side of an if just with different
coordinates).
No performance difference on i965 with x11perf -magpixwin100 (n=40).
Improves -magpixwin100 by 12.9174% +/- 0.405272% (n=5) on vc4.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All sorts of weird indentation, and some cuddled conditional
statements deep in the if tree.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
wh ratios are != 1.0 only when large, so with that we can simplify
down how we end up with RepeatFix being used.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We had a double loop across h and w, and passed the current x and y
out to callers who then used w to multiply/add to an index. Instead,
just single loop across w * h.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a step toward using glamor_program.c for Render acceleration.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We can just hand in a constant mask and the driver will optimize away
the multiplication for us.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
One less custom path! By following the common glamor_program.c use
pattern, we get the ability to handle large pixmaps as the
destination. It's also one less place where glamor_utils.h coordinate
transformation happens.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were clipping the drawn rectangle to each clip box, then expanding
the box to a big triangle to avoid tearing, then drawing each triangle
to the destination through a scissor. If we're using a scissor for
clipping, though, then we don't need to clip the drawn primitive on
the CPU in the first place.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
No sense doing it on every draw.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This hasn't been used since 2f80c7791b
(GLAMOR_SEPARATE_TEXTURE removal).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Wait long enough, and you don't need to think about it at all.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
They've been dead since the yInverted removal
(e310387f44).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965 does most of its compiling at link time, so our debug output for
its shaders didn't have the name on.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v1.1: use version defines.
v2: let glamor work it out itself
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-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>
We only need it once at the top of the shader, so just put it
there.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This happens if you run twm + mplayer + xclock and drag
the clock over the mplayer. If we don't catch it, we cause
an illegal draw elements command to be passed to GL.
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>
I originally inherited this from the EXA code, without determining
whether it was really needed. Regular composite should end up doing
the same thing, since it's all just shaders anyway. To the extent
that it doesn't, we should fix composite.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reading and writing to 16-depth pixmaps using PICT_x1r5g5b5 ends up
failing, unless you're doing a straight copy at the same bpp where the
misinterpretation matches on both sides.
Fixes rendercheck/blend/over and renderhceck/blend/src in piglit.
Please cherry-pick this to active stable branches.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
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>
This converts the Xv code to using VBOs instead of
client ptrs. This is necessary to move towards using
the core profile later.
v2: put all boxes into single vbo, use draw arrays
to offset things. (Eric)
v2.1: brown paper bag with releasing vbo.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This converts two client arrays users to using vbos,
this is necessary to move to using core profile later.
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>
There is a problem with some fonts that the height necessary
to store the font is greater than the max texture size, which
causes a fallback to occur. We can avoid this by storing two
macro columns side-by-side in the texture and adjusting
the calculations to suit.
This fixes
xfd -fn -*-*-*-*-*-*-*-*-*-*-*-*-*-*
falling back here, when it picks
-arabic-newspaper-medium-r-normal--32-246-100-100-p-137-iso10646-1
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
running xfontsel on haswell here, with a max texture size
of 8kx8k, one font wants 9711 height. This fallsback to
sw in this case.
A proper solution probably involves using an array texture.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If a pixmap isn't getting exported as a dmabuf, then we don't need to
make an EGLImage/GBM bo for it. This should reduce normal pixmap
allocation overhead, and also lets the driver choose non-scanout
formats which may be much higher performance.
On Raspberry Pi, where scanout isn't usable as a texture source, this
improves x11perf -copypixwin100 from about 4300/sec to 5780/sec under
xcompmgr -a, because we no longer need to upload our x11perf window to
a tiled temporary in order to render it to the screen.
v2: Just use pixmap->usage_hint instead of a new field. Drop the
changes that started storing gbm_bos in the pixmap priv due to
lifetime issues.
v3: Fix a missing gbm_bo_destroy() on the pixmap-from-fd success path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This GBM import path was introduced in 10.2, which we already require.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
I think void * was just used to avoid needing to #include gbm.h, but
we can just forward-declare the structs and be fine.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
We were rolling ioctl calls ourselves, when there's a nice interface
for it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
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 DestroyPixmap chain and CloseScreen chain all do pixmap teardown
already, and calling it manually would be redundant.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
I assume this was a workaround for an old, broken, closed driver. The
driver doesn't get to throw away rendering just because the rendering
context's shared-across-processes render target is getting freed from
the local address space. If the rendering isn't to a shared render
target, then we *do* want to throw away the rendering to it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
If the source/mask pixmap is a pixmap that doesn't have an FBO
attached, and it doesn't match the Render operation's size, then we'll
composite it to a CPU temporary (not sure why). We would take the
PictFormatShort from the source Picture, make a pixmap of that depth,
and try to look up the PictFormat description from the depth and the
PictFormatShort. However, the screen's PictFormats are only attached
to the screen's visuals' depths. So, with an x2r10g10b10 short format
(depth 30), we wouldn't find the screen's PictFormat for it
(associated with depth 32).
Instead of trying to look up from the screen, just use the pFormat
that came from our source picture. The only time we need to look up a
PictFormat when we're doing non-shader gradients, which we put in
a8r8g8b8.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
If the glTexImage (or glTexSubImage) out-of-memories, error out
cleanly so that we can fall back to software.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
We already have a fallback path, so we just need to jump to it when we
hit the failure.
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>
GL 4.5 / GLES 3.0 require throwing GL errors at map time, and Mesa
before that might throw errors accidentally if a malloc(0) call was
made to return the mapping.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Otherwise we'll fail and/or crash as no context is bound.
Fixes: 64e6124f27 (glamor: move GL_OES_EGL_image check next to EGL_EXT_image_dma_buf_import)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92105
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Nick Sarnie <commendsarnex@gmail.com>
Reported-by: Nick Sarnie <commendsarnex@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Nick Sarnie <commendsarnex@gmail.com>
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>
Lots of the accel paths only make current once they start
doing someting, so a lot of them call the bail paths without
make current, which means on PRIME systems for example
we end up in the wrong context.
Add a prepare pixmap in the prepare fallback path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90667
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes slow text display in xdvi.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91260
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>
These are dead since the glamor_copy.c replacement.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Adam Jackson
Eric Anholt
Mark Kettenis
Matthieu Herrb
Eric Engestrom
Hans de Goede
Michel Dänzer
Keith Packard
Dave Airlie
Olivier Fourdan
Alan Coopersmith
Emil Velikov