summaryrefslogtreecommitdiffstats
path: root/src/loader/loader_dri3_helper.c
Commit message (Collapse)AuthorAgeFilesLines
* 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: fix indentationEric Engestrom2018-08-021-1/+1
| | | | | 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-011-1/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-311-3/+9
| | | | | | | | | | | | | | | | | | | 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-161-6/+16
| | | | | | | | | | | | | | | | | | | | | 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]>
* egl/x11: Re-allocate buffers if format is suboptimalLouis-Francis Ratté-Boulianne2018-03-091-6/+33
| | | | | | | | | | 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-091-45/+263
| | | | | | | | | | | | 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]>
* x11/dri3: Store raw present completion modeDaniel Stone2018-02-211-9/+3
| | | | | | | | | | 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-211-2/+3
| | | | | | Signed-off-by: Daniel Stone <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* loader_dri3/glx/egl: Reinstate the loader_dri3_vtable get_dri_screen callbackThomas Hellstrom2018-02-201-1/+11
| | | | | | | | | | | | | | | 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/dri3: Try to make sure we only process our own NotifyMSC eventsMichel Dänzer2018-01-171-18/+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]>
* loader/dri3: Improve dri3 thread-safetyThomas Hellstrom2017-11-131-18/+59
| | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* loader/dri3: Don't accidently free buffer holding new back contentThomas Hellstrom2017-10-051-7/+9
| | | | | | | | | | | Avoid freeing buffers holding new back content (with GLX_SWAP_COPY_OML and GLX_SWAP_EXCHANGE_OML) Prevously that would have resulted in back buffer content becoming incorrect after a swap, although I haven't managed to trigger such a situation yet. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]>
* loader/dri3: Avoid resizing existing buffers in dri3_find_back_allocThomas Hellstrom2017-10-051-10/+31
| | | | | | | | Resize only in loader_dri3_get_buffers(), where the dri driver has a chance to immediately update the viewport. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]>
* loader/dri3: Use local blits and local buffers when resizingThomas Hellstrom2017-10-051-26/+24
| | | | | | | | | When a drawable is resized, and we fill the resized buffers, with data from the old buffers, use a local blit if there is a local buffer (back or fake front), and we have local blitting capability. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]>
* loader/dri3: Make sure we invalidate a drawable on size changeThomas Hellstrom2017-09-071-0/+2
| | | | | | | | | If we're seeing a drawable size change, in particular after processing a configure notify event, make sure we invalidate so that the state tracker picks up the new geometry. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader/dri3: Process event after each fence waitThomas Hellstrom2017-09-071-7/+10
| | | | | | | | | | This tries to mimic dri2 behaviour where events are typically processed while waiting for X replies. Since, during steady-state dri3 rendering, we seldom wait for xcb replies, and haven't enabled any automatic event processing, instead check for events after a fence wait. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader/dri3: Use client local back to front blit in copySubBuffer if availableThomas Hellstrom2017-09-051-9/+7
| | | | | | | | | | | | | The copySubBuffer functionality always attempted a server side blit from back to fake front if a fake front was present, and we weren't displaying on a remote GPU. Now that we always have local blit capability on modern drivers, first attempt a local blit, and only if that fails, try the server blit. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Axel Davy <[email protected]>
* dri3: Move up fourcc utility functionLouis-Francis Ratté-Boulianne2017-08-211-21/+21
| | | | | | | It will be needed in next patches. Signed-off-by: Louis-Francis Ratté-Boulianne <[email protected]> Reviewed-by: Daniel Stone <[email protected]>
* loader_dri3: Make sure we have an updated back v3Thomas Hellstrom2017-08-171-10/+49
| | | | | | | | | | | | | | | | With GLX_SWAP_COPY_OML and GLX_SWAP_EXCHANGE_OML it may happen in situations when glXSwapBuffers() is immediately followed by for example another glXSwapBuffers() or glXCopyBuffers() or back buffer age querying, that we haven't yet allocated and initialized a new back buffer because there was no GL rendering in between. Make sure that we have a back buffer in those situations. v2: Eliminate the drawable have_back_format member. v3: Make sure we re-initialize the back even if it exists. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader_dri3: Support GLX_SWAP_EXCHANGE_OMLThomas Hellstrom2017-08-171-3/+5
| | | | | | | | | Add support for the exchange swap method. Since we're now forcing a fake front buffer and we exchange the back and fake front on swaps, we don't need to add much code. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader_dri3: Eliminate the back-to-fake-front copyThomas Hellstrom2017-08-171-19/+31
| | | | | | | | | | Eliminate the back-to-fake-front copy by exchanging the previous back buffer and the fake front buffer. This is a gain except when we need to preserve the back buffer content but in that case we still typically gain by replacing a server-side blit by a client side non-flushing blit. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader_dri3: Remove buffer_type from buffer metadataThomas Hellstrom2017-08-171-2/+0
| | | | | | | | It's not used anywhere and now that we're about to exchange back- and fake fronts it doesn't serve a purpose. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader_dri3: Support GLX_SWAP_COPY_OMLThomas Hellstrom2017-08-171-1/+8
| | | | | | | | Support the GLX_SWAP_COPY_OML method. When this method is requested, we use the same swapbuffer code path as EGL_BUFFER_PRESERVED. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader_dri3: Honor the request to preserve back buffer contentThomas Hellstrom2017-08-171-3/+51
| | | | | | | | | | | | | | | | | | | | EGL uses the force_copy parameter to loader_dri3_swap_buffers_msc() to indicate that it wants to preserve back buffer contents across a buffer swap. While the loader then turns off server-side page-flipping there's nothing to guarantee that a new backbuffer isn't chosen when EGL starts to render again, and that buffer's content is of course undefined. So rework the functionality: If the client supports local blits, allow server-side page flipping and when a new back is grabbed, if needed, blit the old back's content to the new back. If the client doesn't support local blits, disallow server-side page-flipping to avoid a client deadlock and then, when grabbing a new back buffer, sleep until the old back is idle, which may take a substantial time depending on swap interval. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader_dri3: Increase the likelyhood of reusing the current swap bufferThomas Hellstrom2017-08-171-0/+6
| | | | | Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader_dri3/glx/egl: Optionally use a blit context for blitting operationsThomas Hellstrom2017-08-171-66/+177
| | | | | | | | | | | | | The code was relying on us always having a current context for client local image blit operations. Otherwise the blit would be skipped. However, glxSwapBuffers, for example, doesn't require a current context and that was a common problem in the dri1 era. It seems the problem has resurfaced with dri3. If we don't have a current context when we want to blit, try creating a private dri context and maintain a context cache of a single context. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader_dri3/glx/egl: Remove the loader_dri3_vtable get_dri_screen callbackThomas Hellstrom2017-08-171-11/+1
| | | | | | | | | | | It's not very usable since in the rare, but definitely existing case that we don't have a current context, it will return NULL. Presumably it will always be safe to use the dri screen the drawable was created with for operations on that drawable. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* loader: drop the [gs]et_swap_interval callbacksEmil Velikov2017-08-041-6/+4
| | | | | | | | | | Having two callbacks to manage a single int seems like an overkill. Use a cached copy and update that when needed. Signed-off-by: Emil Velikov <[email protected]> --- Might want to look if the dimensions dance in .query_surface ... speaking of which close to nobody implements that ...
* dri3: Wait for all pending swapbuffers to be scheduled before touching the frontThomas Hellstrom2017-08-021-0/+18
| | | | | | | | | | | | This implements a wait for glXWaitGL, glXCopySubBuffer, dri flush_front and creation of fake front until all pending SwapBuffers have been committed to hardware. Among other things this fixes piglit glx-copy-sub-buffers on dri3. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Cc: <[email protected]>
* loader: remove clamp_swap_interval()Eric Engestrom2017-08-011-1/+0
| | | | | | | | | | As of last commit, no invalid swap interval can be stored, so there's no need to sanitize the values when reading them anymore. Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* loader/dri3: Use dri3_find_back in loader_dri3_swap_buffers_mscThomas Hellstrom2017-07-131-1/+1
| | | | | | | | | | | | | | | | If the application hasn't done any drawing since the last call, we would reuse the same back buffer which was used for the previous swap, which may not have completed yet. This could result in various issues such as tearing or application hangs. In the normal case, the behaviour is unchanged. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97957 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101683 Cc: [email protected] [Michel Dänzer: Make Thomas' fix from bugzilla actually work as intended, write commit log]
* egl/dri3: implement query surface hookBrendan King2017-02-281-0/+23
| | | | | | | | | | | | | | This is a DRI3 version of a change made for DRI2 (4d6d4f939e0af4252e0b, "egl/dri2: implement query surface hook"), that fixed failures in dEQP-EGL.functional.resize.surface_size.grow and dEQP-EGL.functional.resize.surface_size.shrink. Cc: Tapani Pälli <[email protected]> Cc: Mark Janes <[email protected]> Cc: Chad Versace <[email protected]> Signed-off-by: Brendan King <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Cc: "17.0" <[email protected]>
* loader/dri3: Unify the style of function pointer calls in structsBoyan Ding2017-01-131-39/+39
| | | | Signed-off-by: Boyan Ding <[email protected]>
* loader/dri3: constify the loader_dri3_vtableEmil Velikov2016-10-141-1/+1
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* loader/dri3: import prime buffers in the currently-bound screenMartin Peres2016-10-071-1/+11
| | | | | | | | | | | | | | | | | | This tries to mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and fixes many applications when using DRI3: - Totem with libva on hw-accelerated decoding - obs-studio, using Window Capture (Xcomposite) as a Source - gstreamer with VAAPI v2: - introduce get_dri_screen() in the dri3 loader's vtable (krh) Tested-by: Timo Aaltonen <[email protected]> Tested-by: Ionut Biru <[email protected]> Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759 Reviewed-by: Emil Velikov <[email protected]> Signed-off-by: Martin Peres <[email protected]>
* loader/dri3: Always use at least two back buffersMichel Dänzer2016-09-061-3/+1
| | | | | | | | | | | This can make a significant difference for performance with some extreme test cases such as vblank_mode=0 glxgears. Fixes: 1e3218bc5ba2 ("loader/dri3: Overhaul dri3_update_num_back") Cc: "12.0 11.2" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97549 Reviewed-by: Jason Ekstrand <[email protected]> Tested-by: Dieter Nützel <[email protected]>
* loader/dri3: Overhaul dri3_update_num_backMichel Dänzer2016-08-251-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Always use 3 buffers when flipping. With only 2 buffers, we have to wait for a flip to complete (which takes non-0 time even with asynchronous flips) before we can start working on the next frame. We were previously only using 2 buffers for flipping if the X server supports asynchronous flips, even when we're not using asynchronous flips. This could result in bad performance (the referenced bug report is an extreme case, where the inter-frame stalls were preventing the GPU from reaching its maximum clocks). I couldn't measure any performance boost using 4 buffers with flipping. Performance actually seemed to go down slightly, but that might have been just noise. Without flipping, a single back buffer is enough for swap interval 0, but we need to use 2 back buffers when the swap interval is non-0, otherwise we have to wait for the swap interval to pass before we can start working on the next frame. This condition was previously reversed. Cc: "12.0 11.2" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97260 Reviewed-by: Frank Binns <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* loader/dri3: Destroy Present event context when destroying drawable v2Michel Dänzer2016-08-041-1/+7
| | | | | | | | | | | Without this, the X server may accumulate stale Present event contexts if a client ends up creating and destroying DRI drawables for the same window. v2: Based on Chris Wilson's review: * Use xcb_present_select_input_checked so that protocol errors generated by old X servers can be handled gracefully * Use xcb_discard_reply() instead of free(xcb_request_check())
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-21 11:58:25 +0000