aboutsummaryrefslogtreecommitdiffstats
path: root/src/loader
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Rename GLX_USE_TLS to USE_ELF_TLS.Bas Nieuwenhuizen2019-08-031-1/+1
| | | | | | | These days it is not GLX only and it does not work with all TLS implementations. Reviewed-by: Eric Engestrom <[email protected]>
* Delete autotoolsDylan Baker2019-04-151-57/+0
| | | | | | | | | | Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Acked-by: Marek Olšák <[email protected]> Acked-by: Jason Ekstrand <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Matt Turner <[email protected]>
* loader: use loader_open_device() to handle O_CLOEXECEmil Velikov2019-02-261-1/+1
| | | | | | | | Some platforms lack O_CLOEXEC. The loader_open_device() handles those appropriately, so use the helper. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* iris: Initial commit of a new 'iris' driver for Intel Gen8+ GPUs.Kenneth Graunke2019-02-211-0/+9
| | | | | | | | | | | | | | | This commit introduces a new Gallium driver for Intel Gen8+ GPUs, named 'iris_dri.so' after the hardware. Developed by: - Kenneth Graunke (overall driver) - Dave Airlie (shaders, conditional render, overflow query, Gen8 port) - Chris Wilson (fencing, pinned memory, ...) - Jordan Justen (compute shaders) - Jason Ekstrand (image load store) - Caio Marcelo de Oliveira Filho (tessellation control passthrough) - Rafael Antognolli (auxiliary buffer fixes) - The rest of the i965 contributors and the Mesa community
* drm-uapi: use local files, not system libdrmEric Engestrom2019-02-143-3/+2
| | | | | | | | | There was an issue recently caused by the system header being included by mistake, so let's just get rid of this include path and always explicitly #include "drm-uapi/FOO.h" Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Kristian H. Kristensen <[email protected]>
* loader/dri3: Use strlen instead of sizeof for creating VRR property atomMichel Dänzer2019-02-051-1/+1
| | | | | | | | | | | sizeof counts the terminating null character as well, so that also contributed to the ID computed for the X11 atom. But the convention is for only the non-null characters to contribute to the atom ID. Fixes: 2e12fe425fe3 "loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property" Reviewed-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* loader: fix the no-modifiers caseRob Clark2019-01-221-6/+14
| | | | | | | | | | | Normally modifiers take precendence over use flags, as they are more explicit. But if the driver supports modifiers, but the xserver does not, then we should fallback to the old mechanism of allocating a buffer using 'use' flags. Fixes: 069fdd5f9facbd72fb6a289696c7b74e3237e70f Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Kristian H. Kristensen <[email protected]>
* dri3: initialize adaptive_sync as false before configQuerybTapani Pälli2019-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixes following errors from valgrind output: ==23388== Conditional jump or move depends on uninitialised value(s) ==23388== at 0x48B4924: loader_dri3_drawable_init (loader_dri3_helper.c:381) ==23388== by 0x48A97D2: dri3_create_drawable (dri3_glx.c:386) ==23388== by 0x489E190: driFetchDrawable (dri_common.c:369) ==23388== by 0x48A9187: dri3_bind_context (dri3_glx.c:195) ==23388== by 0x488B75C: MakeContextCurrent (glxcurrent.c:220) ==23388== by 0x488B8DB: glXMakeCurrent (glxcurrent.c:267) ==23388== by 0x10A987: ??? (in /usr/bin/glxgears) ==23388== by 0x4BEB412: (below main) (in /usr/lib64/libc-2.28.so) ==23388== ==23388== Conditional jump or move depends on uninitialised value(s) ==23388== at 0x48B5A40: loader_dri3_swap_buffers_msc (loader_dri3_helper.c:923) ==23388== by 0x48A9B7E: dri3_swap_buffers (dri3_glx.c:587) ==23388== by 0x4887A81: glXSwapBuffers (glxcmds.c:857) ==23388== by 0x10ADED: ??? (in /usr/bin/glxgears) ==23388== by 0x4BEB412: (below main) (in /usr/lib64/libc-2.28.so) Fixes: 2e12fe425fe "loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property" Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]>
* loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH propertyNicholas Kazlauskas2018-12-282-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DDX driver can be notified of adaptive sync suitability by flagging the application's window with the _VARIABLE_REFRESH property. This property is set on the first swap the application performs when adaptive_sync is set to true in the drirc. It's performed here instead of when the loader is initialized for two reasons: (1) The window's drawable can be missing during loader init. This can be observed during the Unigine Superposition benchmark. (2) Adaptive sync will only be enabled closer to when the application actually begins rendering. If adaptive_sync is false then the _VARIABLE_REFRESH property is deleted on loader init. The property is only managed on the glx DRI3 backend for now. This should cover most common applications and games on modern hardware. Vulkan support can be implemented in a similar manner but would likely require splitting the function out into a common helper function. Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]>
* loader: free error state, when checking the drawable typeKirill Burtsev2018-12-101-0/+1
| | | | | | | | | | | | | | Currently we distinguish if the drawable is a window or pixmap by checking xcb_present_select_input throws an error or not. Yet, we don't always free the error state returned by xcb. Cc: Kirill Burtsev <[email protected]> Cc: Boyan Ding <[email protected]> Fixes: 6bd9ba7d074 ("loader: Add dri3 helper") Reviewed-by: Emil Velikov <[email protected]> [Emil: add commit message, fixes tag] Signed-off-by: Emil Velikov <[email protected]>
* loader: deduplicate logger function declarationEric Engestrom2018-12-042-3/+4
| | | | | Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* loader: Factor out the common driver opening logic from each loader.Eric Anholt2018-11-165-1/+103
| | | | | | | | | | | | | I copied the code from egl_dri2.c, but the functionality was equivalent between all the loaders other than their particular environment variables. v2: Drop the logging function equivalent to loader_default_logger() (requested by Eric, Emil). Move the SCons workaround across. Drop the now-unused driGetDriverExtensions() declaration that was lost in a rebase. Reviewed-by: Eric Engestrom <[email protected]> (v1) Reviewed-by: Emil Velikov <[email protected]> (v1)
* loader: Stop using a local definition for an in-tree headerEric Anholt2018-11-161-8/+2
| | | | | | | | I need other types from the header now, and "gl.h is big" is not a good reason to duplicate definitions. Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* loader/dri3: Also wait for front buffer fence if we triggered itMichel Dänzer2018-10-181-2/+5
| | | | | | | | | | | | | In that case, we have to wait for the fence to synchronize with the corresponding drawing we triggered in the X server. Fixes incorrect display with the i965 driver and some applications, e.g. solvespace. Bugzilla: https://bugs.freedesktop.org/108097 Fixes: aefac10fecc9 "loader/dri3: Only wait for back buffer fences in dri3_get_buffer" Tested-by: Sergii Romantsov <[email protected]>
* loader/dri3: Don't wait for fence of old buffer when re-allocating itMichel Dänzer2018-09-121-1/+0
| | | | | | | | | | | We only need to wait for the fence before drawing to a buffer, not before reading from it. This might avoid hangs when re-allocating the fake front buffer, similar to the previous change. But I haven't seen any evidence that this was actually happening in practice. Tested-by: Olivier Fourdan <[email protected]>
* loader/dri3: Only wait for back buffer fences in dri3_get_bufferMichel Dänzer2018-09-121-1/+3
| | | | | | | | | | | | | | We don't need to wait before drawing to the fake front buffer, as front buffer rendering by definition is allowed to produce artifacts. Fixes hangs in some cases when re-using the fake front buffer, due to it still being busy (i.e. in use for presentation). Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/106404 Bugzilla: https://bugs.freedesktop.org/107757 Tested-by: Olivier Fourdan <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]>
* loader: Drop unused argument from dri3_update_drawable().Eric Anholt2018-09-051-4/+3
| | | | | | The argument has never been used since the function was added. Reviewed-by: Michel Dänzer <[email protected]>
* loader: add loader_open_render_node(..)Christian Gmeiner2018-08-312-0/+68
| | | | | | | This helper is almost a 1:1 copy of tegra_open_render_node(). Signed-off-by: Christian Gmeiner <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* loader: add dri_driver option to override dri driver to loadQiang Yu2018-08-171-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drirc implementation of MESA_LOADER_DRIVER_OVERRIDE which can be used to override dri driver to load. Usage: override dri driver for device with spec kernel driver name: <device kernel_driver="kernel_driver_name"> <option name="dri_driver" value="new_dri_driver" /> </device> or <device driver="loader" kernel_driver="kernel_driver_name"> <option name="dri_driver" value="new_dri_driver" /> </device> v2: add kernel_driver device attribute to specify kernel driver name instead of reuse driver attribute v3: seperate loader_get_kernel_driver_name into another patch seperate add kernel_driver attribute into another patch Suggested-by: Michel Dänzer <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Acked-by: Michel Dänzer <[email protected]> Reviewed-by: Emil Velikov <[email protected]> [v4 Emil: add HAVE_LIBDRM guard around __driConfigOptionsLoader and loader_get_dri_config_driver] Signed-off-by: Emil Velikov <[email protected]>
* xmlconfig: add kernel_driver device attributeQiang Yu2018-08-171-1/+1
| | | | | | | | | This attribute can be used by loader to apply different option to device use specific kernel driver. Signed-off-by: Qiang Yu <[email protected]> Acked-by: Michel Dänzer <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* loader: abstract loader_get_kernel_driver_name for reuseQiang Yu2018-08-171-16/+23
| | | | | | | | | This function can be shared by the following kernel_driver drirc patch. Signed-off-by: Qiang Yu <[email protected]> Acked-by: Michel Dänzer <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* loader: fix indentationEric Engestrom2018-08-022-3/+3
| | | | | Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Frank Binns <[email protected]>
* loader_dri3: Handle mismatched depth 30 formats for Prime renderoffload.Mario Kleiner2018-08-012-1/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Detect if the display (X-Server) gpu and Prime renderoffload gpu prefer different channel ordering for color depth 30 formats ([X/A]BGR2101010 vs. [X/A]RGB2101010) and perform format conversion during the blitImage() detiling op from tiled backbuffer -> linear buffer. For this we need to find the visual (= red channel mask) for the X-Drawable used to display on the server gpu. We use the same proven logic for finding that visual as in commit "egl/x11: Handle both depth 30 formats for eglCreateImage()". This is mostly to allow "NVidia Optimus" at depth 30, as Intel/AMD gpu's prefer xRGB2101010 ordering, whereas NVidia gpu's prefer xBGR2101010 ordering, so we can offload to nouveau without getting funky colors. Tested on Intel single gpu, NVidia single gpu, Intel + NVidia prime offload with DRI3/Present. Note: An unintended but pleasant surprise of this patch is that it also seems to make the modesetting-ddx of server 1.20.0 work at depth 30 on nouveau, at least with unredirected "classic" X rendering, and with redirected desktop compositing under XRender accel, and with OpenGL compositing under GLX. Only X11 compositing via OpenGL + EGL still gives funky colors. modesetting-ddx + glamor are not yet ready to deal with nouveau's ABGR2101010 format, and treat it as ARGB2101010, also exposing X-visuals with ARGB2101010 style channel masks. Seems somehow this triggers the logic in this patch on modesetting-ddx + depth 30 + DRI3 buffer sharing and does the "wrong" channel swizzling that then cancels out the "wrong" swizzling of glamor and we end up with the proper pixel formatting in the scanout buffer :). This so far tested on a NVA5 Tesla card under KDE5 Plasma as shipping with Ubuntu 16.04.4 LTS. Signed-off-by: Mario Kleiner <[email protected]> Cc: Ilia Mirkin <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* dri3: For 1.2, use root window instead of pixmap drawableOlivier Fourdan2018-07-312-3/+10
| | | | | | | | | | | | | | | | | | | get_supported_modifiers() and pixmap_from_buffers() requests both expect a window as drawable, passing a pixmap will fail as the Xserver will fail to match the given drawable to a window. That leads to dri3_alloc_render_buffer() to return NULL and breaks rendering when using GLX_DOUBLEBUFFER on pixmaps. Query the root window of the pixmap on first init, and use the root window instead of the pixmap drawable for get_supported_modifiers() and pixmap_from_buffers(). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107117 Fixes: 069fdd5 ("egl/x11: Support DRI3 v1.1") Signed-off-by: Olivier Fourdan <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* dri3: Stricter SBC wraparound handlingMichel Dänzer2018-05-221-3/+11
| | | | | | | | | | | | | | Prevents corrupting the upper 32 bits of draw->recv_sbc when draw->send_sbc resets to 0 (which currently happens when the window is unbound from a context and bound to one again), which in turn caused loader_dri3_swap_buffers_msc to calculate target_msc with corrupted upper 32 bits. This resulted in hangs with the Xorg modesetting driver as of xserver 1.20 (older versions and other drivers ignored the upper 32 bits of the target MSC, which is why this wasn't noticed earlier). Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/106351 Tested-by: Mike Lothian <[email protected]>
* dri3: Only update number of back buffers in loader_dri3_get_buffersMichel Dänzer2018-05-091-8/+11
| | | | | | | | | | | | | | And only free no longer needed back buffers there as well. We want to stick to the same back buffer throughout a frame, otherwise we can run into various issues. Bugzilla: https://bugs.freedesktop.org/105906 Bugzilla: https://bugs.freedesktop.org/106399 Fixes: 3160cb86aa92 "egl/x11: Re-allocate buffers if format is suboptimal" Reported-by: Sergii Romantsov <[email protected]> Tested-by: Eero Tamminen <[email protected]> Acked-by: Daniel Stone <[email protected]>
* dri: Add __DRI_IMAGE_FORMAT_SABGR8Tapani Pälli2018-04-241-0/+2
| | | | | | | | | | Add format definition and required plumbing to create images. Note that there is no match to drm_fourcc definition, just like with existing _DRI_IMAGE_FOURCC_SARGB8888. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri3: Don't fail on version mismatchDaniel Stone2018-03-201-2/+3
| | | | | | | | | | | | | The previous commit to make DRI3 modifier support optional, breaks with an updated server and old client. Make sure we never set multibuffers_available unless we also support it locally. Make sure we don't call stubs of new-DRI3 functions (or empty branches) which will never succeed. Signed-off-by: Daniel Stone <[email protected]> Reviewed-by: Dave Airlie <[email protected]> Fixes: 7aeef2d4efdc ("dri3: allow building against older xcb (v3)")
* dri3: allow building against older xcb (v3)Dave Airlie2018-03-162-7/+18
| | | | | | | | | | | | | | | | | | | | | I'm not sure everyone wants to be updating their dri3 in a forced march setting, this allows a nicer approach, esp when you want to build on distro that aren't brand new. I'm sure there are plenty of ways this patch could be cleaner, and I've also not built it against an updated dri3. For meson I've just left it alone, since if you are using meson you probably don't mind xcb updates, and if you are using meson you can fix this better than me. v3: just don't put a version in for dri3/present without modifiers, should allow building with 1.11 as well (feel free to supply meson followups) Signed-off-by: Dave Airlie <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* loader: Include include/drm-uapi in the autotools buildJason Ekstrand2018-03-161-0/+1
| | | | | | | | We're already including it in the meson build. This fixes build issues on systems which have a drm_fourcc.h that doesn't have modifiers. Reviewed-by: Dylan Baker <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* egl/x11: Re-allocate buffers if format is suboptimalLouis-Francis Ratté-Boulianne2018-03-092-6/+34
| | | | | | | | | | If PresentCompleteNotify event says the pixmap was presented with mode PresentCompleteModeSuboptimalCopy, it means the pixmap could possibly have been flipped instead if allocated with a different format/modifier. Signed-off-by: Louis-Francis Ratté-Boulianne <[email protected]> Reviewed-by: Daniel Stone <[email protected]>
* egl/x11: Support DRI3 v1.1Louis-Francis Ratté-Boulianne2018-03-093-47/+278
| | | | | | | | | | | | Add support for DRI3 v1.1, which allows pixmaps to be backed by multi-planar buffers, or those with format modifiers. This is both for allocating render buffers, as well as EGLImage imports from a native pixmap (EGL_NATIVE_PIXMAP_KHR). Signed-off-by: Louis-Francis Ratté-Boulianne <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Daniel Stone <[email protected]>
* loader: Add support for platform and host1x bussesThierry Reding2018-03-021-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ARM SoCs usually have their DRM/KMS devices on the platform bus, so add support for this bus in order to allow use of the DRI_PRIME environment variable with those devices. While at it, also support the host1x bus, which is effectively the same but uses an additional layer in the bus hierarchy. Note that it isn't enough to support the bus that has the rendering GPU because the loader code will also try to construct an ID path tag for a scanout-only device if it is the default that is being opened. The ID path tag for a device can be obtained by running udevadm info on the device node, as shown in this example on NVIDIA Tegra: $ udevadm info /dev/dri/card0 | grep ID_PATH_TAG E: ID_PATH_TAG=platform-50000000_host1x The corresponding OF_FULLNAME property, from which the ID_PATH_TAG is constructed, can be found in the sysfs "uevent" attribute for the card0 device's parent: $ grep OF_FULLNAME /sys/devices/platform/50000000.host1x/drm/uevent OF_FULLNAME=/host1x@50000000 Similarily, /dev/dri/card1 corresponds to the GPU: $ udevadm info /dev/dri/card1 | grep ID_PATH_TAG E: ID_PATH_TAG=platform-57000000_gpu and: $ grep OF_FULLNAME /sys/devices/platform/57000000.gpu/uevent OF_FULLNAME=/gpu@57000000 Changes in v2: - avoid confusing pre-increment in strdup() - add examples of tags to commit message Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* x11/dri3: Store raw present completion modeDaniel Stone2018-02-212-10/+4
| | | | | | | | | | The DRI3 drawable info struct currently stores a boolean for whether the last completed operation was a flip or not. As we need to track the full completion mode for handling suboptimal returns, change the 'flipping' field to the raw present completion mode from the server. Signed-off-by: Daniel Stone <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* x11/dri3: Don't open-code ARRAY_SIZEDaniel Stone2018-02-212-3/+4
| | | | | | Signed-off-by: Daniel Stone <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* loader: Fix compiler warnings about truncating the PCI ID path.Eric Anholt2018-02-201-8/+7
| | | | | | | | | | | | | My build was producing: ../src/loader/loader.c:121:67: warning: ‘%1u’ directive output may be truncated writing between 1 and 3 bytes into a region of size 2 [-Wformat-truncation=] and we can avoid this careful calculation by just using asprintf (as we do elsewhere in the file). Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* loader_dri3/glx/egl: Reinstate the loader_dri3_vtable get_dri_screen callbackThomas Hellstrom2018-02-202-1/+12
| | | | | | | | | | | | | | | Removing this callback caused rendering corruption in some multi-screen cases, so it is reinstated but without the drawable argument which was never used by implementations and was confusing since the drawable could have been created with another screen. Cc: "17.3 18.0" [email protected] Fixes: 5198e48a0d (loader_dri3/glx/egl: Remove the loader_dri3_vtable get_dri_screen callback) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105013 Reported-by: Daniel van Vugt <[email protected]> Tested-by: Timo Aaltonen <[email protected]> Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: add xbgr support adjacent to xrgbIlia Mirkin2018-02-191-0/+4
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Daniel Stone <[email protected]>
* dri: fromPlanar() can return NULL as a valid resultLouis-Francis Ratté-Boulianne2018-02-151-1/+4
| | | | | | | | | | | | | It was assumed that fromPlanar() could return NULL to mean that the planar image is the same as the parent DRI image. That assumption wasn't made everywhere though. Let's fix things and make sure that all callers understand a NULL result Signed-off-by: Louis-Francis Ratté-Boulianne <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Daniel Stone <[email protected]>
* loader: let compiler figure out the length of the stringEric Engestrom2018-01-251-2/+1
| | | | | | | Basically, turn comment into code Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* autotools: include meson build files in tarballDylan Baker2018-01-191-1/+1
| | | | | | | | | | | | This adds the meson.build, meson_options.txt, and a few scripts that are used exclusively by the meson build. v2: - Remove accidentally included changes needed to test make dist with LLVM > 3.9 Signed-off-by: Dylan Baker <[email protected]> Acked-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* loader/dri3: Try to make sure we only process our own NotifyMSC eventsMichel Dänzer2018-01-172-22/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We were using a sequence counter value to wait for a specific NotifyMSC event. However, we can receive events from other clients as well, which may already be using higher sequence numbers than us. In that case, we could stop processing after an event from another client, which could have been received significantly earlier. This would have multiple undesirable effects: * The computed MSC and UST values would be lower than they should be * We could leave a growing number of NotifyMSC events from ourselves and other clients in XCB's special event queue I ran into this with Firefox and Thunderbird, whose VSync threads both seem to use the same window. The result was sluggish screen updates and growing memory consumption in one of them. Fix this by checking the XCB sequence number and MSC value of NotifyMSC events, instead of using our own sequence number. v2: * Use the Present event ID for the sequence parameter of the PresentNotifyMSC request, as another safeguard against processing events from other clients * Rebase on drawable mutex changes Reviewed-by: Nicolai Hähnle <[email protected]> # v1
* loader/dri3: Avoid freeing renderbuffers in useThomas Hellstrom2018-01-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Upon reception of an event that lowered the number of active back buffers, the code would immediately try to free all back buffers with an id equal to or higher than the new number of active back buffers. However, that could lead to an active or to-be-active back buffer being freed, since the old number of back buffers was used when obtaining an idle back buffer for use. This lead to crashes when lowering the number of active back buffers by transitioning from page-flipping to non-page-flipping presents. Fix this by computing the number of active back buffers only when trying to obtain a new back buffer. Fixes: 15e208c4cc ("loader/dri3: Don't accidently free buffer holding new back content") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104214 Cc: "17.3" <[email protected]> Tested-by: Andriy.Khulap <[email protected]> Tested-by: Vadym Shovkoplias <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Thomas Hellstrom <[email protected]>
* loader/dri3: Add XRGB2101010 and ARGB2101010 support.Mario Kleiner2018-01-031-0/+2
| | | | | | | | | To allow DRI3/Present buffer sharing for 10 bpc buffers. Signed-off-by: Mario Kleiner <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* meson: add dep_thread to every lib that includes threads.hEric Engestrom2017-12-071-1/+1
| | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104141 Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* meson: Fix overlinkage of dri3 loaderDylan Baker2017-12-041-2/+1
| | | | | | | | | | | | This was covering for underinkage elsewhere. With that fixed these can be removed. v2: - sort dependencies Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Jon Turney <[email protected]> (v1) Reviewed-by: Eric Engestrom <[email protected]> (v1) Reviewed-by: Emil Velikov <[email protected]>
* loader/dri3: Improve dri3 thread-safetyThomas Hellstrom2017-11-132-18/+69
| | | | | | | | | | | | | | | | | | | | | | | | | It turned out that with recent changes that call into dri3 from glFinish(), it appears like different thread end up waiting for X events simultaneously, causing deadlocks since they steal events from eachoter and update the dri3 counters behind eachothers backs. This patch intends to improve on that. It allows at most one thread at a time to wait on events for a single drawable. If another thread intends to do the same, it's put to sleep until the first thread finishes waiting, and then it rechecks counters and optionally retries the waiting. Threads that poll for X events never pulls X events off the event queue if there are other threads waiting for events on that drawable. Counters in the dri3 drawable structure are protected by a mutex. Finally, the mutex we introduce is never held while waiting for the X server to avoid unnecessary stalls. This does not make dri3 drawables completely thread-safe but at least it's a first step. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102358 Fixes: d5ba75f8881 "st/dri2 Plumb the flush_swapbuffer functionality through to dri3" Signed-off-by: Thomas Hellstrom <[email protected]> Acked-by: Nicolai Hähnle <[email protected]>
* radeonsi: remove unused field in the PCI ID tableMarek Olšák2017-11-071-1/+1
| | | | Reviewed-by: Alex Deucher <[email protected]>
* loader: drop empty function aliasEric Engestrom2017-10-261-11/+2
| | | | | | | While at it, drop the duplicate return. Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* loader: use drmGetDeviceNameFromFd2 from libdrmGreg V2017-10-261-35/+1
| | | | | | | | | | | Reduce code duplication and automatically benefit from OS-specific fixes to libdrm (e.g. in FreeBSD ports). API was introduced with 2.4.74 and we already require 2.4.75 globally. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103283 Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>