We're using the former only as the latter is present. Thus in some cases
we might incorrectly error out if it's missing.
Namely - glamor_glx, glamor_egl without gbm, EGL_KHR_gl_texture_2D_image
or EGL_EXT_image_dma_buf_import.
Fixes 58d54ee82df(glamor: explicitly check for GL_OES_EGL_image)
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Suggested-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Otherwise we'll fail miserably later on as we try to use
glEGLImageTargetTexture2DOES.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Fixes a regression since a2a2f6e34b. I
missed this in testing on x86, because we never fail to allocate an
FBO. We do hit this path on VC4, though.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Without this, the context of another screen may be current, or no context
at all if glamor_egl_init failed for another screen.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that it's always non-null when the pixmap is non-null, we don't
need so much of this. glamor_get_pixmap_private() itself still
accepts a NULL pixmap and returns NULL, because of glamor_render.c
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This avoids a lot of screwing around to attach our privates later. It
means that non-glamor pixmaps now gain 120 bytes of glamor privates on
64-bit (which has quite a bit of fixable bloat), and glamor pixmaps
take one less pointer of storage (not counting malloc overhead).
Note that privates start out zero-filled, which matches the callocs we
were doing when making our own privates, and in the case of an fb
pixmap that has a priv where it didn't before, the type ends up being
GLAMOR_MEMORY as we would want.
v2: Clarify that the GLAMOR_MEMORY enum must be 0 (as it was
previosuly), so that the new pixmap private behavior is as
expected. Suggested by keithp.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Keith Packard <keithp@keithp.com>
This should help people debugging when glamor does something stupid on
their driver.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
It was apparently accidentally dropped in keithp's removal of _nf
functions in 90d326fcc6.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Improves text rendering from about 284k glyphs per second to 320k
glyphs per second. There's no GL extension for probing this, because
of the philosophy of "Don't expose whether things are really in
hardware or not."
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
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 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 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>
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>
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>
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>
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>
