summaryrefslogtreecommitdiffstats
path: root/src/glx/dri3_glx.c
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* glx/dri3: explicitly assign struct components for glx_*_vtableEmil Velikov2014-04-281-11/+13
| | | | | | | | ... to improve readability of code. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* glx/dri3: rework __DRIextension handlingEmil Velikov2014-04-281-9/+8
| | | | | | | | Use a const array with the extensions, rather than assigning each one to a fixed size array at runtime. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* dri_interface: Update __DRItexBufferExtensionRec to version 3Emil Velikov2014-04-281-1/+2
| | | | | | | | | | | | | | | | | | | | With commit e59fa4c46c8("dri2: release texture image.") we updated the extension without bumping the version number. The patch itself added an interface required to enable texture_from_pixmap on certain platforms. The new code was effectively never build, as it depended on __DRI_TEX_BUFFER_VERSION >= 3, which never came to be in upstream mesa. This commit bumps the version number, drops the __DRI_TEX_BUFFER_VERSION checks and resolves all the build conflicts. Additionally it add a version check as egl and dri3, as require version 2 of the extension which does not have the releaseTexBuffer hook. Cc: Juan Zhao <[email protected]> Cc: Kristian Høgsberg <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* dri3: Add GLX_EXT_buffer_age supportAdel Gadllah2014-03-131-0/+20
| | | | | | | | | | | v2: Indent according to Mesa style, reuse sbc instead of making a new swap_count field, and actually get a usable back before returning the age of the back (fixing updated piglit tests). Changes by anholt. Signed-off-by: Adel Gadllah <[email protected]> Reviewed-by: Robert Bragg <[email protected]> (v1) Reviewed-by: Adel Gadllah <[email protected]> (v2) Reviewed-by: Eric Anholt <[email protected]>
* dri3: Prefer the last chosen back when finding a new one.Eric Anholt2014-03-131-10/+7
| | | | | | | | | | | | | | With the buffer_age code, I need to be able to potentially call this more than once per frame, and it would be bad if a new special event showing up meant I chose a different back mid-frame. Now, once we've chosen a back for the frame, another find_back will choose it again since we know that it won't have ->busy set until swap. Note that this makes find_back return a buffer id instead of a backbuffer index. That's kind of a silly distinction anyway, since it's an identity mapping between the two (it's the front buffer that is at an offset). Reviewed-By: Adel Gadllah <[email protected]>
* glx: cleanup unneeded headersEmil Velikov2014-03-111-3/+0
| | | | | | | | | | | - xf86dri.h is the old dri1 header, not required by dri2 nor dri3 - fold xf86drm.h inclusiong inside dri2.h - dri3_glx does not have any drm specific dependencies - glapi.h is not required by the dri2 and dri3 codepaths Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Jon TURNEY <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glx/dri3: set the implemented version of __DRIimageLoaderExtensionEmil Velikov2014-02-231-3/+4
| | | | | | | | | ... over the one provided by the spec. Currently both versions are identical, but that is not guaranteed to be the case in the future. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* dri3: Track current Present swap mode and adjust buffer countsKeith Packard2014-01-301-5/+30
| | | | | | | | | | | | | | | | | | | | | | | | This automatically adjusts the number of buffers that we want based on what swapping mode the X server is using and the current swap interval: swap mode interval buffers copy > 0 1 copy 0 2 flip > 0 2 flip 0 3 Note that flip with swap interval 0 is currently limited to twice the underlying refresh rate because of how the kernel manages flipping. Moving from 3 to 4 buffers would help, but that seems ridiculous. v2: Just update num_back at the point that the values that change num_back change. This means we'll have the updated value at the point that the freeing of old going-to-be-unused backbuffers happens, which might not have been the case before (change by anholt, acked by keithp). Signed-off-by: Keith Packard <[email protected]> Signed-off-by: Eric Anholt <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888Keith Packard2014-01-301-0/+1
| | | | | | | | | | | | | | | | The __DRIimage createImageFromFds function takes a fourcc code, but there was no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to __DRI_IMAGE_FOURCC_SARGB8888 and then adds translations *back* to __IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers. I'll refrain from comments on whether I think having two separate sets of format defines in dri_interface.h is a good idea or not... Fixes piglit glx-tfp and glx-visuals-depth Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* dri3: Flush XCB before blocking for special eventsKeith Packard2014-01-301-0/+2
| | | | | | | | XCB doesn't flush the output buffer automatically, so we have to call xcb_flush ourselves before waiting. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* dri3: Enable GLX_INTEL_swap_eventKeith Packard2014-01-301-17/+1
| | | | | | | | | Now that we're tracking SBC values correctly, and the X server has the ability to send the GLX swap events from a PresentPixmap request, enable this extension. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* dri3: Fix dri3_wait_for_sbc to wait for completion of requested SBCKeith Packard2014-01-301-16/+39
| | | | | | | | | | | | | | | | | Eric figured out that glXWaitForSbcOML wanted to block until the requested SBC had been completed, which means to wait until the PresentCompleteNotify event for that SBC had been received. This replaces the simple sleep(1) loop (which was bogus) with a loop that just checks to see if we've seen the specified SBC value come back in a PresentCompleteNotify event yet. The change is a bit larger than that as I've broken out a piece of common code to wait for and process a single Present event for the target drawable. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* dri3: Track full 64-bit SBC numbers, instead of just 32-bitsKeith Packard2014-01-301-13/+21
| | | | | | | | | | Tracking the full 64-bit SBC values makes it clearer how those values are being used, and simplifies the wait_msc code. The only trick is in re-constructing the full 64-bit value from Present's 32-bit serial number that we use to pass the SBC value from request to event. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* dri: Fix the logger error message handling.Eric Anholt2014-01-271-1/+1
| | | | | | | | | | | Since the loader changes, there has been a compiler warning that the prototype didn't match. It turns out that if a loader error message was ever thrown, you'd segfault because of trying to use the warning level as a format string. Reviewed-by: Keith Packard <[email protected]> Tested-by: Keith Packard <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* dri3: Fix two little memory leaks.Eric Anholt2014-01-271-2/+2
| | | | | | | Noticed when valgrinding an unrelated bug. Reviewed-by: Keith Packard <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* glx: use the loader util libEmil Velikov2014-01-181-1/+3
| | | | | | | | | | v2 * Set logger to ErrorMessageF. Spotted by Kristian Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Rob Clark <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* dri3: Rename DRI3_MAX_BACK to DRI3_NUM_BACKKeith Packard2013-12-201-2/+2
| | | | | | | | | It is the maximum number of back buffers, but the name is confusing and is easily read as the maximum back buffer index. Chage to DRI3_NUM_BACK to make the intended usage a bit clearer. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri3: Free resources when drawable is destroyed.Keith Packard2013-12-201-1/+16
| | | | | | | Always nice to clean up after ourselves. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri3: Switch to libxshmfence version 1.1Keith Packard2013-12-201-2/+2
| | | | | | | | | | | libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which works when the fence is a linux futex. However, version 1.1 changes the exported datatype to 'struct xshmfence *' Require libxshmfence version 1.1 and switch the API around. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Remove redundant createNewContext function from __DRIimageDriverExtensionKristian Høgsberg2013-11-121-45/+11
| | | | | | | | | | createContextAttribs is a superset of what createNewContext provides. Also remove the function typedef, since createNewContext is deprecated and no longer used in multiple interfaces. Signed-off-by: Kristian Høgsberg <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Cc: "10.0" <[email protected]>
* dri3: Fix pixmap buf_id computation10.0-branchpointKeith Packard2013-11-071-1/+1
| | | | | | | Looks like some kind of rebase damage to me... Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glx: Add a more informative debug message in a DRI3 error path.Eric Anholt2013-11-071-0/+7
|
* Add DRI3+Present loaderKeith Packard2013-11-071-0/+1831
Uses the __DRIimage loader interfaces. v2: Fix _XIOErrors when DRI3 isn't present (change by anholt). Apparently XCB just terminates your connection if you don't check for extensions before using them, instead of returning an error like you'd expect. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 11:14:21 +0000