Funky new vblank counter regressions in Linux 4.4-rc1

On Wed, Nov 25, 2015 at 08:04:26PM +0100, Mario Kleiner wrote: > On 11/25/2015 06:46 PM, Ville Syrjälä wrote: > > On Wed, Nov 25, 2015 at 06:24:13PM +0100, Mario Kleiner wrote: > >> On 11/23/2015 09:24 PM, Ville Syrjälä wrote: > >>> On Mon, Nov 23, 2015 at 06:58:34PM +0100, Mario Kleiner

[PATCH] drm/mm: use list_next_entry

To make the intention clearer, use list_next_entry instead of list_entry. Signed-off-by: Geliang Tang --- include/drm/drm_mm.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h index a58cc6c..fc65118 100644 ---

[PATCH 2/7] drm/vmwgfx: fix a problematic usage of WARN_ON()

WARN_ON() takes a condition rather than a format string. This patch converted WARN_ON() to WARN() instead. Signed-off-by: Geliang Tang --- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c

[PATCH 1/7] drm/msm/mdp: fix a problematic usage of WARN_ON()

WARN_ON() takes a condition rather than a format string. This patch converted WARN_ON() to WARN() instead. Signed-off-by: Geliang Tang --- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h

Funky new vblank counter regressions in Linux 4.4-rc1

The only difference to reality would be that this simulated vblank would start 5 scanlines earlier than the true hw vblank, but i can't see how the core would care about that. > One problem with that approach could be that the vblank event and page > flip event would be delievered at different times if you keep using the > page flip interrupt, but I'm not sure that would be a problem. At least > they should both have the same timestamp and counter value. > That's the same now, and the timestamps and counts be the same. I'll check with my measurement equipment that the timestamps will be still accurate wrt. to reality. Attached is my current patch i wanted to submit for the drm core's drm_update_vblank_count(). I think it's good to make the core somewhat robust against potential kms driver bugs or glitches. But if you wouldn't like that patch, there wouldn't be much of a point sending it out at all. thanks, -mario -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-irq-Make-drm_update_vblank_count-more-robust.patch Type: text/x-patch Size: 4244 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/81a0dd3c/attachment-0001.bin>

Funky new vblank counter regressions in Linux 4.4-rc1

On Wed, Nov 25, 2015 at 06:24:13PM +0100, Mario Kleiner wrote: > On 11/23/2015 09:24 PM, Ville Syrjälä wrote: > > On Mon, Nov 23, 2015 at 06:58:34PM +0100, Mario Kleiner wrote: > >> > >> > >> On 11/23/2015 04:51 PM, Ville Syrjälä wrote: > >>> On Mon, Nov 23, 2015 at 04:23:21PM +0100, Mario

Funky new vblank counter regressions in Linux 4.4-rc1

On Wed, Nov 25, 2015 at 06:24:13PM +0100, Mario Kleiner wrote: > On 11/23/2015 09:24 PM, Ville Syrjälä wrote: > > On Mon, Nov 23, 2015 at 06:58:34PM +0100, Mario Kleiner wrote: > >> > >> > >> On 11/23/2015 04:51 PM, Ville Syrjälä wrote: > >>> On Mon, Nov 23, 2015 at 04:23:21PM +0100, Mario

Funky new vblank counter regressions in Linux 4.4-rc1

On 11/25/2015 06:58 PM, Ville Syrjälä wrote: > On Wed, Nov 25, 2015 at 06:24:13PM +0100, Mario Kleiner wrote: >> On 11/23/2015 09:24 PM, Ville Syrjälä wrote: >>> On Mon, Nov 23, 2015 at 06:58:34PM +0100, Mario Kleiner wrote: On 11/23/2015 04:51 PM, Ville Syrjälä wrote: >

[PATCH i915 v8 2/2] i915: wait for fence in prepare_plane_fb

In intel_prepare_plane_fb, if fb is backed by dma-buf, wait for exclusive fence v2: First commit v3: Remove object_name_lock acquire Move wait from intel_atomic_commit() to intel_prepare_plane_fb() v4: Wait only on exclusive fences, interruptible with no timeout v5: Style tweaks to more

[PATCH i915 v8 1/2] i915: wait for fence in mmio_flip_work_func

