summaryrefslogtreecommitdiffstats
path: root/src/glx/dri3_glx.c
Commit message (Collapse)AuthorAgeFilesLines
* x11: Only report supported DRI3/Present versionsDaniel Stone2018-03-301-6/+16
| | | | | | | | | | | | | The version passed to QueryVersion requests is the version that the client supports. We were just passing in whatever version of XCB was present on the system, which may not be a version that Mesa actually explicitly supports, e.g. it might bring unwanted semantics. Set specific protocol versions which we support, and only pass those. Signed-off-by: Daniel Stone <[email protected]> Fixes: 7aeef2d4efd ("dri3: allow building against older xcb (v3)") Reviewed-by: Emil Velikov <[email protected]>
* dri3: Don't fail on version mismatchDaniel Stone2018-03-201-2/+6
| | | | | | | | | | | | | 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)")
* egl/x11: Re-allocate buffers if format is suboptimalLouis-Francis Ratté-Boulianne2018-03-091-1/+3
| | | | | | | | | | 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-1/+9
| | | | | | | | | | | | 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]>
* glx/dri: Add a driconf option to disable GLX_SGI_video_syncThomas Hellstrom2018-03-081-1/+5
| | | | | | | | | | | Drivers on virtual hardware don't want to expose this extension to GLX compositors, similarly to GLX_OML_sync_control, since that significantly increases latency. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]> Reviewed-by: Deepak Rawat <[email protected]>
* loader_dri3/glx/egl: Reinstate the loader_dri3_vtable get_dri_screen callbackThomas Hellstrom2018-02-201-0/+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]>
* glx/dri3: Remove unused deviceName variableVadym Shovkoplias2017-12-011-4/+1
| | | | | | | | | deviceName string is declared, assigned and freed but actually never used in dri3_create_screen() function. Fixes: 2d94601582e ("Add DRI3+Present loader") Signed-off-by: Vadym Shovkoplias <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* glx/dri3: Fix passing renderType into glXCreateContextAdam Jackson2017-11-131-1/+2
| | | | | | | | | | Without this, trying to create a GLX_RGBA_FLOAT_TYPE_ARB context would fail, because GLX_RGBA_TYPE would be a mismatch with the fbconfig. Cc: [email protected] Reviewed-by: Tapani Pälli <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Signed-off-by: Adam Jackson <[email protected]>
* Revert "glx: Implement GLX_EXT_no_config_context (v2)"Adam Jackson2017-11-091-1/+0
| | | | | | Pushed ahead of things actually working. This reverts commit 5293b96b160b904c0e53cbce93679c3aa090f846.
* glx: Implement GLX_EXT_no_config_context (v2)Adam Jackson2017-11-091-0/+1
| | | | | | | | | | This more or less ports EGL_KHR_no_config_context to GLX. v2: Enable the extension only for those backends that support it. Khronos: https://github.com/KhronosGroup/OpenGL-Registry/pull/102 Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Adam Jackson <[email protected]>
* glx: Prepare the DRI backends for GLX_EXT_no_config_contextAdam Jackson2017-11-091-2/+3
| | | | | | | | | | | This should be safe as these backends already support the EGL version of this extension. DRI1 is not affected because it does not support GLX_ARB_create_context anyway. DRI-Windows is not prepared to implement this as there's no equivalent WGL extension, and wglCreateContextAttribs seems to really want the HDC's pixel format to be set. Signed-off-by: Adam Jackson <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glx: Implement GLX_ARB_context_flush_controlNeil Roberts2017-11-061-2/+12
| | | | | | | Reviewed-by: Adam Jackson <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Signed-off-by: Neil Roberts <[email protected]>
* loader_dri3/glx/egl: Optionally use a blit context for blitting operationsThomas Hellstrom2017-08-171-0/+1
| | | | | | | | | | | | | 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/+0
| | | | | | | | | | | 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-18/+1
| | | | | | | | | | 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 ...
* glx/dri3: Implement the flush_swapbuffers methodThomas Hellstrom2017-08-031-1/+29
| | | | | | | | Provide a dri3 implementation for the image loader extension method. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* loader: remove clamp_swap_interval()Eric Engestrom2017-08-011-7/+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]>
* dri: Optionally turn off a couple of GLX extensions based on driconf optionsThomas Hellstrom2017-06-071-2/+9
| | | | | | | | | | | | With GLX_EXT_buffer_age turned on, gnome-shell will use full-screen damage with GLX, which severely hurts performance with architectures that emulate page-flips with copies. Like vmware. We would like to be able to turn off that extension. Similarly, typically the GLX_OML_sync_control doesn't make much sense on a virtual architecture since we don't really sync to the host's vertical retrace. We'd like to be able to turn it off as well. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* dri3/GLX: Fix drawable invalidation v2Thomas Hellstrom2017-06-071-0/+6
| | | | | | | | | | | | | | | | | | | A number of internal VMware apitrace traces image comparisons fail with dri3 because the viewport transformation becomes incorrect after an X drawable resize. The incorrect viewport transformation sometimes persist until the second draw-call after a swapBuffer. Comparing with the dri2 glx code there are a couple of places where dri2 invalidates the drawable in the absence of server-triggered invalidation, where dri3 doesn't do that. When these invalidation points are added to dri3, the image comparisons become correct. v2: Addressed review comment by Michel Dänzer. Cc: <[email protected]> Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-and-tested-by: Michel Dänzer <[email protected]>
* glx: implement __DRIbackgroundCallableExtension.isThreadSafeGregory Hainaut2017-05-291-1/+11
| | | | | | | | | | | | | | | v2: bump version v3: Add code comment s/IsGlThread/IsThread/ (and variation) v4: DRI3 doesn't hit X through GL call so it is always safe Signed-off-by: Gregory Hainaut <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* glx: Implement __DRI_BACKGROUND_CALLABLEPaul Berry2017-03-161-0/+14
| | | | | | | | | | | v2: Marek: Add DRI3 support. v3: (Timothy Arceri) use C99 initializers. Acked-by: Timothy Arceri <[email protected]> Acked-by: Marek Olšák <[email protected]> Tested-by: Dieter Nützel <[email protected]> Tested-by: Mike Lothian <[email protected]>
* glx: don't expose systemTimeExtension for DRI2/DRI3/DRISWEmil Velikov2017-03-151-1/+0
| | | | | | Used/applicable to only dri1 drivers. Signed-off-by: Emil Velikov <[email protected]>
* glx: guard swap-interval functions against destroyed drawablesNicolai Hähnle2017-02-061-0/+4
| | | | | | | | | | | | | | | | The GLX specification says about glXDestroyPixmap: "The storage for the GLX pixmap will be freed when it is not current to any client." So arguably, functions like glXSwapIntervalMESA can be called after glXDestroyPixmap has been called for the currently bound GLXPixmap. In that case, the GLXDRIDrawable no longer exists, and so we just skip those calls. Cc: 17.0 <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* glx/dri3: guard in_current_context against a disappeared drawableNicolai Hähnle2017-02-061-0/+4
| | | | | | Cc: 17.0 <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* glx/dri3: handle NULL pointers in loader-to-DRI3 drawable conversionNicolai Hähnle2017-02-061-0/+2
| | | | | | | | | | | | | With a subsequent patch, we might see NULL loaderPrivates, e.g. when a DRIdrawable is flushed whose corresponding GLXDRIdrawable was destroyed. This resulted in a crash, since the loader vs. DRI3 drawable structures have a non-zero offset. Fixes glx-visuals-{depth,stencil} -pixmap Cc: 17.0 <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* dri3: Fix MakeCurrent without a default framebufferFredrik Höglund2017-01-051-4/+10
| | | | | | | | | | In OpenGL 3.0 and later it is legal to make a context current without a default framebuffer. This has been broken since DRI3 support was introduced. Cc: "13.0 12.0" <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* loader: remove loader_get_driver_for_fd() driver_typeEmil Velikov2016-10-181-1/+1
| | | | | | | | | | | | | | Reminiscent from the pre-loader days, were we had multiple instances of the loader logic in separate places and one could build a "GALLIUM_ONLY" version. Since that is no longer the case and the loaders (glx/egl/gbm) do not (and should not) require to know any classic/gallium specific we can drop the argument and the related code. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Axel Davy <[email protected]> Reviewed-by: Nicolai Hähnle <[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: add get_dri_screen() to the vtableMartin Peres2016-10-071-0/+11
| | | | | | | | | This allows querying the current active screen from the loader's common code. Cc: [email protected] Reviewed-by: Emil Velikov <[email protected]> Signed-off-by: Martin Peres <[email protected]>
* dri3: Check for dummyContext to see if the glx_context is validStefan Dirsch2016-04-271-6/+2
| | | | | | | | | | | | According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext() always returns a valid pointer. If no context is made current, it will contain dummyContext. Thus a test for NULL will always fail. https://lists.freedesktop.org/archives/mesa-dev/2016-April/113962.html Signed-off-by: Stefan Dirsch <[email protected]> Reviewed-by: Egbert Eich <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* glx: implement GLX part of interop interface (v2)Marek Olšák2016-04-201-0/+5
| | | | v2: - use const
* glx: update to updated version of EXT_create_context_es2_profileIlia Mirkin2016-02-031-1/+6
| | | | | | | | | | | | | | | | | | | | The EXT spec has been updated to: - logically combine the es2_profile and es_profile exts - allow any legal version to be requested dEQP tests request a specific ES version when using GLX, so this allows dEQP upstream to run against GLX with the appropriate X server patch (which had similar disabling logic). Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Matt Turner <[email protected]> (v1) Reviewed-by: Adam Jackson <[email protected]> (v3) v1 -> v2: - distinguish between DRI_API_GLES{,2,3} - add GLX_EXT_create_context_es_profile client-side support v2 -> v3: - fix error in computing mask
* glx/dri3: a drawable might not be bound at wait timeIlia Mirkin2015-12-211-2/+4
| | | | | | | | A trace of Alien Isolation hit this on nouveau. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-and-Tested-by: Michel Dänzer <[email protected]> Cc: "11.0 11.1" <[email protected]>
* glx/dri3: Convert to use dri3 helper in loader libraryBoyan Ding2015-11-171-1282/+125
| | | | | | | | | | | | v2: From Martin Peres - convert to the new drawable interface - delete dead code after the dropping of some vfuncs - delete the width and height attributes since they are found in the helper Signed-off-by: Boyan Ding <[email protected]> Signed-off-by: Martin Peres <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* dri3_open: don't leak the replyGuillaume Desmottes2015-07-111-0/+2
| | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90073 Signed-off-by: Guillaume Desmottes <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* glx/dri3: Add additional check for gpu offloading caseAxel Davy2015-05-111-0/+5
| | | | | | | | | | | | | | | Checks blitImage is implemented. Initially having the __DRIimageExtension extension at version 9 at least meant blitImage was supported. However some implementation do advertise version >= 9 without implementing it. CC: 10.5 <[email protected]> Reviewed-by: Dave Airlie <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* glx: report which DRI version is used when in verbose debug modeMartin Peres2015-05-071-0/+2
| | | | | | | | This should make it more obvious in bug reports while also removing any sort of guesswork for developers. Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Martin Peres <[email protected]>
* glx/dri3: Don't fail on glXSwapBuffersMscOML(dpy, window, 0, 0, 0) (v2)Mario Kleiner2014-12-141-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | glXSwapBuffersMscOML() with target_msc=divisor=remainder=0 gets translated into target_msc=divisor=0 but remainder=1 by the mesa api. This is done for server DRI2 where there needs to be a way to tell the server-side DRI2ScheduleSwap implementation if a call to glXSwapBuffers() or glXSwapBuffersMscOML(dpy,window,0,0,0) was done. remainder = 1 was (ab)used as a flag to tell the server to select proper semantic. The DRI3/Present backend ignored this signalling, treated any target_msc=0 as glXSwapBuffers() request, and called xcb_present_pixmap with invalid divisor=0, remainder=1 combo. The present extension responded kindly to this with a BadValue error and dropped the request, but mesa's DRI3/Present backend doesn't check for error codes. From there on stuff went downhill quickly for the calling OpenGL client... This patch fixes the problem. v2: Change comments to be more clear, with reference to relevant spec, as suggested by Eric Anholt. Cc: "10.3 10.4" <[email protected]> Signed-off-by: Mario Kleiner <[email protected]> Reviewed-by: Axel Davy <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glx/dri3: Request non-vsynced Present for swapinterval zero. (v3)Mario Kleiner2014-12-141-1/+13
| | | | | | | | | | | | | | | | | | | | | | Restores proper immediate tearing swap behaviour for OpenGL bufferswap under DRI3/Present. Cc: "10.3 10.4" <[email protected]> v2: Add Frank Binns signed off by for his original earlier patch from April 2014, which is identical to this one, and Chris Wilsons reviewed tag from May 2014 for that patch, ergo also for this one. v3: Incorporate comment about triple buffering as suggested by Axel Davy, and reference to relevant spec provided by Eric Anholt. Signed-off-by: Frank Binns <[email protected]> Signed-off-by: Mario Kleiner <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Axel Davy <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glx/dri3: Track separate (ust, msc) for PresentPixmap vs. PresentNotifyMsc (v2)Mario Kleiner2014-12-141-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prevent calls to glXGetSyncValuesOML() and glXWaitForMscOML() from overwriting the (ust,msc) values of the last successfull swapbuffers call (PresentPixmapCompleteNotify event), as glXWaitForSbcOML() relies on those values corresponding to the most recent completed swap, not to whatever was last returned from the server. Problematic call sequence without this patch would have been, e.g., glXSwapBuffers() ... wait ... swap completes -> PresentPixmapComplete event -> (ust,msc) updated to reflect swap completion time and count. ... wait for at least 1 video refresh cycle/vblank increment. glXGetSyncValuesOML() -> PresentNotifyMsc event overwrites (ust,msc) of swap completion with (ust,msc) of most recent vblank glXWaitForSbcOML() -> Returns sbc of last completed swap but (ust,msc) of last completed vblank, not of last completed swap. -> Client is confused. Do this by tracking a separate set of (ust, msc) for the dri3_wait_for_msc() call than for the dri3_wait_for_sbc() call. This makes the glXWaitForSbcOML() call robust again and restores consistent behaviour with the DRI2 implementation. Fixes applications originally written and tested against DRI2 which also rely on this not regressing under DRI3/Present, e.g., Neuro-Science software like Psychtoolbox-3. This patch fixes the problem. v2: Rename vblank_msc/ust to notify_msc/ust as suggested by Axel Davy for better clarity. Cc: "10.3 10.4" <[email protected]> Signed-off-by: Mario Kleiner <[email protected]> Reviewed-by: Axel Davy <[email protected]>
* glx/dri3: Fix glXWaitForSbcOML() to handle targetSBC==0 correctly. (v2)Mario Kleiner2014-12-141-0/+9
| | | | | | | | | | | | | | | | | | | | | | | targetSBC == 0 is a special case, which asks the function to block until all pending OpenGL bufferswap requests have completed. Currently the function just falls through for targetSBC == 0, returning bogus results. This breaks applications originally written and tested against DRI2 which also rely on this not regressing under DRI3/Present, e.g., Neuro-Science software like Psychtoolbox-3. This patch fixes the problem. v2: Simplify as suggested by Axel Davy. Add comments proposed by Eric Anholt. Cc: "10.3 10.4" <[email protected]> Signed-off-by: Mario Kleiner <[email protected]> Reviewed-by: Axel Davy <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glx/dri3: Implement LIBGL_SHOW_FPS=1 for DRI3/Present.Kenneth Graunke2014-10-291-1/+31
| | | | | | | | | | | | | | | v2: Use the UST value provided in the PRESENT_COMPLETE_NOTIFY event rather than gettimeofday(), which gives us the presentation time instead of the time when SwapBuffers was called. Suggested by Keith Packard. This relies on the fact that the X DRI3/Present implementations use microseconds for UST. v3: Properly ignore PresentCompleteKindMSCNotify; multiply in 64 bits (caught by Keith Packard). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Keith Packard <[email protected]> [v3] Reviewed-by: Marek Olšák <[email protected]> [v1]
* glx/dri3: Provide error diagnostics when DRI3 allocation failsKeith Packard2014-09-301-8/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of just segfaulting in the driver when a buffer allocation fails, report error messages indicating what went wrong so that we can debug things. As a simple example, chromium wraps Mesa in a sandbox which doesn't allow access to most syscalls, including the ability to create shared memory segments for fences. Before, you'd get a simple segfault in mesa and your 3D acceleration would fail. Now you get: $ chromium --disable-gpu-blacklist [10618:10643:0930/200525:ERROR:nss_util.cc(856)] After loading Root Certs, loaded==false: NSS error code: -8018 libGL: pci id for fd 12: 8086:0a16, driver i965 libGL: OpenDriver: trying /local-miki/src/mesa/mesa/lib/i965_dri.so libGL: Can't open configuration file /home/keithp/.drirc: Operation not permitted. libGL: Can't open configuration file /home/keithp/.drirc: Operation not permitted. libGL error: DRI3 Fence object allocation failure Operation not permitted [10618:10618:0930/200525:ERROR:command_buffer_proxy_impl.cc(153)] Could not send GpuCommandBufferMsg_Initialize. [10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(236)] CommandBufferProxy::Initialize failed. [10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(256)] Failed to initialize command buffer. This made it pretty easy to diagnose the problem in the referenced bug report. Bugzilla: https://code.google.com/p/chromium/issues/detail?id=415681 Signed-off-by: Keith Packard <[email protected]> Cc: [email protected] Reviewed-by: Matt Turner <[email protected]>
* glx/dri3: Use four buffers until X driver supports async flipsKeith Packard2014-09-301-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A driver which doesn't have async flip support will queue up flips without any way to replace them afterwards. This means we've got a scanout buffer pinned as soon as we schedule a flip and so we need another buffer to keep from stalling. When vblank_mode=0, if there are only three buffers we do: current scanout buffer = 0 at MSC 0 Render frame 1 to buffer 1 PresentPixmap for buffer 1 at MSC 1 This is sitting down in the kernel waiting for vblank to become the next scanout buffer Render frame 2 to buffer 2 PresentPixmap for buffer 2 at MSC 1 This cannot be displayed at MSC 1 because the kernel doesn't have any way to replace buffer 1 as the pending scanout buffer. So, best case this will get displayed at MSC 2. Now we block after this, waiting for one of the three buffers to become idle. We can't use buffer 0 because it is the scanout buffer. We can't use buffer 1 because it's sitting in the kernel waiting to become the next scanout buffer and we can't use buffer 2 because that's the most recent frame which will become the next scanout buffer if the application doesn't manage to generate another complete frame by MSC 2. With four buffers, we get: current scanout buffer = 0 at MSC 0 Render frame 1 to buffer 1 PresentPixmap for buffer 1 at MSC 1 This is sitting down in the kernel waiting for vblank to become the next scanout buffer Render frame 2 to buffer 2 PresentPixmap for buffer 2 at MSC 1 This cannot be displayed at MSC 1 because the kernel doesn't have any way to replace buffer 1 as the pending scanout buffer. So, best case this will get displayed at MSC 2. The X server will queue this swap until buffer 1 becomes the scanout buffer. Render frame 3 to buffer 3 PresentPixmap for buffer 3 at MSC 1 As soon as the X server sees this, it will replace the pending buffer 2 swap with this swap and release buffer 2 back to the application Render frame 4 to buffer 2 PresentPixmap for buffer 2 at MSC 1 Now we're in a steady state, flipping between buffer 2 and 3 waiting for one of them to be queued to the kernel. ... current scanout buffer = 1 at MSC 1 Now buffer 0 is free and (e.g.) buffer 2 is queued in the kernel to be the scanout buffer at MSC 2 Render frames, flipping between buffer 0 and 3 When the system can replace a queued buffer, and we update Present to take advantage of that, we can use three buffers and get: current scanout buffer = 0 at MSC 0 Render frame 1 to buffer 1 PresentPixmap for buffer 1 at MSC 1 This is sitting waiting for vblank to become the next scanout buffer Render frame 2 to buffer 2 PresentPixmap for buffer 2 at MSC 1 Queue this for display at MSC 1 1. There are three possible results: 1) We're still before MSC 1. Buffer 1 is released, buffer 2 is queued waiting for MSC 1. 2) We're now after MSC 1. Buffer 0 was released at MSC 1. Buffer 1 is the current scanout buffer. a) If the user asked for a tearing update, we swap scanout from buffer 1 to buffer 2 and release buffer 1. b) If the user asked for non-tearing update, we queue buffer 2 for the MSC 2. In all three cases, we have a buffer released (call it 'n'), ready to receive the next frame. Render frame 3 to buffer n PresentPixmap for buffer n If we're still before MSC 1, then we'll ask to present at MSC 1. Otherwise, we'll ask to present at MSC 2. Present already does this if the driver offers async flips, however it does this by waiting for the right vblank event and sending an async flip right at that point. I've hacked the intel driver to offer this, but I get tearing at the top of the screen. I think this is because flips are always done from within the ring, and so the latency between the vblank event and the async flip happening can cause tearing at the top of the screen. That's why I'm keying the need for the extra buffer on the lack of 2D driver support for async flips. Signed-off-by: Keith Packard <[email protected]> Acked-by: Jason Ekstrand <[email protected]> Tested-by: Dylan Baker <[email protected]>
* glx/dri3: add GPU offloading support.Axel Davy2014-07-011-32/+186
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The differences with DRI2 GPU offloading are: a) There's no logic for GPU offloading needed in the Xserver b) for DRI2, the card would render to a back buffer, and the content would be copied to the front buffer (the same buffers everytime). Here we can potentially use several back buffers and copy to buffers with no tiling to share with X. We send them with the Present extension. That means than the DRI2 solution is forced to have tearings with GPU offloading. In the ideal scenario, this DRI3 solution doesn't have this problem. However without dma-buf fences, a race can appear (if the card is slow and the rendering hasn't finished before the server card reads the buffer), and then old content is displayed. If a user hits this, he should probably revert to the DRI2 solution (LIBGL_DRI3_DISABLE). Users with cards fast enough seem to not hit this in practice (I have an Amd hd 7730m, and I don't hit this, except if I force a low dpm mode) c) for non-fullscreen apps, the DRI2 GPU offloading solution requires compositing. This DRI3 solution doesn't have this requirement. Rendering to a pixmap also works. d) There is no need to have a DDX loaded for the secondary card. V4: Fixes some piglit tests Signed-off-by: Axel Davy <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* dri3: cache pointer to back instead of looking up.Dave Airlie2014-07-011-8/+9
| | | | | | This is just prep work for the dri3 prime patches. Signed-off-by: Dave Airlie <[email protected]>
* dri3: use invalidate.Axel Davy2014-06-271-0/+7
| | | | | | | | | | This doesn't change anything to the intel DRI3 implementation, but enables the gallium implementation to use dri2.stamp instead of relying on the stamp shared with the st backend. Signed-off-by: Axel Davy <[email protected]> Reviewed-by: Ben Skeggs <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* dri3: fix image extension checking.Dave Airlie2014-06-271-10/+6
| | | | | | | | | Move the image extension setup in with all the others in bind_extensions, and improve the check to both version and function pointer. Reviewed-by: Axel Davy <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* glx: Add an error message when a direct renderer's createScreen() routine failsJon TURNEY2014-06-181-1/+3
| | | | | | | | | | | | | | | because no matching fbConfigs or visuals could be found. Nearly all the error cases in *createScreen() issue an error message to diagnose the failure to initialize before branching to handle_error. The few remaining error cases which don't should probably do the same. (At the moment, it seems this can be triggered in drisw with an X server which reports definite values for MAX_PBUFFFER_(WIDTH|HEIGHT|SIZE), because those attributes are checked for an exact match against 0.) Signed-off-by: Jon TURNEY <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri3: Enable GLX_MESA_query_renderer on DRI3 tooIan Romanick2014-05-021-2/+8
| | | | | | | | | | | | | | This should have happend around the time of commit 4680d23, but Keith's DRI3 patches and my GLX_MESA_query_renderer patches crossed in the mail. I don't have a working DRI3 setup, so I haven't been able to actually verify this. I'm hoping that someone can piglit this for me on DRI3... It's also unfortunate the DRI2 and DRI3 can't share more code. Signed-off-by: Ian Romanick <[email protected]> Cc: Keith Packard <[email protected]> Cc: "10.1" <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 19:05:50 +0000