summaryrefslogtreecommitdiffstats
path: root/src/glx
Commit message (Collapse)AuthorAgeFilesLines
* glx: replace __FUNCTION__ with __func__Marius Predut2015-04-141-2/+2
| | | | | | | | Consistently just use C99's __func__ everywhere. No functional changes. Acked-by: Matt Turner <[email protected]> Signed-off-by: Marius Predut <[email protected]>
* glx: Include util/macros.h instead of redefining PRINTFLIKE.Jose Fonseca2015-04-131-6/+1
| | | | Reviewed-by: Roland Scheidegger <[email protected]>
* glx: Handle out-of-sequence swap completion events correctly. (v2)Mario Kleiner2015-03-171-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code for emitting INTEL_swap_events swap completion events needs to translate from 32-Bit sbc on the wire to 64-Bit sbc for the events and handle wraparound accordingly. It assumed that events would be sent by the server in the order their corresponding swap requests were emitted from the client, iow. sbc count should be always increasing. This was correct for DRI2. This is not always the case under the DRI3/Present backend, where the Present extension can execute presents and send out completion events in a different order than the submission order of the present requests, due to client code specifying targetMSC target vblank counts which are not strictly monotonically increasing. This confused the wraparound handling. This patch fixes the problem by handling 32-Bit wraparound in both directions. As long as successive swap completion events real 64-Bit sbc's don't differ by more than 2^30, this should be able to do the right thing. How this is supposed to work: awire->sbc contains the low 32-Bits of the true 64-Bit sbc of the current swap event, transmitted over the wire. glxDraw->lastEventSbc contains the low 32-Bits of the 64-Bit sbc of the most recently processed swap event. glxDraw->eventSbcWrap is a 64-Bit offset which tracks the upper 32-Bits of the current sbc. The final 64-Bit output sbc aevent->sbc is computed from the sum of awire->sbc and glxDraw->eventSbcWrap. Under DRI3/Present, swap completion events can be received slightly out of order due to non-monotic targetMsc specified by client code, e.g., present request submission: Submission sbc: 1 2 3 targetMsc: 10 11 9 Reception of completion events: Completion sbc: 3 1 2 The completion sequence 3, 1, 2 would confuse the old wraparound handling made for DRI2 as 1 < 3 --> Assumes a 32-Bit wraparound has happened when it hasn't. The client can queue multiple present requests, in the case of Mesa up to n requests for n-buffered rendering, e.g., n = 2-4 in the current Mesa GLX DRI3/Present implementation. In the case of direct Pixmap presents via xcb_present_pixmap() the number n is limited by the amount of memory available. We reasonably assume that the number of outstanding requests n is much less than 2 billion due to memory contraints and common sense. Therefore while the order of received sbc's can be a bit scrambled, successive 64-Bit sbc's won't deviate by much, a given sbc may be a few counts lower or higher than the previous received sbc. Therefore any large difference between the incoming awire->sbc and the last recorded glxDraw->lastEventSbc will be due to 32-Bit wraparound and we need to adapt glxDraw->eventSbcWrap accordingly to adjust the upper 32-Bits of the sbc. Two cases, correponding to the two if-statements in the patch: a) Previous sbc event was below the last 2^32 boundary, in the previous glxDraw->eventSbcWrap epoch, the new sbc event is in the next 2^32 epoch, therefore the low 32-Bit awire->sbc wrapped around to zero, or close to zero --> awire->sbc is apparently much lower than the glxDraw->lastEventSbc recorded for the previous epoch --> We need to increment glxDraw->eventSbcWrap by 2^32 to adjust the current epoch to be one higher than the previous one. --> Case a) also handles the old DRI2 behaviour. b) Previous sbc event was above closest 2^32 boundary, but now a late event from the previous 2^32 epoch arrives, with a true sbc that belongs to the previous 2^32 segment, so the awire->sbc of this late event has a high count close to 2^32, whereas glxDraw->lastEventSbc is closer to zero --> awire->sbc is much greater than glXDraw->lastEventSbc. --> We need to decrement glxDraw->eventSbcWrap by 2^32 to adjust the current epoch back to the previous lower epoch of this late completion event. We assume such a wraparound to a higher (a) epoch or lower (b) epoch has happened if awire->sbc and glxDraw->lastEventSbc differ by more than 2^30 counts, as such a difference can only happen on wraparound, or if somehow 2^30 present requests would be pending for a given drawable inside the server, which is rather unlikely. v2: Explain the reason for this patch and the new wraparound handling much more extensive in commit message, no code change wrt. initial version. Cc: "10.3 10.4 10.5" <[email protected]> Signed-off-by: Mario Kleiner <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* glx: remove support for non-multithreaded platformsEmil Velikov2015-03-113-29/+2
| | | | | | | | | Implicitly required for a while, although commit 9385c592c68 (mapi: remove u_thread.h) was the one that put the final nail on the coffin. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* glx: remove final reference to THREADSEmil Velikov2015-03-111-4/+0
| | | | | | | | Left over from commit 18db13f5865(mapi: THREADS was always defined, remove it) Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* Revert "glx: remove final reference to THREADS"Emil Velikov2015-03-061-0/+4
| | | | | | This reverts commit 8b15a883e0ba72c9156d7192a798bb272e0bc528. Not meant to go in yet. Lacking review.
* Revert "glx: remove support for non-multithreaded platforms"Emil Velikov2015-03-063-2/+29
| | | | | | This reverts commit 38591295cd4b68f89f257b20f476f98de3772a47. Not meant to go in yet. Lacking review.
* glx: remove unneeded ifdef _WIN32 guardEmil Velikov2015-03-061-2/+0
| | | | | | | The C99 header exists on other platforms as well. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* glx: remove support for non-multithreaded platformsEmil Velikov2015-03-063-29/+2
| | | | | | | | Implicitly required for a while, although commit 9385c592c68 (mapi: remove u_thread.h) was the one that put the final nail on the coffin. Signed-off-by: Emil Velikov <[email protected]>
* glx: remove final reference to THREADSEmil Velikov2015-03-061-4/+0
| | | | | | | Left over from commit 18db13f5865(mapi: THREADS was always defined, remove it) Signed-off-by: Emil Velikov <[email protected]>
* Fix invalid extern "C" around header inclusion.Mark Janes2015-03-052-2/+8
| | | | | | | | | | | System headers may contain C++ declarations, which cannot be given C linkage. For this reason, include statements should never occur inside extern "C". This patch moves the C linkage statements to enclose only the declarations within a single header. Reviewed-by: Jose Fonseca <[email protected]>
* glx/tests: add -I src/ to fix make checkBrian Paul2015-03-041-0/+1
| | | | Reviewed-by: Ian Romanick <[email protected]>
* glx: use ARRAY_SIZE from macros.hBrian Paul2015-03-043-1/+3
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* glx: Fix returned values of GLX_RENDERER_PREFERRED_PROFILE_MESAAndreas Boll2015-02-251-6/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | If the renderer supports the core profile the query returned incorrectly 0x8 as value, because it was using (1U << __DRI_API_OPENGL_CORE) for the returned value. The same happened with the compatibility profile. It returned 0x1 (1U << __DRI_API_OPENGL) instead of 0x2. Internal DRI defines: dri_interface.h: #define __DRI_API_OPENGL 0 dri_interface.h: #define __DRI_API_OPENGL_CORE 3 Those two bits are supposed for internal usage only and should be translated to GLX_CONTEXT_CORE_PROFILE_BIT_ARB (0x1) for a preferred core context profile and GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB (0x2) for a preferred compatibility context profile. This patch implements the above translation in the glx module. v2: Fix the incorrect behavior in the glx module Cc: "10.3 10.4 10.5" <[email protected]> Signed-off-by: Andreas Boll <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glx: do not leak the dri2 extension informationEmil Velikov2015-02-181-1/+2
| | | | | | | | | | | | The XExtensionInfo is allocated dynamically (if the pointer is NULL) in the XEXT_GENERATE_FIND_DISPLAY macro. On the other hand the macro XEXT_GENERATE_CLOSE_DISPLAY does not check/free the memory. Follow the example set by dri1 and appledri, and use a static variable. Spotted while hunting "still reachable" leaks in Waffle. Signed-off-by: Emil Velikov <[email protected]>
* darwin: build fixJeremy Huddleston Sequoia2015-02-101-0/+5
| | | | | | | | | xfont.c:237:14: error: implicit declaration of function 'GetGLXDRIDrawable' is invalid in C99 [-Werror,-Wimplicit-function-declaration] glxdraw = GetGLXDRIDrawable(CC->currentDpy, CC->currentDrawable); ^ Fixes regression from 291be28476ea60c6fb1eb2a882e2e25def5d3735 Signed-off-by: Jeremy Huddleston Sequoia <[email protected]>
* darwin: build fixJeremy Huddleston Sequoia2015-02-101-0/+1
| | | | | | ../../../src/mesa/main/compiler.h:47:10: fatal error: 'util/macros.h' file not found Signed-off-by: Jeremy Huddleston Sequoia <[email protected]>
* mesa: remove support for GCC older than 3.3.0Timothy Arceri2014-12-171-1/+1
| | | | | | | | | GCC >=3.3 has been required since 9aa3aa71386394725ce88df463d6183f62777ee5 Signed-off-by: Timothy Arceri <[email protected]> Reviewed-By: Jose Fonseca <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* glx: remove __glXstrdup()Juha-Pekka Heikkila2014-12-162-20/+0
| | | | | | | I didn't find this being used anywhere Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Matt Turner <[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-142-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* mesa: Add notes/readme files to distribution.Matt Turner2014-12-121-0/+2
|
* mesa: Add scons files to distribution.Matt Turner2014-12-121-0/+2
|
* glx/apple: Add headers to distribution.Matt Turner2014-12-121-1/+10
|
* glx/tests: Add headers to distribution.Matt Turner2014-12-121-0/+2
|
* glx: Add headers to distribution.Matt Turner2014-12-121-3/+21
|
* glx: Alphabetize source lists.Matt Turner2014-12-121-40/+40
| | | | And remove absurd tab-space-space indentation.
* glx/dri3: Implement LIBGL_SHOW_FPS=1 for DRI3/Present.Kenneth Graunke2014-10-292-2/+36
| | | | | | | | | | | | | | | 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: Fix glxUseXFont for glxWindow and glxPixmapsDaniel Manjarres2014-10-131-0/+5
| | | | | | | | | | | | | | | The current implementation of glxUseXFont requires creating a temporary pixmap and graphics context, which requires a real old-school X11 Window, not a glxDrawable. This patch changes things so that glxUseXFont will also accept a glxWindow or glxPixmap, and lookup the underlying X11 Drawable. Without this patch glxUseXFont generates a giant stream of Xerrors about bad drawables and bad graphics contexts. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54372 Cc: [email protected] Reviewed-by: Brian Paul <[email protected]>
* 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-302-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* include: move sarea.h next to it's only userEmil Velikov2014-08-212-1/+93
| | | | | | | | | The header is used by DRI1 drivers, which we've removed a while back. Now only the dri1 loader in libGL is using it, so let's move it in src/glx, and prefix it accordingly. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* SCons: Rename dri2_query_renderer.c to dri_common_query_renderer.c.Vinson Lee2014-08-211-1/+1
| | | | | | | Fix SCons build error introduced with commit 3fe7daec14282dc8e2f5c8cc547927e305009677. Signed-off-by: Vinson Lee <[email protected]>
* glx: Fix build since 679c2ef "glx/drisw: add support for ↵Jon TURNEY2014-08-215-20/+20
| | | | | | | | | | | | | DRI2rendererQueryExtension", when only building drisw renderer v2: - Move dri*_query_renderer_* into their respective dri*_priv.h headers - Drop then unnneeded include of dri2.h from dri2_query_renderer.c - Rename dri2_query_renderer.c as dri_common_query_renderer.c, as it's contents now are used for more than dri[23] Signed-off-by: Jon TURNEY <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* glx/drisw: add support for DRI2rendererQueryExtensionEmil Velikov2014-08-153-2/+58
| | | | | | | | | | The extension is used by GLX_MESA_query_renderer, which can be provided for by hardware and software drivers. v2: Use designated initializers. v3: Move drisw_query_renderer_*() to dri2_query_renderer.c Signed-off-by: Emil Velikov <[email protected]>
* glx/dri2: use mapping table for dri2_convert_glx_query_renderer_attribs()Emil Velikov2014-08-151-26/+28
| | | | Signed-off-by: Emil Velikov <[email protected]>
* glx/drisw: Move private structure declarations to a header fileEmil Velikov2014-08-152-40/+65
| | | | | | v2: Reff the correct file wrt copyright, spotted by Chia-I Signed-off-by: Emil Velikov <[email protected]>
* glx/dri3: add GPU offloading support.Axel Davy2014-07-012-32/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* glxext: Send the Drawable's ID in the GLX_BufferSwapComplete eventJasper St. Pierre2014-06-271-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | While the official INTEL_swap_event specification says that the drawable field should contain the GLXDrawable, not the Drawable, the existing DRI2 code in dri2.c that translates from DRI2_BufferSwapComplete sends out GLX_BufferSwapComplete with the Drawable's ID, so existing codebases like Clutter/Cogl rely on getting the Drawable. Match DRI2's error here and stuff the event with the X Drawable, not the GLX drawable. This fixes apps seeing wrong drawables through an indirect GLX context or with DRI3, which uses the GLX_BufferSwapComplete event directly on the wire instead of translates Present in mesa. At the same time, also modify the structure for the event to make sure that clients don't make the same mistake. This is not an API or ABI break, as GLXDrawable and Drawable are both typedefs for XID. Signed-off-by: Jasper St. Pierre <[email protected]> Reviewed-by: Axel Davy <[email protected]> Cc: "10.1 10.2" <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* glx: Added missing null check in GetDrawableAttribute()Juha-Pekka Heikkila2014-06-261-4/+8
| | | | | | | For GLX_BACK_BUFFER_AGE_EXT query added extra null check. Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glx: Don't crash on swap event for a Window (non-GLXWindow)Daniel Manjarres2014-06-201-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to GLX 1.3 there was the glxMakeCurrent() function that took a single drawable handle. The Drawable could be either a bare XID for a Window or an XID for a glxpixmap. GLX 1.3 added glxMakeContextCurrent that takes 2 handles: one for reading, one for writing. Nowadays the old glxMakeCurrent call is implemented as a call to glxMakeContextCurrent with the single handle duplicated. Because of this it is allowed to use a plain-old Window ID as an argument to glxMakeContextCurrent, although nobody really documents this sort of thing. The manpage for the NEW call specifies the arguments as GLXPixmaps, but the actual code accepts Window XIDs too, and handles them correctly. Similarly, the glxSelectEvents function can also take a bare Window XID. The "piglit" tests all use GLXWindows and/or GLXPixmaps. You never tested swap events with a bare Window XID. That is what my app was doing. The swap_events code worked with Window XIDs in mesa 7.x.y. The new code added in versions 8, 9, and 10 assumes that all buffer swap events have a GLXPixmap associated with them. Because of the historical quirks above, this is not true. Swap events for bare Window XIDs do NOT have a glxpixmap resulting in a segfault. Any app that uses the old school glxMakeCurrent call with a Window XID while trying to use swap_events will crash when the libs try to lookup the nonexistent GLXPixmap associated with the incoming swap event. I believe that the people who wrote the spec overlooked this, because the "sbc" field comes from the OML_sync extension that is defined in terms of glxpixmaps only. v2 (idr): Formatting changes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54372 Reviewed-by: Ian Romanick <[email protected]> Acked-by: Jesse Barnes <[email protected]> Cc: "10.1 10.2" <[email protected]>
* glx: Add an error message when a direct renderer's createScreen() routine failsJon TURNEY2014-06-184-4/+12
| | | | | | | | | | | | | | | 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]>
* mesa: glx: Reduce error log levelCourtney Goeltzenleuchter2014-06-121-1/+1
| | | | | | | | | | | The code that parses LIBGL_DRIVERS_PATH was printing an error for every attempted dlopen. It's not an error to have to check multiple items in the path, only an error if no suitable library is found. Reduced the load error to a warning to match behavior of dynamic linker. Signed-off-by: Courtney Goeltzenleuchter <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* glx: Fix build in GLX_DIRECT_RENDERING !GLX_USE_APPLEGL !GLX_USE_DRM caseJon TURNEY2014-06-102-6/+13
| | | | | | | | | | | | | | | | | | | Some untangling to fix building in the dri_platform=none, --enable-driglx-direct case, where only driswast can be used. Turn the test for including the glXGetScreenDriver()/glXGetScreenDriver() interface used by xdriinfo from !GLX_USE_APPLEGL into a positive form, as it is only useful when dri_platform=drm Add additional GLX_USE_DRM tests so DRI[123] renderers are only used when dri_platform=drm Note that swrast and indirect must still be disabled in the APPLEGL case at the moment, which makes things more complex than they need to be. More untangling is needed to allow that Signed-off-by: Jon TURNEY <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* Revert "glx: load dri driver with RTLD_LOCAL so dlclose never fails to unload"Marek Olšák2014-06-021-5/+5
| | | | | | | | | | | This reverts commit e3cc0d90e14e62a0a787b6c07a6df0f5c84039be. It breaks too many apps and completely breaks my desktop too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79469 We'll probably need to re-release all stable versions after this is committed. Cc: "10.1 10.2" <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 22:11:10 +0000