If a buffer is backed by dmabuf, wait on its reservation object's exclusive fence before flipping. v2: First commit v3: Remove object_name_lock acquire v4: Move wait ahead of mark_page_flip_active Use crtc->primary->fb to get GEM object instead of pending_flip_obj use_mmio_flip() return

[PATCH i915 v8 0/2] PRIME Synchronization

Hello all, For a while now, I've been working to fix tearing with PRIME. This is the same as the eighth version of the DRM component for PRIME synchronization, In this version, use_mmio_flip() tests against !reservation_object_test_signaled_rcu(test_all=FALSE) instead of directly checking for an

Funky new vblank counter regressions in Linux 4.4-rc1

On 11/23/2015 09:24 PM, Ville Syrjälä wrote: > On Mon, Nov 23, 2015 at 06:58:34PM +0100, Mario Kleiner wrote: >> >> >> On 11/23/2015 04:51 PM, Ville Syrjälä wrote: >>> On Mon, Nov 23, 2015 at 04:23:21PM +0100, Mario Kleiner wrote: On 11/20/2015 04:34 PM, Ville Syrjälä wrote: > On

[RFC PATCH 1/2] drm: add support for for clk and de polarity

Am Mittwoch, den 15.07.2015, 17:50 +0200 schrieb Manfred Schlaegl: > To get full support for parallel and LVDS displays with drm: > Add representation for clock and data enable polarity in drm_display_mode > flags (similar to HSYNC/VSYNC polarity) and update conversion functions > from/to

[Bug 80419] XCOM: Enemy Unknown Causes lockup

during the resume operation? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/59db2767/attachment.html>

