summaryrefslogtreecommitdiff
path: root/glamor
AgeCommit message (Collapse)AuthorFilesLines
2020-11-04glamor: Update pixmap's devKind when making it exportableAlex Goins1-0/+3
When making a pixmap exportable, glamor will currently create a temporary exported pixmap backed by a GBM bo, with the devKind updated to the stride of the bo. However, when the backing of the exported pixmap is swapped into the original, the devKind of the original is not updated. Some GBM bos may get implicitly padded, in which case the devKind of the pixmap will not match the stride of the backing bo. For example, an 800x600 pixmap will have a devKind of 3200, but the bo's stride will be 3328. This can cause corruption with PRIME, when the sink uses the wrong stride to display the shared pixmap. This commit changes glamor_make_pixmap_exportable() to update the devKind of the original pixmap after it swaps exported pixmap's backing into it, keeping everything consistent. Fixes issue #1018. Signed-off-by: Alex Goins <agoins@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2020-09-15Consolidate fourcc.hMichel Dänzer1-1/+1
Move the copy in hw/xfree86/common to include/, and remove the one in hw/kdrive/src/. Fixes DIX glamor code including an xfree86 DDX header.
2020-08-24glamor: Fix glamor_poly_fill_rect_gl xRectangle::width/height handlingMichel Dänzer1-4/+14
(Using GLSL 1.30 or newer) The width/height members of xRectangle are unsigned, but they were being interpreted as signed when converting to floating point for the vertex shader, producing incorrect drawing for values > 32767. v2: * Use separate GL_UNSIGNED_SHORT vertex attribute for width/height. (Eric Anholt) Reviewed-by: Eric Anholt <eric@anholt.net>
2020-08-18glamor: Fix debugging callback setup on GLESAdam Jackson1-1/+2
You will not find GL_ARB_* extensions in a GLES context by definition, the droid you're looking for is named GL_KHR_debug. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2020-07-05Fix spelling/wording issuesAlan Coopersmith5-7/+7
Most (but not all) of these were found by using codespell --builtin clear,rare,usage,informal,code,names but not everything reported by that was fixed. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2020-01-08glamor_egl: Reject OpenGL < 2.1 early onLubomir Rintel1-11/+28
The Etnaviv driver on GC2000 reports desktop OpenGL 1.3 but also OpenGL ES 2.0. However, with the modesetting driver, GLES2 never gets a chance: [ 11233.393] Require OpenGL version 2.1 or later. [ 11233.393] (EE) modeset(0): Failed to initialize glamor at ScreenInit() time. [ 11233.393] (EE) Fatal server error: [ 11233.395] (EE) AddScreen/ScreenInit failed for driver 0 Let's reject old desktop GL early on, just like XWayland seems to do. This is perhaps a slightly bit more complicated that one would expect, since we need to call eglMakeCurrent() before we query the GL version. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-12-20glamor: Only use dual blending with GLSL >= 1.30Michel Dänzer1-0/+1
It can't be used with older GLSL. Fixes a crash when attempting to anyway. Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/97 Fixes: e7308b6c7756 "glamor: Add support for CA rendering in a single pass." Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2019-11-26glamor: Add a function to get the driver name via EGL_MESA_query_driverKenneth Graunke2-0/+18
This maps to eglGetDisplayDriverName if EGL_MESA_query_render is supported, otherwise it returns NULL.
2019-11-22glamor: make sure the correct FBO is clearedDor Askayo1-1/+2
This also removes an unnecesary call to glDrawBuffer. Signed-off-by: Dor Askayo <dor.askayo@gmail.com> Fixes: 0e9a0c20 - "xwayland: clear pixmaps after creation in rootless mode" Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/933 Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-11-07xwayland: clear pixmaps after creation in rootless modeDor Askayo4-0/+44
When a pixmap is created with a backing FBO, the FBO should be cleared to avoid rendering uninitialized memory. This could happen when the pixmap is rendered without being filled in its entirety. One example is when a top-level window without a background is resized. The pixmap would be reallocated to prepare for more pixels, but uninitialized memory would be rendered in the resize offset until the client sends a frame that fills these additional pixels. Another example is when a new top-level window is created without a background. Uninitialized memory would be rendered after the pixmap is allocated and before the client sends its first frame. This issue is only apparent in OpenGL implementations that don't zero the VRAM of allocated buffers by default, such as RadeonSI. Signed-off-by: Dor Askayo <dor.askayo@gmail.com> Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/636 Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-11-04glamor/xwayland: Define EGL_NO_X11Hans de Goede2-0/+2
Define EGL_NO_X11 everywhere were we also define MESA_EGL_NO_X11_HEADERS, EGL_NO_X11 is the MESA_EGL_NO_X11_HEADERS equivalent for the egl headers shipped with libglvnd. This fixes the xserver not building with the libglvnd-1.2.0 headers: In file included from /usr/include/EGL/eglplatform.h:128, from /usr/include/epoxy/egl_generated.h:11, from /usr/include/epoxy/egl.h:46, from glamor_priv.h:43, from glamor_composite_glyphs.c:25: /usr/include/X11/Xlib.h:222:2: error: conflicting types for 'GC' 222 | *GC; | ^~ In file included from glamor.h:34, from glamor_priv.h:32, from glamor_composite_glyphs.c:25: ../include/gcstruct.h:282:3: note: previous declaration of 'GC' was here 282 | } GC; | ^~ Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2019-10-14Revert https://gitlab.freedesktop.org/xorg/xserver/merge_requests/235Michel Dänzer3-99/+113
Caused assertion failures / crashes with Xorg. Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/916
2019-10-11glamor: check for non NULL pixmap at close_screenEmil Velikov1-1/+5
DDX such as Xorg, Xwayland & Xephyr do not destroy the pixmap before they call into CloseScreen. At the same time Xvfb (support for glamor coming with later commit) do. As such the pixmap will be NULL and we'll crash out. Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2019-10-11glamor_egl: check for non NULL pixmap at egl_close_screenEmil Velikov1-2/+7
DDX such as Xorg, Xwayland & Xephyr do not destroy the pixmap before they call into CloseScreen. At the same time Xvfb (support for glamor coming with later commit) do. As such the pixmap will be NULL and we'll crash out. Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2019-10-11glamor_egl: override the CloseScreen/DestroyPixmap earlierEmil Velikov1-6/+6
Currently we wrap the EGL CloseScreen/DestroyPixmap callbacks after the glamor ones. Thus upon teardown, we'll end calling things in the wrong order. Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2019-10-11glamor_egl: remove unneeded xf86 includes/GLAMOR_FOR_XORGEmil Velikov2-7/+0
As of last commit, all of glamor_egl ix xf86 agnostic, so adjust the includes and drop the GLAMOR_FOR_XORG instances. Note the macro is still used for glamor_xv_init() which pulls xf86. v2: Drop GLAMOR_FOR_XORG guards (Michel Dänzer) Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2019-10-11glamor_egl: disable modifiers via glamor_init()Emil Velikov2-5/+6
Currently we parse through xf86Info.debug to check if we the modifiers should be disabled. Handle that within DDX and pass GLAMOR_NO_MODIFIERS into the glamor_init() flags. This allows individual DDX control over the setting - say when modifiers are woking OK with one implementation and not the other. Most importantly, this removes the final xf86 piece from the codebase. Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2019-10-11glamor_egl: don't use ScrnInfoRec::privatesEmil Velikov2-54/+41
Move from the xf86 specific ScrnInfoRec::privates, to the dix private handling. Since there's no FreeScreen function in ScreenPtr, fold the former within the existing CloseScreen. Users, such as modesetting are updated, and out of tree drivers will need equivalent, yet trivial, patch. Note: we need to ensure that the screen private is unset and the screen callbacks are restored in our CloseScreen function. Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2019-10-11glamor_egl: move glamor_egl_cleanup() further upEmil Velikov1-18/+18
We'll use the function within glamor_egl_close_screen() with next patch. Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2019-10-11glamor/egl: remove unused function pointersEmil Velikov1-2/+0
The following two members of glamor_egl_screen_private has been unused for a little while now. CreateScreenResources CloseScreen Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2019-10-11glamor_egl: use LogMessage over xf86DrvMsgEmil Velikov1-19/+17
Much of glamor already use LogMessage() so we might as well be consistent. This effectively paves the way of making glamor-egl xf86 agnostic. Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2019-05-29glamor: Make pixmap exportable from `gbm_bo_from_pixmap()`Olivier Fourdan1-5/+14
If a pixmap is not exportable, `glamor_gbm_bo_from_pixmap()` would fail and the modesettings driver would consequently fail to do its page flip, which both prevents Present from working and also fill up the logs with error messages such as: (EE) modeset(0): Failed to get GBM bo for flip to new front. (EE) modeset(0): present flip failed Refactor the code so that `glamor_gbm_bo_from_pixmap()` takes care of making the pixmap exportable. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Signed-off-by: Yuxuan Shui yshui@hadean.com See-also: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/131 Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/68 Fixes: 86b2d8740a "glamor: Reallocate pixmap storage without modifiers if necessary"
2019-05-28glamor: return status from `glamor_set_pixmap_texture()`Olivier Fourdan2-3/+5
Chnage the API for `glamor_set_pixmap_texture()` to return a status, so that the caller can know whether it succeeded or not. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
2019-05-28glamor: Fix more fallback paths with non-GXcopy rop with GLESAdam Jackson1-1/+1
Desktop GL can handle arbitrary rops here, GLES can't. The switch statement attempts to optimize some cases that GLES can still handle if we precompute the right pixel value, but we were then throwing that pixel value away and using gc->fgPixel anyway. Fix this, and now xts-render passes against glamor+gles.
2019-04-17glamor: Introduce a central place for our pixmap format/type handling.Eric Anholt10-145/+209
We had various helper functions trying to come up with the internalformat/format/type/render formats for pixmaps, and it's much nicer to just detect what those should be once at startup. This gives us a chance to do the right thing for GLES. It also, notably, fixes our format/type for depth 15 and 16 setup for desktop GL, so that we actually allocate 16bpp (GL_RGB/565) on most drivers instead of 32bpp (GL_RGB/UBYTE). GLES still has regressions over desktop (2 regressions in llvmpipe XTS, many in rendercheck), but I think this is a good baseline. Signed-off-by: Eric Anholt <eric@anholt.net>
2019-04-17glamor: Plumb the pixmap through fbo creation instead of a "format"Eric Anholt4-34/+33
For GLES, we're going to need a lot more logic for picking the iformat/format/type of texture setup, so we'll want the pixmap's depth and is_cbcr flag. Signed-off-by: Eric Anholt <eric@anholt.net>
2019-04-17glamor: Stop trying to store the pixmap's "format" in glamor_pixmap_fbo.Eric Anholt5-18/+9
"format" is a bit of a confused term (internalformat vs GL format), and all we really needed was "is this GL_RED?" Signed-off-by: Eric Anholt <eric@anholt.net>
2019-04-17glamor: Switch the gl_flavor to a boolean is_gles.Eric Anholt7-34/+27
There are only 2 flavors we are distinguishing -- GL versions are handled separately. Signed-off-by: Eric Anholt <eric@anholt.net>
2019-03-28glamor: Fix a compiler warning since the recent OOM fixes.Eric Anholt1-2/+0
Signed-off-by: Eric Anholt <eric@anholt.net>
2019-03-11glamor: pixmap FBO may not be allocatedOlivier Fourdan1-0/+3
If `_glamor_create_tex()` fails to allocate the FBO because of GL_OUT_OF_MEMORY error, the `pixmap_priv->fbo` is NULL. However, `glamor_get_pixmap_texture()` doesn't actually check whether the `pixmap_priv->fbo` is NULL and will segfault with a NULL pointer dereference trying to access the `pixmap_priv->fbo->tex`. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/647
2019-03-08glamor: Fallback to system memory for RW PBO buffer allocationPaul Kocialkowski1-5/+6
We currently support two modes of operation for RW PBO buffers: one that allocates a pack buffer with GL memory and one that uses system memory when the former is not supported. Since allocation with system memory is less likely to fail, add a fallback to system memory when GL memory failed instead of bailing out. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
2019-03-08glamor: Propagate glamor_prepare_access failures in copy helpersPaul Kocialkowski1-2/+6
glamor_prepare_access can fail for a few reasons, especially when failing to allocate a PBO buffer. Take this in account and bail in the copy helpers that call the helper when a failure happens. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
2019-03-08glamor: Error out on out-of-memory when allocating PBO for FBO accessPaul Kocialkowski2-0/+18
Packed buffer allocation (which happens at glBufferData time with the buffer bound) can fail when there is no GL memory left. Pick up the error when it happens, print a proper error message, do some cleanup and bail. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
2019-03-08glamor: Propagate FBO allocation failure for picture to texture uploadPaul Kocialkowski1-1/+3
When uploading a picture to a texture, glamor_upload_picture_to_texture calls glamor_pixmap_ensure_fbo to ensure that there is backing FBO. The FBO will be allocated if the picture's drawable pixmap does not have one already, which can fail when there is no GL memory left. glamor_upload_picture_to_texture checks that the call succeeded and will enter the failure path if it did not. However, unlike many other functions in glamor, this one has ret set to TRUE initially, so it needs to be set to FALSE when a failure happens. Otherwise, the error is not propagated and the failure path return TRUE. This leads to a fault when trying to access the FBO pointer later on. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
2019-01-10glamor/glamor_egl.c: EGL_NATIVE_PIXMAP_KHR do not require contextsRohan Garg1-1/+1
From https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_image_pixmap.txt * If <target> is EGL_NATIVE_PIXMAP_KHR, and <ctx> is not EGL_NO_CONTEXT, the error EGL_BAD_PARAMETER is generated. Fixes: a5321ea4 ("Allow to create textured pixmaps from gbm_bo without using gem names")
2019-01-10glamor/egl: Drop a implicit depends on EGL_KHR_no_config_contextRohan Garg1-1/+9
Not all platforms provide EGL_KHR_no_config_context, this ensures that eglCreateContext works on such platforms by querying for a config.
2018-12-21glamor: Remove unused format_for_pixmap helperMichel Dänzer1-6/+0
Reviewed-by: Eric Anholt <eric@anholt.net>
2018-12-20glamor: Allow HW acceleration for more RENDER formatsMichel Dänzer1-4/+4
As long as the storage format is compatible. v2: * Remove explicit cases for formats handled by the default case. Reviewed-by: Eric Anholt <eric@anholt.net>
2018-12-20glamor: Check that storage format is compatible with RENDER formatMichel Dänzer1-8/+17
Fixes x2r10g10b10 related rendercheck failures. Reviewed-by: Eric Anholt <eric@anholt.net>
2018-10-23glamor: Add support for exporting depth 15/8 pixmapsMichel Dänzer1-0/+6
This allows X to run with glamor at these depths.
2018-10-05glamor/egl: Avoid crashing on broken configurationsAdam Jackson1-0/+5
0a9415cf apparently can tickle bugs in the GL stack where glGetString returns NULL, presumably because the eglMakeCurrent() didn't manage to actually install a dispatch table and you're hitting a stub function. That's clearly not our bug, but if it happens we should at least not crash. Notice this case and fail gently. Signed-off-by: Adam Jackson <ajax@redhat.com>
2018-09-28glamor_egl: Don't initialize on llvmpipeAdam Jackson1-1/+10
Mesa started supporting GL_OES_EGL_image on llvmpipe in 17.3, after this commit: commit bbdeddd5fd0b797e1e281f058338b3da4d98029d Author: Gurchetan Singh <gurchetansingh@chromium.org> Date: Tue Aug 1 14:49:33 2017 -0700 st/dri: add drisw image extension That's pretty cool, but it means glamor now thinks it can initialize on llvmpipe. This is almost certainly not what anyone wants, as glamor on llvmpipe is pretty much uniformly slower than fb. This fixes both Xorg and Xwayland to refuse glamor in such a setup. Xephyr is left alone, both because glamor is not the default there and because Xephyr+glamor+llvmpipe is one of the easier ways to get xts to exercise glamor. The (very small) downside of this change is that you lose DRI3 support. This wouldn't have helped you very much (since an lp glamor blit is slower than a pixman blit), but it would eliminate the PutImage overhead for llvmpipe's glXSwapBuffers. A future change should add DRI3 support for the fb-only case. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
2018-09-12glamor: fix leak of fs_getcolor_source.Dave Airlie1-3/+5
This is created using XNFstrdup, so it needs to be freed. Pointed out by coverity. Signed-off-by: Dave Airlie <airlied@redhat.com>
2018-09-11glamor: add support for NV12 in XvJulien Isorce1-25/+155
Useful when video decoders only output NV12. Currently glamor Xv only supports I420 and YV12. Note that Intel's sna supports I420, YV12, YUY2, UYVY, NV12. Test: xvinfo | grep NV12 Test: gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! xvimagesink v2: Combine the two texture2Ds on u_sampler. Signed-off-by: Julien Isorce <jisorce@oblong.com> Tested-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2018-09-11glamor: add support for GL_RGJulien Isorce5-3/+18
Allow to upload the CbCr plane of an NV12 image into a GL texture. Signed-off-by: Julien Isorce <jisorce@oblong.com> Tested-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2018-09-07glamor: Add support for exporting depth 16 pixmaps.Eric Anholt1-8/+14
With a patch to mesa to expose rgb565 pbuffers even on a server with only depth 24 and 32 visuals, fixes dEQP-EGL.functional.render.single_context.gles2.rgb565_pbuffer. Those pbuffers (or at least something renderable with 565) are required by the current CTS for GLES3, and having the server support DRI3 on those pixmaps means that we can avoid having a different path for EGL pbuffers compared to pixmaps. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
2018-06-27glamor: Work around GEM usage v2Thomas Hellstrom1-2/+12
KMS drivers are not required to support GEM. In particular, vmwgfx doesn't support flink and handles and names are identical. Getting a bo name should really be part of a lower level API, if needed, but in the mean time work around this by setting the name identical to the handle if GEM isn't supported. This fixes modesetting driver dri2 on vmwgfx. Reviewed-by: Deepak Rawat <drawat@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2018-06-27glamor: Unbreak glamor_fd_from_pixmap()Lyude Paul4-25/+43
When support for allocating GBM BOs with modifiers was added, glamor_fd_from_pixmap() was changed so that it would return an error if it got a bo with modifiers set from glamor_fds_from_pixmap(). The problem is that on systems that support BOs with modifiers, glamor_fds_from_pixmap() will always return BOs with modifiers. This means that glamor_fd_from_pixmap() was broken entirely, which broke a number of other things including glamor_shareable_fd_from_pixmap(), which meant that modesetting using multiple GPUs with the modesetting DDX was also broken. Easy reproducer: - Find a laptop with DRI prime that has outputs connected to the dedicated GPU and integrated GPU - Try to enable one display on each using the modesetting DDX - Fail Since there isn't a way to ask for no modifiers from glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap() function used by both glamor_fds_from_pixmap() and glamor_fd_from_pixmap() that calls down to the appropriate glamor_egl_fd*_from_pixmap() function. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
2018-06-07glamor: Enable modifier support for xfree86 tooAdam Jackson1-2/+2
This was left disabled in 1.20.0, it's time to start being sure it works. Signed-off-by: Adam Jackson <ajax@redhat.com> Acked-by: Keith Packard <keithp@keithp.com> Acked-by: Daniel Stone <daniels@collabora.com>
2018-05-28glamor: Propagate glamor_fds_from_pixmap error in glamor_fd_from_pixmapMichel Dänzer1-1/+1
glamor_fds_from_pixmap returns 0 on error, but we were treating that as success, continuing with uninitialized stride and fd values. Also bail if the offset isn't 0, same as in dri3_fd_from_pixmap. v2: * Reduce to a simple one-liner fix (Emil Velikov) Fixes: c8c276c9569b "glamor: Implement PixmapFromBuffers and BuffersFromPixmap" Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-28 18:24:31 +0000