This hasn't been used since the format swap/revert stuff for pictures
was added back in 2012.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This function takes the start x/y and the destination's width/height,
so it only works if there's no transform. We could potentially
transform this box and take its bounds with some rounding, but this at
least gets us to read out enough data.
Note that this does the same overshoot on destination pictures with a
transform attached, but that seems unlikely to be used anyway.
v2: Add XXX comment for the commit message note (Suggested by Michel).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Dave Airlie <airlied@redhat.com> (v1)
The pixmap->picture is just the *last* picture attached to the pixmap,
so you'd potentially be looking at the wrong one when trying to
temporarily upload to avoid a composite fallback.
There's some trickiness in glamor_render.c when we're dealing with the
upload of a GLAMOR_MEMORY pixmap as both the source and mask using
different formats, where we smash the source's format to a new value
so that the mask can use the same uploaded bits. Dropping most of
that should be safe, since it will be uploaded as the source first, so
the smashed format will still be used.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
These functions aren't used by anything else, and are specific to the
temporary-upload-as-a-weird-format path of glamor_render.c, called
through glamor_upload_picture_to_texture().
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
We don't need any of its weird handling of picture formats, since our
XV pixmaps don't have any pictures attached.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Attaching a picture to a pixmap doesn't change its GL format, so it
doesn't change how core rendering should be assigning colors to it.
(Imagine XCreatePixmap(), optional XCreatePicture(pixmap) with various
formats, XFillRectangle, XGetImage(). If the XGetImage results
changed, this would be wrong).
Fixes all failures in "rendercheck -t fill" and, as a result, the
remaining failures in "rendercheck -t blend -o src -f
a8r8g8b8,x2r10g10b10"
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
I'm amazed we've made it as far as we have without these checks: if
you made an unusual format picture that wasn't the normal a8r8g8b8 or
x8r8g8b8 or a8, we'd go ahead and try to render with it, ignoring that
the sampler would fetch totally wrong bits.
Fixes 260 tests in rendercheck -t blend -o src -f a8r8g8b8,x2r10g10b10
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
glamor_egl_init() was not undoing any of the init steps on init error,
add an glamor_egl_cleanup() function and use this both on error and on exit
to cleanup the various resources.
Even on a clean exit eglTerminate() was not being called, causing the fd
dup()-ed by eglInitialize() to stay open, call eglTerminate() from the new
glamor_egl_cleanup() to fix this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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>
It died as of keithp's new glyphs code.
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 significantly reduces the amount of time it takes for xterm to start
up on a fresh X server with the radeonsi driver.
v2: Use GLYPHWIDTHBYTESPADDED instead of hardcoding 4 bytes glyph
alignment (Keith Packard)
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-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>
Fixes regressions since Eric's "don't make an FBO for the glyph atlas"
change. The a1 upload was a fallback, as expected. However, fallback
reads use glReadPixels() because there's no glGetTexSubImage2D() to
match glTexSubImage2D(). We were just binding the 0 FBO value, so the
glReadPixels() would throw a GL error instead of getting any data.
After the fallback was done we'd write back the undefined data to the
atlas, blowing away the entire rest of the atlas because we didn't
specify any bounds on our prepare.
To fix the fallbacks to actually work, we'd need a prepare path that
allocates some memory memory do a full glGetTexImage() into, then
memcpy out of that. Instead, just dodge the general fallback by
implementing the specific upload we need to do here, which should also
be *much* faster at uploading a1 glyphs since it's not
readpixels/texsubimaging back and forth.
v3: Use CopyPlane to a temp pixmap for the upload
v4: Rewrite anholt's commit message to be from keithp's perspective
(changes by anholt)
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This gives the compiler a chance to optimize when the data is never
changed -- for example, with pict_format_combine_tab, the compiler
ends up inlining the 24 bytes of data into just 10 more bytes of code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
It's been unused since I killed glamor_download_pixmap_to_cpu().
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@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>
Above, we've already checked for ->fbo && ->fbo->fb and returned.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
v2: Don't forget to set priv->block_w/block_h like the wrapper used
to.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
This should hopefully keep the comments more up to date with the
structure comments. While I'm here, I've reworded a few of them to be
more accurate, and dropped a bunch of stale comments.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The code to set it was deleted in keithp's big rewrite.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
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>
Improves x11perf -aa10text performance by 1377.59% +/- 23.8198% (n=93)
on Intel with GLES2.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
We were only looking for the desktop GL version of the extension, so
GLES2 missed out.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
We use this for all of our other performance-sensitive rendering, too.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The GL_QUADS helper takes a number of quads, not a number of vertices.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Rather than create the pixmap, this uses the file descriptor
to change an existing pixmaps backing store.
This is required for reverse prime slaves, where we create
the slave pixmap, then set the backing store.
v1.1: use local pScreen (Eric)
Reviewed-by: Eric Anholt <eric@annholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need this for doing USB offload scenarios using glamor
and modesetting driver.
unfortunately only gbm in mesa 10.6 has support for the
linear API.
v1.1: fix bad define
v2: update the configure.ac test as per amdgpu. (Michel)
set linear bos to external to avoid cache. (Eric)
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
VC4 (and many GLES2 renderers) can't render to GL_ALPHA, so our pixmap
would end up as GLAMOR_MEMORY and our dereference of the FBO would
setfault. Instead, tell the pixmap creation that we don't need an FBO
at all. Our glyph upload path was already glTexImage for non-a1, and
a more general software fallback for a1 (since the glyph is also in
system memory).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The cache was trying to allow glyph_max_dim in, but since we were
putting over 64x64 into HW memory, it would end up in the
single-glyph-per-render bail_one path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
XRender defines this, GL really doesn't like it.
kwin 4.x and qt 4.x seem to make this happen for the
gradient in the titlebar, and on radeonsi/r600 hw
this draws all kinds of wrong.
v2: bump this up a level, and check it earlier.
(I assume the XXXX was for this case.)
v3: add same code to largepixmap paths (Keith)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
New composite glyphs code uses the updated glamor program
infrastructure to create efficient shaders for drawing render text.
Glyphs are cached in two atlases (one 8-bit, one 32-bit) in a simple
linear fashion. When the atlas fills, it is discarded and a new one
constructed.
v2: Eric Anholt changed the non-GLSL 130 path to use quads instead of
two triangles for a significant performance improvement on hardware
with quads. Someone can fix the GLES quads emulation if they want to
make it faster there.
v3: Eric found more dead code to delete
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This extends the existing API to support options needed for render
accleration, including an additional fragment, 'combine', (which
provides a place to perform the source IN mask operation before the
final OP dest state) and an additional 'defines' parameter which
provides a way to add target-dependent values without using a uniform.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Use code from Piglit project to compute GLSL version for either GL or
GLES. The Piglit code was originally written by Chad Versace.
v2: bail if the parse fails (requested by Eric Anholt)
v3: Use version 1.20 for GLES until we fix our programs (Eric Anholt)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Instead of passing the destination drawable, just pass the depth, as
the underlying functions need only that to check whether the planemask
is going to work.
This API change will allow higher level functions to not need the
destination pixmap.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes a build error with gcc 4.2.1 on OpenBSD due to
-Werror=return-type from xorg-macros.
error: type qualifiers ignored on function return type
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
v2: fixup whitespace
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Pass the inverse of the texture size to glamor vertex shaders so that
we multiply by that instead of dividing by the size as multiplication
is generally faster than division.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The texture2D() happens in each branch, so we may as well do it as early
as possible and hide some of its latency in the branching instructions.
Moving it outside the (uniform) control flow reduces the number of
instructions in the fs_source shader from 64 to 46 and in the
set_alpha_source shader from 69 to 47 on Haswell.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
We should do better than this with an index buffer, but for now at
least make it so that we don't have to copy the same code to new
places.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This possibly is a minor hit for immediate mode renderers (no
difference on copypixin100 on my hsw, n=12), but it gives important
information about drawing bounds to a deferred renderer (3.1x
improvement in copypixwin100 on vc4).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
By dropping the unconditional logic op disable at the end of
rendering, this fixes GL errors being thrown in GLES2 contexts (which
don't have logic ops). On desktop, this also means a little less
overhead per draw call from taking one less trip through the
glEnable/glDisable switch statement of doom in Mesa.
The exchange here is that we end up taking a trip through it in the
XV, Render, and gradient-generation paths. If the glEnable() is
actually costly, we should probably cache our logic op state in our
screen, since there's no way the GL could make that switch statement
as cheap as the caller caching it would be.
v2: Don't forget to set the logic op in Xephyr's drawing.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
When using glamor (either in Xephyr or Xwayland) on hardware with too
low instructions limit, glamor fallbacks to sw due to large shaders.
This makes glamor unbearably slow on such hardware.
Check reported value for GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB
and fail in glamor_init() if the limit is lower than 128.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88316
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Initialize full pixmap private for all pixmaps, including block
dimensions and counts so that no checks are needed when walking the
fbos.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This will let us eliminate the pixmap types shortly
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Just embed the large elements in the regular pixmap private and
collapse the union to a single struct.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
There's no reason to waste memory storing redundant copies of the same
pointer all over the system; just pass in pointers as necessary to
each function.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
The core rendering code already requires that FBOs be allocated at
exactly the pixmap size so that tiling and stippling work
correctly. Remove the allocation support for that, along with the
render code.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is not used anywhere
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This was only used to signal when we couldn't ask the DDX to draw to a
pixmap; now that we have no DDX-based fallbacks, we don't need to have
this type.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
With no DDX-based fallback support, we can remove these functions as
they are no longer called.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
These were used by the non-standard glamor implementation in the intel
driver.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Remove these defines as we start to remove support for non-standard
glamor layering as used by the intel driver.
v2: Rebase on the blockhandler change and the Xephyr init failure
change (by anholt), fix stray NO_DRI3 addition to xwayland.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
GLAMOR_MEMORY_MAP was only used with GLAMOR_CREATE_PIXMAP_MAP, and
GLAMOR_CREATE_PIXMAP_MAP doesn't appear to be used anywhere, so just
remove both of them.
v2: Fix a stray whitespace bug that was introduced (change by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Remove the calls to GL_TEXTURE_MAX_LEVEL. Setting the filtering is
a sufficient hint to the driver about texture mipmap allocation.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The latter might not be available on GLES2.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
According to Eric Anholt the check for glGetError is not needed here.
Because a opengl error might be set before this function is called
keeping the check could result in glamor_build_program returning
failure when building the shader succeeded.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Check for GL_EXT_unpack_subimage and GL_NV_pack_subimage to
check if GL_(UN)PACK_ROW_LENGTH is available. Set the offsets
manually to prevent calls to GL_(UN)PACK_SKIP_*.
v2: Check support for GL_NV_pack_subimage as suggested by Matt Turner.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This adds glamor into the block handler call chain
in the correct place.
This should fix interactions between glamor and drivers
requiring damage from glamor.
v2: okay don't consolidate, just leave things wierd for now
remove blcokhandler in screen close.
v3: block handler wrapping the right way.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The number of lines of video to update in the texture needs to be
computed from the height of the updated source, not the full height of
the source.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
_glamor_upload_bits_to_pixmap_texture currently ignores the stride
parameter, but __glamor_upload_pixmap_to_texture uses 4-byte alignment
via glPixelStorei(GL_UNPACK_ALIGNMENT, 4).
Also fix up the stride argument passed in though, in case it starts
being used properly in the future.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87455
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Only called from glamor_fbo.c now.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Calling glamor_purge_fbo directly was incorrect for large pixmaps.
Fixes use-after free with large pixmaps:
==2029== Invalid write of size 8 ~
==2029== at 0x85F93AD: __xorg_list_del (list.h:184)
==2029== by 0x85F93AD: xorg_list_del (list.h:204)
==2029== by 0x85F93AD: glamor_fbo_expire (glamor_fbo.c:280)
==2029== by 0x85F95CA: glamor_pixmap_fbo_cache_put (glamor_fbo.c:159)
==2029== by 0x85D7AB5: glamor_destroy_textured_pixmap (glamor.c:228)
==2029== by 0xC1BDDC4: radeon_glamor_destroy_pixmap (radeon_glamor.c:272)
==2029== by 0x519D00: damageDestroyPixmap (damage.c:1473)
==2029== by 0x4DD307: XvDestroyPixmap (xvmain.c:370)
==2029== by 0x4DB975: ShmDestroyPixmap (shm.c:258)
==2029== by 0x5098F6: FreePicture (picture.c:1425)
==2029== by 0x85E678E: glamor_composite_clipped_region (glamor_render.c:1558)
==2029== by 0x85F763A: glamor_composite_largepixmap_region (glamor_largepixmap.c:1347)
==2029== by 0x85E7964: _glamor_composite (glamor_render.c:1679)
==2029== by 0x85E7A38: glamor_composite (glamor_render.c:1758)
==2029== Address 0x1141d3c0 is 0 bytes inside a block of size 64 free'd
==2029== at 0x4C29E90: free (vg_replace_malloc.c:473)
==2029== by 0x85D7167: glamor_set_pixmap_private (glamor.c:570)
==2029== by 0xC1BDDC4: radeon_glamor_destroy_pixmap (radeon_glamor.c:272)
==2029== by 0x519D00: damageDestroyPixmap (damage.c:1473)
==2029== by 0x4DD307: XvDestroyPixmap (xvmain.c:370)
==2029== by 0x4DB975: ShmDestroyPixmap (shm.c:258)
==2029== by 0x45B246: doFreeResource (resource.c:875)
==2029== by 0x45BD5E: FreeResource (resource.c:905)
==2029== by 0x43444B: ProcFreePixmap (dispatch.c:1422)
==2029== by 0x43856E: Dispatch (dispatch.c:432)
==2029== by 0x43C96F: dix_main (main.c:298)
==2029== by 0x6CFAB44: (below main) (libc-start.c:287)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The other way around fails to destroy the screen pixmap EGL image:
==1782== 80 (32 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 981 of 2,171
==1782== at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==1782== by 0xF9D4BD2: dri2_create_image_from_dri (egl_dri2.c:1264)
==1782== by 0xF9D4BD2: dri2_create_image_dma_buf (egl_dri2.c:1764)
==1782== by 0xF9D4BD2: dri2_create_image_khr (egl_dri2.c:1798)
==1782== by 0xF9C7937: eglCreateImageKHR (eglapi.c:1494)
==1782== by 0x85D5655: _glamor_egl_create_image (glamor_egl.c:134)
==1782== by 0x85D5655: glamor_egl_create_textured_pixmap (glamor_egl.c:302)
==1782== by 0x85D579B: glamor_egl_create_textured_screen (glamor_egl.c:225)
==1782== by 0xC1BE05D: radeon_glamor_create_screen_resources (radeon_glamor.c:67)
==1782== by 0xC1B6153: RADEONCreateScreenResources_KMS (radeon_kms.c:258)
==1782== by 0x4B2105: xf86CrtcCreateScreenResources (xf86Crtc.c:709)
==1782== by 0x43C823: dix_main (main.c:223)
==1782== by 0x6CFAB44: (below main) (libc-start.c:287)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
For robustness against drivers which may call both
glamor_(egl_)destroy_textured_pixmap and glamor_destroy_pixmap.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
==25551== Invalid read of size 8
==25551== at 0x85D5F2C: glamor_egl_destroy_pixmap_image (glamor_egl.c:527)
==25551== by 0x85D7750: glamor_destroy_pixmap (glamor.c:235)
==25551== by 0xC1BDD9B: radeon_glamor_destroy_pixmap (radeon_glamor.c:278)
==25551== by 0x5098F6: FreePicture (picture.c:1425)
==25551== by 0x85DD7A9: glamor_unrealize_glyph_caches (glamor_glyphs.c:257)
==25551== by 0x85D7B50: glamor_close_screen (glamor.c:586)
==25551== by 0x4B1A82: xf86CrtcCloseScreen (xf86Crtc.c:734)
==25551== by 0x4CFFC7: CursorCloseScreen (cursor.c:187)
==25551== by 0x513A44: AnimCurCloseScreen (animcur.c:106)
==25551== by 0x51529B: present_close_screen (present_screen.c:64)
==25551== by 0x43CA83: dix_main (main.c:351)
==25551== by 0x6CFAB44: (below main) (libc-start.c:287)
==25551== Address 0x83dafa0 is 96 bytes inside a block of size 152 free'd
==25551== at 0x4C29E90: free (vg_replace_malloc.c:473)
==25551== by 0x85D76B4: glamor_destroy_textured_pixmap (glamor.c:225)
==25551== by 0x85D7750: glamor_destroy_pixmap (glamor.c:235)
==25551== by 0xC1BDD9B: radeon_glamor_destroy_pixmap (radeon_glamor.c:278)
==25551== by 0x5098F6: FreePicture (picture.c:1425)
==25551== by 0x85DD7A9: glamor_unrealize_glyph_caches (glamor_glyphs.c:257)
==25551== by 0x85D7B50: glamor_close_screen (glamor.c:586)
==25551== by 0x4B1A82: xf86CrtcCloseScreen (xf86Crtc.c:734)
==25551== by 0x4CFFC7: CursorCloseScreen (cursor.c:187)
==25551== by 0x513A44: AnimCurCloseScreen (animcur.c:106)
==25551== by 0x51529B: present_close_screen (present_screen.c:64)
==25551== by 0x43CA83: dix_main (main.c:351)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(Originally written by Dave Airlie; split into a separate patch by
Kenneth Graunke.)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
They are part of the ABI.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When reallocating the framebuffer on screen resize, the old EGL image
was getting leaked. Check for an existing EGL image and free it in
this case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Revewied-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There's no reason to store this in the egl screen private as the
screen pixmap will always hold a reference to it anyways.
Signed-off-by: Keith Packard <keithp@keithp.com>
Revewied-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There were three paths that called eglDestroyImageKHR:
* The front buffer
* The intel driver's flip buffer
* pixmaps under DRI3
This patch unifies the second two by having glamor_destroy_pixmap
always destroy any associaged EGL image. This allows us to stop
storing the back_pixmap pointer in glamor as that was only used to
make sure that buffer was freed at server reset time.
v2: check for valid pixmap_priv before using it in
glamor_egl_destroy_pixmap_image
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Mark fbos created from external buffers so that when the associated
pixmap is destroyed, they aren't put into the fbo cache for later
re-use and are instead freed immediately.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
When uploading bits to a texture which need reformatting to match a
supported GL format, a temporary buffer is allocated to hold the
reformatted bits. This gets freed in the general path, but is not
freed in the fast path because that includes an early return before
the call to free.
This patch removes the early return and places the general case under
an 'else' block, so that both paths reach the call to free.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
glamor_color_convert_to_bits() returns its second argument on
success, NULL on error, and need_free_bits already makes sure that
"bits" aliasing converted_bits is freed in the success case.
Looks like the memory leak that was supposed to be fixed in
6e50bfa706 only occurred in the error
case.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This existed to be passed to the bs recovery routine; since we back all
planes, we don't care.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Otherwise the CPU may end up reading from non-cacheable memory, which is
very slow.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84178
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Markus Wick <markus@selfnet.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
==9530== 808,575,600 bytes in 5,904 blocks are definitely lost in loss record 4,602 of 4,602
==9530== at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==9530== by 0xAD29C98: _glamor_upload_bits_to_pixmap_texture (glamor_pixmap.c:771)
==9530== by 0xAD2AE95: glamor_upload_sub_pixmap_to_texture (glamor_pixmap.c:1031)
==9530== by 0xAD2BD55: glamor_upload_pixmap_to_texture (glamor_pixmap.c:1057)
==9530== by 0xAD1C2E6: glamor_composite_choose_shader (glamor_render.c:1025)
==9530== by 0xAD1C629: glamor_composite_with_shader (glamor_render.c:1174)
==9530== by 0xAD1DA77: glamor_composite_clipped_region (glamor_render.c:1542)
==9530== by 0xAD1E849: _glamor_composite (glamor_render.c:1689)
==9530== by 0xAD1ED90: glamor_composite (glamor_render.c:1758)
==9530== by 0x519FD6: damageComposite (damage.c:502)
==9530== by 0xAD27AA3: glamor_trapezoids (glamor_trapezoid.c:147)
==9530== by 0xAD27B51: glamor_trapezoids (glamor_trapezoid.c:101)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84176
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
I can't find any performance benefit to using the GL path and the code
renders this trapezoid incorrectly:
top: FIXED 29.50
bottom: FIXED 30.00
left top: POINT 0.00, 29.50
left bottom: POINT 0.00, 30.50
right top: POINT -127.50, 29.50
right bottom: POINT 52.50, 30.00
This should render a solid line from 0,30 to 52,30 but draws nothing.
The code also uses an area computation for trapezoid coverage which
does not conform to the Render specification which requires a specific
point sampling technique.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This enables the assertion that all users of the large pixmap member
are restricted to pixmaps which are actually large.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glamor_composite_largepixmap_region is given the job of dealing with
compositing between a mixture of large and small pixmaps. However, it
was assuming that the destination pixmap was large and fetching
members of the large structure even for small pixmaps.
This manifested with assertion failures when compositing from a large
pixmap to a small pixmap.
Fixed by using the pixmap size for the destination block size for
small pixmaps.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glamor_compute_clipped_regions_ext wants to treat small and large
pixmaps uniformly and did that by writing into the large pixmap
union member in small pixmaps to construct something that looks like a
one texture large pixmap.
Instead of doing that, simply allocate the necessary elements locally
on the stack and use them from there.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
For now, this simply fetches the large member of the pixmap private.
It will be changed to assert that the pixmap is large once bugs
related to that have been fixed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is the last function-like macro in glamor_priv.h; change to
static inline like all of the other functions there.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
It references a pixmap, which is a per-screen resource.
Fixes broken text rendering in xfwm4-tweak-settings in Zaphod mode.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is necessary because the glyph caches are per screen.
Fixes broken menu text in gnome-terminal in Zaphod mode.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
And rename the boolean to reflect what it's about.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The comment above glamor_glyphs_init was already saying so.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
It results in a crash.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
The Xv StopVideo callback is not invoked on textured video ports, so
the temporary pixmaps allocated for the video planes are never freed.
Freeing the storage immediately after use is a simple solution to this
problem which doesn't appear to have any visible performance impact.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This happens to avoid GL errors on hardware without
EXT_texture_integer (which implies < GLSL 130, and thus glamor_text.c
programs not compiling anyway).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This provides a speedup e.g. when the destination is an SHM pixmap.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76285
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
A few files in the server are including xorg-server.h, which is only
for use by Xorg server drivers. This fixes those errors and then adds
a check to make sure it doesn't happen again.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This uses a single large triangle and a scissor to draw the video
instead of two triangles.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
I intended to use glFlush all along, but somehow managed to type
glFinish instead. glFlush is sufficient (for a single-queue GPU) to
ensure serialization between queued rendering in the X server and
future rendering from the client.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
This hooks up SHM sync fences to complete the requirements for DRI3
running on Glamor.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
It's unused since keithp's copy acceleration code completely replaced
glamor_copyarea.c and removed the blit path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Unused since the glamor_prepare.c replacement of glamor_finish_access().
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
All users of glamor had the same value set, and it complicated things
for no reason.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
After keithp's change to drop the old glamor_fill() code, nothing ever
changed these values.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
We're not drawing, and we're not initially setting up the texture for
later drawing.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
If this path needed the filters set, so would all the other
glDrawArrays() callers. But they don't.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
To understand this patch, let's start at the protocol interface where
the relationship between the coordinate spaces is documented:
static Bool
_glamor_composite(CARD8 op,
PicturePtr source,
PicturePtr mask,
PicturePtr dest,
INT16 x_source,
INT16 y_source,
INT16 x_mask,
INT16 y_mask,
INT16 x_dest, INT16 y_dest,
CARD16 width, CARD16 height, Bool fallback)
The coordinates are passed to this function directly off the wire and
are all relative to their respective drawables. For Windows, this means
that they are relative to the upper left corner of the window, in
whatever pixmap that window is getting drawn to.
_glamor_composite calls miComputeCompositeRegion to construct a clipped
region to actually render to. In reality, miComputeCompositeRegion clips
only to the destination these days; source clip region based clipping
would have to respect the transform, which isn't really possible. The
returned region is relative to the screen in which dest lives; offset by
dest->drawable.x and dest->drawable.y.
What is important to realize here is that, because of clipping, the
composite region may not have the same position within the destination
drawable as x_dest, y_dest. The protocol coordinates now exist solely to
'pin' the three objects together.
extents->x1,y1 Screen origin of clipped operation
width,height Extents of the clipped operation
x_dest,y_dest Unclipped destination-relative operation coordinate
x_source,y_source Unclipped source-relative operation coordinate
x_mask,y_mask Unclipped mask-relative operation coordinate
One thing we want to know is what the offset is from the original
operation origin to the clipped origin
Destination drawable relative coordinates of the clipped operation:
x_dest_clipped = extents->x1 - dest->drawable.x
y_dest_clipped = extents->y1 - dest->drawable.y
Offset from the original operation origin:
x_off_clipped = x_dest_clipped - x_dest
y_off_clipped = y_dest_clipped - y_dest
Source drawable relative coordinates of the clipped operation:
x_source_clipped = x_source + x_off_clipped;
y_source_clipped = y_source + y_off_clipped;
Mask drawable relative coordinates of the clipped operation:
x_mask_clipped = x_source + x_off_clipped;
y_mask_clipped = y_source + y_off_clipped;
This is where the original code fails -- it doesn't subtract the
destination drawable location when computing the distance that the
operation has been moved by clipping. Here's what it does when
constructing a temporary source picture:
temp_src =
glamor_convert_gradient_picture(screen, source,
extent->x1 + x_source - x_dest,
extent->y1 + y_source - y_dest,
width, height);
...
x_temp_src = -extent->x1 + x_dest;
y_temp_src = -extent->y1 + y_dest;
glamor_convert_gradient_picture needs source drawable relative
coordinates, but that is not what it's getting; it's getting
screen-relative coordinates for the destination, adjusted by the
distance between the provided source and destination operation
coordinates. We want x_source_clipped and y_source_clipped:
x_source_clipped = x_source + x_off_clipped
= x_source + x_dest_clipped - x_dest
= x_source + extents->x1 - dest->drawable.x - x_dest
x_temp_src/y_temp_src are supposed to be the coordinates of the original
operation translated to the temporary picture:
x_temp_src = x_source - x_source_clipped;
y_temp_src = y_source - y_source_clipped;
Note that x_source_clipped/y_source_clipped will never be less than
x_source/y_source because all we're doing is clipping. This means that
x_temp_src/y_temp_src will always be non-positive; the original source
coordinate can never be strictly *inside* the temporary image or we
could have made the temporary image smaller.
x_temp_src = x_source - x_source_clipped
= x_source - (x_source + x_off_clipped)
= -x_off_clipped
= x_dest - x_dest_clipped
= x_dest - (extents->x1 - dest->drawable.x)
Again, this is off by the destination origin within the screen
coordinate space.
The code should look like:
temp_src =
glamor_convert_gradient_picture(screen, source,
extent->x1 + x_source - x_dest - dest->pDrawable->x,
extent->y1 + y_source - y_dest - dest->pDrawable->y,
width, height);
x_temp_src = -extent->x1 + x_dest + dest->pDrawable->x;
y_temp_src = -extent->y1 + y_dest + dest->pDrawable->y;
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Markus Wick <markus@selfnet.de>
This reverts commit 4e9aabb6fc.
It broke kwin decorations with XRender compositing.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
We'd get a request for like 16 bytes, claim to have allocated
GLAMOR_VBO_SIZE, and then not reallocate when something a request
bigger than 16 came along. The intent was to always allocate at least
GLAMOR_VBO_SIZE.
Fixes segfaults with Xephyr -glamor_gles2 and running gnome-terminal.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The difference between the two is that XF86 has the clip helper that
lets you upload less data when rendering video that's clipped. I
don't think that's really worth the trouble, especially in a world of
compositors, so I've dropped it to get to shared code.
It turns out the clipping code was broken on xf86-video-intel anyway.
To reproduce, run without a compositor, and use another window to clip
the top half of your XV output on the glamor XV adaptor: the rendering
got confused about which half of the window was being drawn to.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
I want to expose this from Xephyr as well, both to be able to test XV
changes rapidly, and beause the XV passthrough to the host's overlay
really doesn't work out well when we glXSwapBuffers() over the
colorkey.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The core rendering paths all use the glamor_program fill functions now
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This provides glamor_solid_boxes and glamor_solid using regular GC
operations instead of calling directly to underlying rendering
functions. This will allow the old rendering code to be removed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This copies the stipple to a 8bpp pixmap and uses that to paint the
texture from.
v2: Create deep stipple pixmap without GLAMOR_CREATE_FBO_NO_FBO
v3: Fix stipple origin sign (matches tiles now). Track changes
to original stipple with damage. This isn't required by the
X spec, but java appears to depend on it, so we'll just do it.
When Glamor switches to 8bpp bitmaps, we'll be able to render
directly from them and not need this anymore.
v4: Review comments from Eric:
* Remove stray whitespace change
* Avoid "large" pixmap for stipple by using GLAMOR_CREATE_NO_LARGE
* Wrap to 80 columns
v5: Don't crash when stipple damage tracker is destroyed
The stipple damage tracker is automatically destroyed when the
associated stipple pixmap is destroyed. When this happens, just
clear the pointer from the GC rather than calling
glamor_invalidate_stipple; that function would call
DamageUnregister on the now invalid stipple damage pointer and
crash.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This makes sure the pixelization for dashed lines matches non-dashed
lines, while also speeding them up.
v2: Switch to glamor_make_current
v3: Create dash pattern pixmap without GLAMOR_CREATE_FBO_NO_FBO
v4: Adopt suggestions from Eric's review:
- Drops power-of-two alignment of our line vertex data, simplifying
the code.
- Stops reading from the VBO. While on keithp's and my machines the
VBO is mapped cached, on many implementations it will be mapped WC,
making those reads extremely expensive.
- Style fixes (line wrapping, spaces around operators).
v5: Adopt suggestions from Markus' review:
- Use max when computing zero-width dashed line length.
Don't open code max here.
- Embed CoordModePrevious into VBO writing for dashed lines
Instead of pre-computing the coord mode previous results, just
embed this in the loop which fills the vertex buffer. Saves
re-writing the request buffer, and shortens the code a bit
v6: Export glamor_destroy_gc for UXA
UXA needs to call glamor_destroy_gc from its GCFuncs, so export
it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
GL lines are nearly X compliant; you just need to fill in the last
pixel when the client hasn't requested CapNotLast.
v2: switch to glamor_make_current
v3: use miPolylines instead of custom glamor fallback path. Wrap
code to 80 columns.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This uses the same shaders as glamor_poly_glyph_blt.
v2: Wrap some long lines (changes by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Paints with textures, using a temporary buffer for overlapping copies
Performs CPU to GPU transfers for pixmaps in memory. Accelerates copy
plane when both objects are in the GPU. Includes copy_window
acceleration too.
v2: Use NV_texture_barrier for non-overlapping copies within the same
drawable
v3: Switch to glamor_make_current
v4: Do overlap check on the bounding box of the region rather than
on individual boxes
v5: Use Eric Anholt's re-written comments which provide a more accurate
description of the code
v6: Use floating point uniform for copy plane bit multiplier. This
avoids an int to float conversion in the copy plane fragment shader.
Use round() instead of adding 0.5 in copy plane. round() and +0.5
end up generating equivalent code, and performance measurements
confirm that they are the same speed. Round() is a bit clearer
though, so we'll use it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
There's no reason to use a pointer here, it just wastes time.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
These offer a simpler and more efficient means for temporarily
transitioning to CPU-accessible memory for fallback implementations.
v2: Do not attempt fallbacks with GLAMOR_DRM_ONLY pixmaps
glamor cannot transfer pixels for GLAMOR_DRM_ONLY pixmaps using
glReadPixels and glTexSubImage2D, and so there's no way to perform
fallback operations with these pixmaps.
v3: Clear ->pbo field when deleting the PBO. Otherwise, we'd reuse
the old name next time we fall back on the pixmap, which would
potentially conflict with some other pixmap that genned a new
name, or just do a lazy allocation of the name (compat GL context,
like we currently use) or error out (core GL context, like we hope
to use some day). Also, style fixes. Changes by anholt, acked by
keithp.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
It turns out putimage doesn't use the GC tile or stipple anyway, so
there's no need to do this.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The max size of renderbuffers and texture often match by accident, but
as we always use textures, we should check for the right flag. Also
check for viewport size as this may be lower and we want to render to
almost every pixmap.
Signed-off-by: Markus Wick <markus@selfnet.de>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
With GL_TEXTURE_MIN_FILTER, we configure not to use mipmaps, but
there's no real way until GL_ARB_texture_storage to dictate whether
memory should be allocated for mipmap levels or not.
GL_TEXTURE_MAX_LEVEL is a stronger hint to the driver than the
filtering that we really don't want mipmap allocations. Stops VARM
wasting warnings from the nvidia driver.
Signed-off-by: Markus Wick <markus@selfnet.de>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Part of the _nf contract is that glamor will only return FALSE if
glamor has checked that UXA can actually map the pixmaps (UXA only
allocates the BO itself in the screen pixmap and DRI2 cases, and can't
map it otherwise). Fixes server segfaults zooming in and out of
libreoffice spreadsheets.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Disabling asserts is something the user gets to manage.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Because uxa doesn't just use glamor directly, it keeps these two
functions from being wrapped so that they get called
automatically. Publishing these will allow uxa to call them directly.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
GetGlyphs is supposed to always return the full list of characters
when there is a default character available. However, if an
application opens a 16-bit two dimensional font and then draws with
8-bit requests, the bitmapGetGlyphs function in libXfont versions up
through 1.4.7 will return zero glyphs if there is no 0th row.
While this is a bug in libXfont and should be fixed there, it's easy
to protect glamor from it by simply falling through to the case that
handles GetGlyphs failures for fonts without a default character.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Was interpreting the incoming chars as 8-bits instead of 16-bits,
resulting in the wrong characters being drawn.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Even when create a pixmap which smaller than the max_fbo_size,
it may fail due to some low level driver limitation. If that is
the case, we don't need to crash the xserver. We just need to
fallback to system memory.
See the related bug at:
https://bugs.freedesktop.org/show_bug.cgi?id=71190
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Kai Wasserbach <kai@dev.carbon-project.org>
Tested-by: Erich Seifert <eseifert@error-reports.org>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
It would leak the memory allocated for the region rects in some cases.
Found with valgrind.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
There were actually two issues with the original code I believe, the
first is that the call to glamor_convert_gradient_picture wasn't
properly referencing the coordinates of the source/mask pictures. The
second, was that the updated references (x_temp/y_temp) were also
improperly set, they should always be 0 because the temp pictures are
new ones that start at (0, 0). The reason it worked in certain cases
and it didn't in others (notably the tray icons) was due to the
numbers working out based on the call to glamor_composite. In the
cases that it did work extent->x1 would equal x_dest and extent->y1
would equal y_dest, making it so what was actually passed into
glamor_convert_gradient_picture and the settings for x_temp/y_temp
were correct. However, for the case when extent->x1 wouldn't equal
x_dest and extent->y1 wouldn't equal y_dest (for example with the tray
icons) then the wrong parameters get passed into
glamor_convert_gradient_picture and x_temp/y_temp are set improperly.
Fixes issues with tray icons not appearing properly in certain cases.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=64738
Signed-Off-by: Anthony Waters <awaters1@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
These use the upload_boxes and download_boxes helpers to provide
reasonably efficient image transfer.
Fixes segfaults in Xephyr with x11perf -reps 1.
Performance improvements:
Improves -putimage10 by 548.218% +/- 88.601% (n=10).
Improves -putimage500 by 3.71014% +/- 1.5049% (n=10).
Improves -getimage10 by 8.37004% +/- 4.58274% (n=10).
No statistically significant difference on -getimage500 (n=10).
v2: Fix rebase failures, don't forget to check/prepare the gc in
putimage fallbacks (changes by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
When sourcing a picture that has no alpha values, make sure any
texture fetches wire the alpha value to one. This ensures that bits
beyond the depth of the pixmap, or bits other than the RGB values
aren't used.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes a usage of the wrong context with swrast GLX's GetImage entrypoint.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Now that we have the DIX global state for the current context, we
don't need to track nesting to try to reduce MakeCurrent overhead.
v2: Fix a mistaken replacement of a put_context with make_current in
glamor_fill_spans_gl() (caught by keithp).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com> (v1)
This matches the Xephyr behavior. Now that we know when to reset the
context in the presence of GLX, we don't need to try to keep our stuff
from being smashed by GLX.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This gets us some more context changes that are needed to make sure
the two sides render to the right drawables and manipulate the right
objects.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
There is some complicated code to support tweaking the format as we
upload from a SHM pixmap (aka the GTK icon cache), but if we weren't
sourcing from a SHM pixmap we just forgot to check that the formats
matched at all.
We could potentially be a little more discerning here (xRGB source and
ARGB mask would be fine, for example), but this will all change with
texture views anyway, so just get the rendering working for 1.16
release.
Fixes the new rendercheck gtk_argb_xbgr test.
v2: Squash in keithp's fix for checking that we have a non-NULL
pixmap, and reword the comment even more.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Bad anholt, no biscuit. Broken in commit
4c9a200725.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
It wasn't possible to build glamor from tarballs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64297#c9
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Using a pixmap as a tile or stipple means that we must have the
underlying FBO match the pixmap geometry exactly. We may want to add
some complexity here to migrate pixmaps into exact sized objects as
necessary, but for now, make the server work correctly by skipping
this optimization.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Xwayland will eventually need the current client in dri3_open. Simply
changing that API is not an option though as other drivers that
implement DRI3 will not have a matching function signature and will
crash when called.
Add a new dri3_open_client function pointer and bump
DRI3_SCREEN_INFO_VERSION so that drivers can be aware of the new
function which will be used in preference to the old function when
available.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anhole <eric@anholt.net>
Accelerates text painting with GPU-based geometry computation and stippling
v2: Simplify get_glyphs, expand single character variable names to
more descriptive ones. (Markus Wick)
v3: Rebase against the glamor_prepare_* un-renaming (changes by anholt).
Improves x11perf -f8text by 417.908% +/- 11.0144% (n=10)
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This constructs suitable shaders using the glamor_program
infrastructure for poly glyph blt, and then gets rid of the no-op
wrapper of miImageGlyphBlt.
Improves x11perf -f8text by 11.6221% +/- 1.04585% (n=10)
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This accelerates poly_fill_rect using GPU-based geometry computation
Improves x11perf -rect100 by 41.5127% +/- 7.63888% (n=10)
Improves x11perf -rect10 by 3745.72% +/- 94.7503% (n=6)
v2: Rebase on skipping the prepare rewrite for now, and fix the GLSL
1.20 and GLES2 cases (changes by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This accelerates spans operations using GPU-based geometry computation
-wellipse500 goes from about 4k/sec before the patch, to ~8k/sec in
the GLES2 fallback loop, to ~100k/sec in desktop mode.
v2: Rebase on skipping the prepare rewrite for now, and fix the GLSL
1.20 and GLES2 cases (changes by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
These use glTexSubimage2D for upload and glReadPixels for
download. There are a variety of interfaces to the basic function as
needed by the callers.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This prevents performance regressions from losing acceleration support
on older hardware as we transition to using glamor_program.c for
acceleration.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This currently computes the GLSL version in a fairly naïve fashion,
and leaves that in the screen private for other users. This will let
us update the version computation in one place later on.
v2: Drop an accidental rebase-squashed hunk (change by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
I think the sense of the return value was just flipped here; if you
return TRUE, then the calling code assumes that the pixmap *has* been
uploaded and that an FBO is available. When it tries to use it, it
crashes though. Returning false makes the caller bail back to software.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This happens when you have 4bpp pixmaps; it's not an error, so stop
flooding the log file when it happens.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
There was a spurious declaratoin in glamor.h for glamor_poly_line_nf
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The glamor_init calls to glamor_init_xv_shader were never getting run
because GLAMOR_XV was never defined. Instead of trying to make that
work, fix glamor_xv_init to make the call instead.
Further, just get rid of the glamor_fini_xv_shader function entirely
as the shader program will be destroyed when the context is destroyed
at server reset time.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Move the configuration of screen->SetWindowPixmap out from under it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
All of the glamor _nf functions must check to see if the DDX can
access the pixmap directly before returning failure back to the
driver; this restructures the point code to split out the _nf checking
from the _gl code.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
When we create a glamor pixmap by calling glamor_create_pixmap()
directly, we need to call glamor_destroy_pixmap() to destroy it.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This flag lets a DDX allocate a glamor pixmap without allocating the
texture that backs it. The DDX can then allocate the texture itself
and then set it later.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
A DDX that implements the glamor EGL functions need to pull in this
prototype but shouldn't need to pull in glamor_priv.h
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
By passing the client pointer to the dri3_open implementation, we allow
the clients to implement the open callback asynchronously. If the
client ignore count is positive after returning from dri3_open, we
assume that authentication is in progress and doesn't send the reply.
The code to send the reply is moved into a helper function, which the
implementation can call upon receiving its authenticaion reply.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This accelerates poly point when possible by off-loading all geometry
computation to the GPU.
Improves x11perf -dot performance by 28109.5% +/- 1022.01% (n=3)
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
There's no reason to mix PolyPoint and PolySegment in the same file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-off-by: Eric Anholt <eric@anholt.net>
This just adds a bunch of support code to construct shaders from
'facets', which bundle attributes needed for each layer of the
rendering system. At this point, that includes only the primitive and
the fill stuff.
v2: Correct comment in glamor transform about 1/2 pixel correction needed
for GL_POINT. (Eric Anholt)
v3: Rebase on Markus's cleanups (change by anholt)
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This adds a few helper functions to make pixmap fbo access symmetrical
between the single fbo and tiled cases.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
This lets code treat the one-fbo pixmaps more symmetrically with the
tiled pixmaps.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
Glamor has a mode where pixmaps will be constructed from numerous
small FBOs. This allows testing of the tiled pixmap code without
needing to create huge pixmaps.
However, the render glyph code assumed that it could create a pixmap
large enough for the glyph atlas. Instead of attempting to fix that
(which would be disruptive and not helpful), I've added a new pixmap
creation usage, GLAMOR_CREATE_NO_LARGE which forces allocation of a
single large FBO.
Now that we have pixmaps with varying FBO sizes, I then went around
and fixed the few places using the global FBO max size and replaced
that with the per-pixmap FBO tiling sizes, which were already present
in each large pixmap.
Xephyr has been changed to pass GLAMOR_CREATE_NO_LARGE when it creates
the screen pixmap as it doesn't want to deal with tiling either.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
We don't care that much about startup time to write different code paths...
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
The mbr path was hard coded enabled for desktop gl and disabled for
gles. But there are both desktop without mbr and GLES with mbr.
v2: Don't forget to update the fini path, too (change by anholt)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
We will never ever run on OpenGL 1.2 as we use shaders everywhere.
2.0 may be enough, but we also often use PBOs and our big shaders
won't fit into the first GLSL limits.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
It wasn't assigned yet when it was tested for GLAMOR_NO_DRI3.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
We don't use fixed function rendering, so there is no need to reset
the program at all. This lets the driver avoid checking for state
changes between draw calls when we rebind the same program.
Improves xephyr x11perf -f8text performance by 6.03062% +/- 1.64928%
(n=20)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This block was disabled since 2011, so there is likely no need to keep it any more.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Flagged by cppcheck 1.64:
[glamor/glamor_gradient.c:987] -> [glamor/glamor_gradient.c:991]:
(performance) Variable 'repeat_type_uniform_location' is
reassigned a value before the old one has been used.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
This will help tools like fips, apitrace, or INTEL_DEBUG=shader_time
provide useful information about the shaders in use.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
From the GL_ARB_vertex_buffer_object spec:
After the client has specified the contents of a mapped data store,
and before the data in that store are dereferenced by any GL commands,
the mapping must be relinquished by calling
boolean UnmapBufferARB(enum target);
Our mappings were only getting reaped at PBO destroy time, after the
upload. If the GL implementation wasn't coherent, it would have used
stale data to do the texture upload.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
If the lines aren't solid-filled vert/horiz solid-filled rectangles,
we fall back. libreoffice has some diagonal lines, and the
performance of the fallback path was atrocious. Just fall back to
mi's spans instead, so that we don't do an upload/download.
Improves x11perf -seg100 by 863.652% +/- 9.8968% (n=5)
Signed-off-by: Eric Anholt <eric@anholt.net>
Using the same idea as the previous PushPixels code, just make points
for each point in the glyph. This is an advantage over the pushpixels
fallback because we can batch the BO mappings and draw calls across
glyphs.
Improves performance of x11perf -f8text by 773.389% +/- 3.50754% (n=10).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Otherwise, mi will fall back to GetSpans()ing the bitmap, walking the
bitmap, computing spans to be filled, and calling FillSpans().
Improves x11perf -f8text by 759.373% +/- 3.33096% (n=166)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
We had regressions in CopyPlane reported by xts5, because we were
(successfully!) dereferencing the null pixmap->devPrivate.ptr for a
tile or stipple without having done a prepare.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Now that the core deals with that for us, we can avoid all this extra
carefulness.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The common pattern is to do nested if statements making calls to
prepare_access() and then pop those mappings back off in each set of
braces. Some cases checked for src == dst to avoid leaking mappings,
but others didn't. Others didn't even do the nested mappings, so a
failure in the outer map would result in trying to umap the inner and
failing.
By allowing nested mappings, we can fix both problems by not requiring
the care from the caller, plus we can allow a simpler nesting of all
the prepares in one if statement.
v2: Add a comment about nested unmap behavior, and just reuse the
glamor_access_t enum.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Nothing was using it, and it was going to complicate the
glamor_prepare_access bugfixing I'm going to do next.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The old Xephyr codebase was using the GL window system framebuffer for
the screen pixmap, but that meant you couldn't texture from it to do
operations sourcing from the screen, so in the version that landed I
instead had the screen just be a plain texture.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This unpacks the bitfield into an int size, but my experience has been
that packing bitfields doesn't matter for performance.
v2: Convert more comparisons against numbers or implicit bool
comparisons to comparisons against the enum names, and fix up some
comments.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Now the error path of allocation is more obvious: We leave things in
the a-few-boxes-at-a-time stack memory state.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The "valid_" prefix was used above to describe our allocation that
gets reused multiple times, which is totally unrelated.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Imagine a nbox that was (UINT_MAX + small number) / (4 * 2 *
sizeof(float)). We'd malloc a few bytes after the integer overflow,
but glamor_set_normalize_vcoords would write over gigabytes of heap.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
ARRAY_SIZE(vertices) is 32 (floating point values), so we need to
divide by the number of floats in a box like we do in the overflow
case below.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
No change in generated code size -- apparently the compiler figured it
out.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Just like for a caller of glamor_dri3_fd_from_pixmap(), otherwise the
consumer of that named buffer has no idea what GL chose for the
stride.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The flag is already being set at glamor_egl_screen_init() time, so no
need for the driver to separately call this. That said, leave the
function around to keep the ABI compatibility.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
This hasn't actually been a problem, since the server hasn't allocated
any glyphs before our glyph private initialization during
CreateScreenResources. But it's generally not X Server style to do
things this way.
Now that glamor itself drives both parts of glyphs setup, DDX drivers
no longer need to tell glamor to initialize glyphs. We do retain the
old public symbol so they can keep running with no changes.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
There's no reason to hide EGL from the rest of glamor, now that we
have epoxy.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The theory here was that it (which I copied from EGL) existed to fix
up context switching with indirect GLX. But indirect GLX won't even
try to set the context again unless its lastContext field is cleared,
so we need to solve this a different way.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
v2:
- Make the default buffer size a #define. (by Markus Wick)
- Fix the return offset for mapping with buffer_storage. (oops!)
v3:
- Avoid GL error at first rendering from unmapping no buffer.
- Rebase on the glBindBuffer(GL_ARRAY_BUFFER, 0) change.
v4: Rebase on Markus's vbo init changes.
v5: Fix missing put_context() in the buffer_storage fallback path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
The argument to setup_composte_vbo is the number of verts.
v2: Drop the now-unused vert_stride value.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
We should be uploading any vertex data using this kind of upload
style, since it saves a bunch of extra copies of our vertex data.
v2:
- Add a simple comment about what the function does.
- Use get_vbo_space()'s return in trapezoids, instead of dereffing
glamor_priv->vb (by Markus Wick).
- Fix the double-unmapping by moving put_vbo_space() outside of
flush_composite_rects().
- Remove the rest of the composite_vbo_offset usage, and just always
use get_vbo_space()'s return value.
v3:
- Fix failure to put_vbo_space in traps when no prims were
generated.
- Unbind the VBO from put_vbo_space(). Keeps callers from
forgetting to do so.
v4:
- Split out some changes into the previous 3 commits while trying to
track down a regression.
- Fix regression due to rebase fail where glamor_priv->vbo_offset
wasn't incremented.
v5:
- Fix GLES2 VBO sizing.
- Add a comment about resize behavior.
- Move glamor_vbo.c init code to glamor_vbo.c from
glamor_render.c. (Derived from Markus's changes, but the GLES2 fix
dropped almost all of the code in the functions).
v6:
- Drop the initial BufferData on GLES2 (it happens at put() time).
- Don't forget to set vbo_offset to the size on GLES2.
- Use char * instead of void * in the cast to return the vbo_offset.
- Resize the default FBO to 512kb, to be similar to previous
behavior. +1.66124% +/- 0.284223% (n=679) on aa10text.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
I want to extract the VBO mapping code, and as part of that I need to
get the global vbo_offset munging to stop.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
It's only used in the nonantialiased, triangle-based trapezoids path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
We don't need any current contents of the buffer, and this allows an
implementation to make a temporary BO for a streamed upload if it
wants to.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
We don't call GL in this function any more, so we can just drop the
get.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
GLES2 Xephyr is failing due to lack of glMapBuffer() with the read
bits set, and I decided to see if we can just switch everything to
glMapBufferRange(). I'm undecided, and it largely depends on whether
we find people are interested in using glamor for the windows X server.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
The render-nodes case is untested.
v2: Add a flag for wayland to suppress the native DRI3 support.
Wayland isn't running as a master itself, so it can't do the auth
on its own and has to ask the compositor to do it for us. Dropped
XXX about randr provider -- the conclusion from discussion with
keithp was that if the driver's dri3_open for a provider on a
different screen, that's a core dri3 bug.
v3: Don't put quite so much under GLAMOR_NO_DRI3, and add a comment
explaining what this is about.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
There was confusion over whether they should have egl in the name, and
they had DRI3 in the name even though they're useful to have without
DRI3.
v2: Just rename glamor_name_from_pixmap for now -- I'd accidentally
conflict-resolved in adding new parameters from a later commit.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Porting this code to be non-xorg-dependent is going to take
significant hacking, so just dump it in the glamoregl module for the
moment, so I can hack on it while regression testing.
v2: Fix compiler warnings by adding #include dix-config.h at the top,
don't try to auto-init (I'll try to fix the xv ABI later).
v3: Fix last minute breakage of having reintroduced xf86ScrnToScreen
(one of the compat macros). Just use the drawable's pScreen instead.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is not exposing the API we want long term, but it should get
existing DDX drivers up and running while we massage the API into
shape.
v2: Use LIBADD instead of LDFLAGS to fix deps on libglamor.la, and use
version 0.5.1 (the point it was forked from the external repo).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
v2: Avoid making the Ximage for the screen that we'll never use, and
drive the screen pixmap creation for glamor ourselves.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com>
There's nothing dependent on the presence of DRI3 code in the server
for this, but it does rely on GBM.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
GLES2 sensibly doesn't allow you to attach multiple shaders for the
same stage to a single program. This means we have to attach the
whole thing in one glShaderSource call.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
They never get reattached to any other program, so saving them to
unreference later is a waste of code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Assuming it was the first attribute assigned by the GL, it would have
ended up with location 0 anyway.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is the last desktop-versus-ES2 build ifdef in core glamor.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
A pair of 150 lines of inlined switch statements in a header file is
crazy.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
We only ask for GL_RGB on desktop GL as far as I can see, but now if
GLES2 did happen to ask for GL_RGB it would return a cache index
instead of -1.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
v2: Just pass in the PicturePtr to glamor_pict_format_is_compatible()
(suggestion by keithp)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Now that we're using epoxy, we can write code using both desktop and
ES symbols and decide what to use at runtime.
v2: Fix a spelling mistake (latter), since the lines were moved
anyway (noticed by Rémi Cardona). Fix condition invert in
glamor_set_composite_texture (caught by Michel Dänzer).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com> (v1)
gl_ModelViewProjection and friends aren't used in our shaders, so this
setup didn't do anything.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Those calls are only for enabling texture handling in the fixed
function pipeline, while everything we do is with shaders.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The GLX side just gets the context from the current state. That's
also something I want to do for EGL, so that the making a context is
separate from initializing glamor, but I think I need the modesetting
driver in the server before I think about hacking on that more.
The previous code was rather incestuous, along with pulling in xf86
dependencies to our dix code. The new code just initializes itself
from the current state.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
It used to be the thing that returned your dispatch table and happeend
to set up the context, but now it just sets up the context.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Libepoxy hides all the GL versus GLES2 dispatch handling for us, with
higher performance.
v2: Squash in the later patch to drop the later of two repeated
glamor_get_dispatch()es instead (caught by keithp)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
For now we're just building an uninstalled library. The extra EGL
stubs are required so that we can get the DIX building and usable
without pulling in the xf86 DDX code in glamor_egl.c.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
We're not using the extension prototypes, since you have to dlsym them
anyway. Disabling their definitions prevents them from being defined
twice (once by gl.h, once by glext.h).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We're going to want to make this DIX code instead of XF86 if at all
possible, but for now just disable it so we can work on the rest of
the build.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
v2: Also edit the one in glamor_egl.c (by anholt)
v3: Also edit the one in glamor_eglmodule.c (by anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
We only needed this because glx was directly bashing glapi tables.
Since that's not the case anymore, we should just MakeCurrent like a
real GL app.
v2: Hand-resolve against rebase onto newer server (by anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Xfuncproto.h has equivalents for these already.
v2: Adjust a couple more likelies after the rebase (anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Automake always provide -I. It is at the beginning of the list of compiler
options.
Not needed either to find glamor_egl.c source.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
In toplevel makefile:
nostdinc: only xserver, no other X modules
aclocaldir: no local macros to install
xkb_path: xserver only
"Gross hack": xserver only
In src/makefile:
SOLARIS_ASM_CFLAGS; server only
XORG_INCS: undefined variable
DIX_CFLAGS: undefined variable
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This loop needed to go one higher, not sure if this fixes the leak
MrCooper was seeing on irc, but it fixes a leak.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This is a warning, but a real problem can occur on some system.
Reported-by: Fabio Pedretti <fabio.ped@libero.it>
Reviewed-by: Axel Davy <davyaxel@free.fr>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This implements some DRI3 helpers to help the DDXs using
glamor to support DRI3.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There is one compilation error ,cast int to pointer, when built without
libgbm, reported by Gaetan Nadon.
And some error checking after memory allocation, reported by Seth Arnold.
There are still some similar issues in the largepixmap implementation.
They are relatively more complicate due to the heavy usage of RegionXXX
APIs which may allocate implicitly. Will fix them in the future.
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
Tested-by: Gaetan Nadon <memsize@videotron.ca>
This implements glamor_egl_create_textured_pixmap_from_gbm_bo,
which is similar to glamor_egl_create_textured_pixmap, except
it takes a gbm_bo as argument.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
When creating a window with recordmydesktop running, the following may happen:
create picture 0x1cd457e0, with drawable 0x1327d1f0
(SetWindowPixmap is called)
destroy picture 0x1cd457e0, with drawable 0x1cd65820
Obtaining format for pixmap 0x1327d1f0 and picture 0x1cd457e0
==7989== Invalid read of size 4
==7989== at 0x8CAA0CA: glamor_get_tex_format_type_from_pixmap (glamor_utils.h:1252)
==7989== by 0x8CAD1B7: glamor_download_sub_pixmap_to_cpu (glamor_pixmap.c:1074)
==7989== by 0x8CA8BB7: _glamor_get_image (glamor_getimage.c:66)
==7989== by 0x8CA8D2F: glamor_get_image (glamor_getimage.c:92)
==7989== by 0x29AEF2: miSpriteGetImage (misprite.c:413)
==7989== by 0x1E7674: compGetImage (compinit.c:148)
==7989== by 0x1F5E5B: ProcShmGetImage (shm.c:684)
==7989== by 0x1F686F: ProcShmDispatch (shm.c:1121)
==7989== by 0x15D00D: Dispatch (dispatch.c:432)
==7989== by 0x14C569: main (main.c:298)
==7989== Address 0x1cd457f0 is 16 bytes inside a block of size 120 free'd
==7989== at 0x4C2B60C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7989== by 0x228897: FreePicture (picture.c:1477)
==7989== by 0x228B23: PictureDestroyWindow (picture.c:73)
==7989== by 0x234C19: damageDestroyWindow (damage.c:1646)
==7989== by 0x1E92C0: compDestroyWindow (compwindow.c:590)
==7989== by 0x20FF85: DbeDestroyWindow (dbe.c:1389)
==7989== by 0x185D46: FreeWindowResources (window.c:907)
==7989== by 0x1889A7: DeleteWindow (window.c:975)
==7989== by 0x17EBF1: doFreeResource (resource.c:873)
==7989== by 0x17FC1B: FreeClientResources (resource.c:1139)
==7989== by 0x15C4DE: CloseDownClient (dispatch.c:3402)
==7989== by 0x2AB843: CheckConnections (connection.c:1008)
==7989==
(II) fail to get matched format for dfdfdfdf
The fix is to update the picture pointer when the window pixmap is changed,
so it moves the picture around with the window rather than the pixmap.
This makes FreePicture work correctly.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71088
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
n was used as a function parameter. But inside the for (i=1..n) loop,
n got reassigned as REGION_NUM_RECTS() and then decremented to zero by
the while loop. This caused the for loop to only iterate once instead
of 'n' times.
This patch renames the n parameter to numPoints.
Found by code inspection. Untested.
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