[PATCH 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl

Unfortunately the entire improved docbook project died at KS in a massive bikeshed. So we need to carry this around in drm private trees forever :( I discussed this with Dave at kernel summit and he's ok with this. I'll maintain the asciidoc support in topic/kerneldoc in the drm-intel.git tree.

[PATCH 4/5] scripts/kernel-doc: Use asciidoc instead of markdown

By popular demand. This needs some adjustment/fixups after feeding snippets to asciidoc since compared to markdown asciidown escapes xml markup and doesn't just let it through. The other noticeable change is that build times increase a lot - we need to launch the markup process per-snippet,

[PATCH 3/5] scripts/kernel-doc: Improve Markdown results

From: Danilo Cesar Lemes de Paula Using pandoc as the Markdown engine cause some minor side effects as pandoc includes main tags for almost everything. Original Markdown support approach removes those main tags, but it caused some inconsistencies when that tag is

[PATCH 2/5] scripts/kernel-doc: Adding infrastructure for markdown support

From: Danilo Cesar Lemes de Paula Markdown support is given by calling an external tool, pandoc, for all highlighted text on kernel-doc. Pandoc converts Markdown text to proper Docbook tags, which will be later translated to pdf, html or other targets. This adds

[PATCH 1/5] drm/doc: Convert to markdown

From: Danilo Cesar Lemes de Paula DRM Docbook is now Markdown ready. This means its doc is able to use markdown text on it. * Documentation/DocBook/drm.tmpl: Contains a table duplicated from drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore *

[PATCH 0/5] Better markup for GPU DocBook

Hi all, As you might know the markup improvements have been discussed at kernel summit: https://lwn.net/Articles/662930/ Unfortunately it died in a bikeshed fest due to an alliance of people who think docs are useless and you should just read code and others who didn't know how to build the

[PATCH] drm: adv7511: really enable interrupts for EDID detection

Hi Wolfram, On Wed, Nov 25, 2015 at 3:48 PM, Wolfram Sang wrote: > >> > This has been tackled as well now. The clock for the GPIO controller was >> > off, so no interrupt was passed through. >> >> Thanks a lot for your efforts! When you have time, can you please show >> me the patch that fixes

[PATCH] drm/mm: use list_next_entry

On Wed, Nov 25, 2015 at 09:23:07PM +0800, Geliang Tang wrote: > To make the intention clearer, use list_next_entry instead of list_entry. > > Signed-off-by: Geliang Tang Applied to drm-misc, thanks. -Daniel > --- > include/drm/drm_mm.h | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-)

[PATCH 1/3] of: Add United Radiant Technology Corporation vendor prefix

vailable URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/a6f65117/attachment.sig>

[PATCH 9/9] drm/i915: Kill intel_dp_dpcd_read_wake

This read wake with retries were initially added by 2 commits: commit 61da5fab ("drm/i915/dp: retry link status read 3 times on failure") commit 899526d9 ("drm/i915/dp: try to read receiver capabilities 3 times when detecting") Both mentioning section 9.1 of the 1.1a DisplayPort spec, that

[PATCH 8/9] drm/i915: Move dummy aux read from read_wake to aux_transfer.

The goal is to kill the intel_dp_dpcd_read_wake for all, however Jani noticed we cannot ignore the case introduced by: 'commit f6a1906 ("drm/i915: Do a dummy DPCD read before the actual read")' So, instead for removing this for now let's apply that dummy read to all DP_AUX_NATIVE_READ cases.

[PATCH 7/9] drm/i915: Fix random aux transactions failures.

Mainly aux communications on sink_crc were failing a lot randomly on recent platforms. The first solution was to try to use intel_dp_dpcd_read_wake, but then it was suggested to move retries to drm level. Since drm level was already taking care of retries and didn't want to through random retries

[PATCH 6/9] drm/i915: Avoid EBUSY retry on intel_dp_aux_ch.

EBUSY retries are already in place at drm level. We don't need to replicate the job here. v2: rebase on top of EAGAIN x EBUSY retries change at drm. EBUSY retry at DRM is now handling the msleep(1). Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 22 +++---

[PATCH 5/9] drm: Wait 1ms before retrying aux transactions on EBUSY.

DP Specs isn't really clear about the amount of retries, but for cases it mentions retries it also mention times that vary from 300us to 1ms. For many cases hardware can handled the timeouts before retry is possible and allowed, but for many other cases it is better to wait and give time so the

[PATCH 4/9] drm/i915: Use EAGAIN instead EBUSY for aux retry.

Current EBUSY meaning is immediately retry, but this is about to change. DRM aux transfer is about to change and make EAGAIN the immediately retry and use EBUSY to wait a bit for aux channels to recover for any error or wake up. This has no functional change if the EAGAIN support is in place

[PATCH 3/9] drm/nouveau: Use EAGAIN instead EBUSY for aux retry.

Current EBUSY meaning is immediately retry, but this is about to change. DRM aux transfer is about to change and make EAGAIN the immediately retry and use EBUSY to wait a bit for aux channels to recover for any error or wake up. This has no functional change if the EAGAIN support is in place

[PATCH 2/9] drm: Introduce EAGAIN handling for immediatelly aux retries

The goal here is to offload aux retries handling from the drivers to drm. However there are 2 differents cases for retry: 1. Immediately retry - Hardware already took care of needed timeouts before answering that a retry is possible. 2. Busy - Wait some time and retry.

[PATCH 1/9] drm: Improve drm_dp_aux DocBook.

This patch converts drm_dp_aux doc to new per-member comment layout that 4.4 supports as suggested by Daniel. But also: 1. to let the split text with sense this patch also introduce a brief general AUX channel definition. 2. Remove .name and .dev duplications from the original text. 3. Improve

[PATCH 0/9] Organize aux retries v3

This new version first convert the drm_dp_aux doc to new per-member comment layout and introduce a propper documentation for EBUSY/EAGAIN retry cases, as requested by Daniel. Also accept many suggestions from Jani, but mostly removes the Nacked patch and introduce a new one to handle the missed

[PATCH 2/2] drm: Serialise multiple event readers

Do you need to take the mutex around other event pullers as well? So that no such process thinks it has pulled all events and then suddenly an event reappears? I think there was some event pulling code in one of the drivers, but I might be wrong. The close() code should be safe against this.

[PATCH] drm: adv7511: really enable interrupts for EDID detection

Hi Wolfram, On Wed, Nov 25, 2015 at 6:05 AM, Wolfram Sang wrote: > >> Note that I could not yet read EDID with Magnus' Koelsch. > > This has been tackled as well now. The clock for the GPIO controller was > off, so no interrupt was passed through. Thanks a lot for your efforts! When you have

[Intel-gfx] [PATCH v8 1/2] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

On Mon, Nov 02, 2015 at 12:33:47PM -0800, Rafael Antognolli wrote: > +static int __init drm_dp_aux_dev_init(void) > +{ > + int res; > + > + drm_dp_aux_dev_class = class_create(THIS_MODULE, "drm_dp_aux_dev"); > + if (IS_ERR(drm_dp_aux_dev_class)) { > + res =

[PATCH 2/2] drm: Serialise multiple event readers

On Wed, Nov 25, 2015 at 03:44:04PM +0100, Thomas Hellstrom wrote: > Do you need to take the mutex around other event pullers as well? We would. I checked in drm/*.c for other users, but not the drivers. A quick git grep doesn't show any likely candidates, they appear to be private event lists. >

[PATCH 2/2] drm: Serialise multiple event readers

The previous patch reintroduced a race condition whereby a failure in one reader may allow a second reader to see out-of-order events. Introduce a mutex to serialise readers so that an event is completed in its entirety before another reader may process an event. The two readers may race against

[PATCH 1/2] drm: Drop dev->event_lock spinlock around faulting copy_to_user()

In commit cdd1cf799bd24ac0a4184549601ae302267301c5 Author: Chris Wilson Date: Thu Dec 4 21:03:25 2014 + drm: Make drm_read() more robust against multithreaded races I fixed the races by serialising the use of the event by extending the dev->event_lock. However, as Thomas pointed out,

Funky new vblank counter regressions in Linux 4.4-rc1

On Wed, Nov 25, 2015 at 1:21 PM, Mario Kleiner wrote: > On 11/25/2015 06:58 PM, Ville Syrjälä wrote: >> >> On Wed, Nov 25, 2015 at 06:24:13PM +0100, Mario Kleiner wrote: >>> >>> On 11/23/2015 09:24 PM, Ville Syrjälä wrote: On Mon, Nov 23, 2015 at 06:58:34PM +0100, Mario Kleiner

[Bug 108401] GPU lockup with [AMD/ATI] RV730 XT [Radeon HD 4670]

https://bugzilla.kernel.org/show_bug.cgi?id=108401 --- Comment #6 from Alex Deucher --- Please report Mesa bugs on https://bugs.freedesktop.org -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH] drm: imx: convert to drm_crtc_send_vblank_event()

On Wed, Nov 25, 2015 at 10:25:39AM +, Russell King wrote: > ipu_crtc_handle_pageflip() was calling drm_send_vblank_event() with > a pipe argument of -1. Commit cc1ef118fc09 ("drm/irq: Make pipe > unsigned and name consistent") now makes this error obvious, as we > now may get a warning from:

[PATCH] drm: imx: convert to drm_crtc_send_vblank_event()

Hi Russell, Am Mittwoch, den 25.11.2015, 10:25 + schrieb Russell King: > ipu_crtc_handle_pageflip() was calling drm_send_vblank_event() with > a pipe argument of -1. Commit cc1ef118fc09 ("drm/irq: Make pipe > unsigned and name consistent") now makes this error obvious, as we > now may get a

[pull] radeon and amdgpu drm-fixes-4.4

Hi Dave, Radeon and amdgpu fixes for 4.4: - DPM fixes for r7xx devices - VCE fixes for Stoney - GPUVM fixes - Scheduler fixes The following changes since commit 2d591ab18a77e25def2c483b495e07b42a3ea79f: Merge tag 'drm-intel-fixes-2015-11-19' of git://anongit.freedesktop.org/drm-intel into

drm_read() to paged-out memory area

On Tue, Nov 24, 2015 at 10:14:20PM +, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 09:49:58PM +0100, Thomas Hellstrom wrote: > > Hi, Chris, > > > > With your new (well sort of) implementation of drm_read() it looks to me > > like a drm_read() to a paged out > > memory area will always fail

[Bug 93101] GPU Fault almost burned the CPU

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/28feef0d/attachment-0001.html>

[PATCH] drm: imx: convert to drm_crtc_send_vblank_event()

ipu_crtc_handle_pageflip() was calling drm_send_vblank_event() with a pipe argument of -1. Commit cc1ef118fc09 ("drm/irq: Make pipe unsigned and name consistent") now makes this error obvious, as we now may get a warning from: if (WARN_ON(pipe >= dev->num_crtcs)) in

[Bug 93101] GPU Fault almost burned the CPU

ext part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/bf37c149/attachment.html>

[Bug 93101] GPU Fault almost burned the CPU

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/0782ced4/attachment.html>

[Bug 93101] GPU Fault almost burned the CPU

|Linux (All) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/14d03025/attachment-0001.html>

[Bug 93079] Tonga faults and oopses on agd5f drm-fixes-4.4 since fix incorrect mutex usage v3

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/e62af362/attachment.html>

[Bug 93079] Tonga faults and oopses on agd5f drm-fixes-4.4 since fix incorrect mutex usage v3

different - no Oops, similar trace, rcu_preempt detected stalls on CPUs/tasks. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2015

[Bug 93101] GPU Fault almost burned the CPU

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/1709b1a4/attachment.html>

[Bug 93101] GPU Fault almost burned the CPU

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/55e30298/attachment.html>

[Bug 93101] GPU Fault almost burned the CPU

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/c6b5dda9/attachment.html>

[Bug 92982] slow switching to KD_GRAPHICS (KMS?)

hments/20151125/ede899df/attachment-0001.html>

[Bug 91279] agd5f drm tonga occasional traps error:0 in libdrm_amdgpu.so.1.0.0

: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/36cb1f3c/attachment.html>

[PATCH i915 v7 1/2] i915: wait for fence in mmio_flip_work_func

Hi Alex, Drive-by review because I was just reviewing something similar for a different device... On Wed, Nov 25, 2015 at 6:15 AM, Alex Goins wrote: > If a buffer is backed by dmabuf, wait on its reservation object's exclusive > fence before flipping. > > v2: First commit > v3: Remove

[PATCH 2/2] drm/i915: fix potential dangling else problems in for_each_ macros

On Tue, Nov 24, 2015 at 09:21:56PM +0200, Jani Nikula wrote: > We have serious dangling else bugs waiting to happen in our for_each_ > style macros with ifs. Consider, for example, > > #define for_each_power_domain(domain, mask) \ > for ((domain) = 0; (domain) <

[PATCH] drm: adv7511: really enable interrupts for EDID detection

.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/b59a88b1/attachment.sig>

[PATCH i915 v7 1/2] i915: wait for fence in mmio_flip_work_func

On Tue, Nov 24, 2015 at 06:26:00PM -0800, Alex Goins wrote: > Thanks, Daniel. There sure are a lot of Daniels. > > > > + else if (obj->base.dma_buf && obj->base.dma_buf->resv->fence_excl) > > > + return true; > > > > I'm not sure if this is really doing exactly what you want.

[PATCH 2/7] drm/vmwgfx: fix a problematic usage of WARN_ON()

Reviewed-by: Sinclair Yeh On Wed, Nov 25, 2015 at 09:12:15PM +0800, Geliang Tang wrote: > WARN_ON() takes a condition rather than a format string. This patch > converted WARN_ON() to WARN() instead. > > Signed-off-by: Geliang Tang > --- > drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +- > 1 file

[PATCH] drm: adv7511: really enable interrupts for EDID detection

-- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/93ec4c3e/attachment.sig>

drm_read() to paged-out memory area

Hi! On 11/24/2015 11:14 PM, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 09:49:58PM +0100, Thomas Hellstrom wrote: >> Hi, Chris, >> >> With your new (well sort of) implementation of drm_read() it looks to me >> like a drm_read() to a paged out >> memory area will always fail with -EFAULT. From

[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/16e73152/attachment.html>

[PATCH 0/3] drm/amdgpu: enable DKMS build

Thanks all for the comments. The simple changes in this series are just to use relative paths as Christian mentioned. It can also be helpful if some users want to try amdgpu driver from latest upstream on some systems with relatively older kernel installed, in which case the Dynamic Kernel

[Bug 108221] amdgpu: mouse cursor flickers + black boxes

https://bugzilla.kernel.org/show_bug.cgi?id=108221 --- Comment #3 from Michel Dänzer --- FWIW, xf86-video-ati is irrelevant for Tonga. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 74718] r600g: graphics artifacts with geometry shaders with RV730

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/691bb80f/attachment.html>

[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/bf69f384/attachment.html>

[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730

AGP at least. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/c776a3ad/attachment.html>

[Bug 91279] agd5f drm tonga occasional traps error:0 in libdrm_amdgpu.so.1.0.0

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151125/c7e88c9b/attachment-0001.html>