dri-devel July 2018

dri-devel@lists.freedesktop.org

277 participants
1883 discussions

linux-next: manual merge of the mfd tree with the drm-intel tree
by Stephen Rothwell 21 Aug '18

21 Aug '18

Hi Lee, Today's linux-next merge of the mfd tree got a conflict in: drivers/gpu/drm/i915/intel_display.h between commit: 6075546f57f8 ("drm/i915/icl: store the port type for TC ports") from the drm-intel tree and commit: 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi") from the mfd tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/gpu/drm/i915/intel_display.h index 0a79a46d5805,1f176a71e081..000000000000 --- a/drivers/gpu/drm/i915/intel_display.h +++ b/drivers/gpu/drm/i915/intel_display.h @@@ -126,24 -126,30 +126,48 @@@ enum port #define port_name(p) ((p) + 'A') + /* + * Ports identifier referenced from other drivers. + * Expected to remain stable over time + */ + static inline const char *port_identifier(enum port port) + { + switch (port) { + case PORT_A: + return "Port A"; + case PORT_B: + return "Port B"; + case PORT_C: + return "Port C"; + case PORT_D: + return "Port D"; + case PORT_E: + return "Port E"; + case PORT_F: + return "Port F"; + default: + return "<invalid>"; + } + } + +enum tc_port { + PORT_TC_NONE = -1, + + PORT_TC1 = 0, + PORT_TC2, + PORT_TC3, + PORT_TC4, + + I915_MAX_TC_PORTS +}; + +enum tc_port_type { + TC_PORT_UNKNOWN = 0, + TC_PORT_TYPEC, + TC_PORT_TBT, + TC_PORT_LEGACY, +}; + enum dpio_channel { DPIO_CH0, DPIO_CH1

2 3

[Bug 100697] [radeonsi,WebGL] blinking random patches instead of blinking squares
by bugzilla-daemon＠freedesktop.org 20 Aug '18

20 Aug '18

https://bugs.freedesktop.org/show_bug.cgi?id=100697 Bug ID: 100697 Summary: [radeonsi,WebGL] blinking random patches instead of blinking squares Product: Mesa Version: git Hardware: Other URL: https://robertsspaceindustries.com/starmap OS: All Status: NEW Severity: minor Priority: low Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: kai(a)dev.carbon-project.org QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 130867 --> https://bugs.freedesktop.org/attachment.cgi?id=130867&action=edit Random blinking spots instead of squares When viewing <https://robertsspaceindustries.com/starmap> you can see random blinking patches (see attached screenshot) instead of full screen of blinking squares in the background during the loading screens. The first few seconds of <https://www.youtube.com/watch?v=Xn3MeDnryt8> show how the background should look. Please note, that the actual star map works fine AFAICT (thus the reduced severity and priority). This is with the OpenGL stack detailed below and Firefox 52.0.2. Also this doesn't seem to be a duplicate of bug 100036 as that star map seems to render correctly for me with the same setup. The full stack (Debian testing as a base) is: GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/566f2ed571 libdrm: Git:master/c9c77c3717 (tag libdrm-2.4.79) LLVM: SVN:trunk/r299977 (5.0 devel) X.Org: 2:1.19.2-1 Linux: 4.10.9 Firmware (firmware-amd-graphics): 20161130-2 libclc: 0.2.0+git20170330-1 (rebuilt for LLVM 5.0) DDX (xserver-xorg-video-amdgpu): 1.2.0-1+b1 Let me know if you need anything else. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 199425] New: BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
by bugzilla-daemon＠bugzilla.kernel.org 20 Aug '18

20 Aug '18

https://bugzilla.kernel.org/show_bug.cgi?id=199425 Bug ID: 199425 Summary: BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260 Product: Drivers Version: 2.5 Kernel Version: 4.17-rc1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: johannes.hirte(a)datenkhaos.de Regression: No With dc enabled, I get the following use-after-free on my Carrizo: [53213.875800] ================================================================== [53213.875826] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260 [53213.875835] Read of size 8 at addr ffff8801063aaa88 by task kworker/u8:3/9911 [53213.875848] CPU: 3 PID: 9911 Comm: kworker/u8:3 Not tainted 4.17.0-rc1-00001-g9e7729e9a66c #566 [53213.875855] Hardware name: HP HP ProBook 645 G2/80FE, BIOS N77 Ver. 01.12 12/19/2017 [53213.875864] Workqueue: events_unbound commit_work [53213.875870] Call Trace: [53213.875881] dump_stack+0x5b/0x8b [53213.875890] ? drm_atomic_helper_wait_for_flip_done+0x247/0x260 [53213.875899] print_address_description+0x65/0x270 [53213.875907] ? drm_atomic_helper_wait_for_flip_done+0x247/0x260 [53213.875913] kasan_report+0x232/0x350 [53213.875920] drm_atomic_helper_wait_for_flip_done+0x247/0x260 [53213.875930] amdgpu_dm_atomic_commit_tail+0x1b19/0x4010 [53213.875940] ? _raw_spin_unlock_irq+0x35/0x50 [53213.875946] ? wait_for_completion_timeout+0x215/0x2b0 [53213.875953] ? btrfs_rmap_block+0x9c0/0x9c0 [53213.875959] ? dm_update_crtcs_state+0xcb0/0xcb0 [53213.875966] ? _raw_spin_unlock_irqrestore+0x3a/0x70 [53213.875973] ? try_to_wake_up+0xa1/0xf90 [53213.875980] ? drm_atomic_helper_wait_for_dependencies+0x3de/0x7d0 [53213.875986] ? normal_work_helper+0x273/0xa70 [53213.875993] commit_tail+0x95/0xf0 [53213.876000] process_one_work+0x7c8/0x1330 [53213.876006] ? _raw_spin_lock_irq+0x1c/0x40 [53213.876013] worker_thread+0xc9/0xef0 [53213.876021] ? process_one_work+0x1330/0x1330 [53213.876026] kthread+0x2d6/0x390 [53213.876032] ? kthread_create_worker+0xd0/0xd0 [53213.876038] ret_from_fork+0x22/0x40 [53213.876049] Allocated by task 508: [53213.876056] kasan_kmalloc+0xa0/0xd0 [53213.876063] kmem_cache_alloc_trace+0xf3/0x1f0 [53213.876068] dm_crtc_duplicate_state+0x73/0x130 [53213.876075] drm_atomic_get_crtc_state+0x142/0x400 [53213.876080] page_flip_common+0x52/0x220 [53213.876086] drm_atomic_helper_page_flip+0xa1/0x100 [53213.876093] drm_mode_page_flip_ioctl+0xbe3/0xff0 [53213.876100] drm_ioctl_kernel+0x13d/0x1d0 [53213.876106] drm_ioctl+0x63d/0x920 [53213.876112] amdgpu_drm_ioctl+0xc7/0x1a0 [53213.876120] do_vfs_ioctl+0x173/0xde0 [53213.876125] ksys_ioctl+0x6b/0x80 [53213.876130] __x64_sys_ioctl+0x6a/0xb0 [53213.876137] do_syscall_64+0x95/0x2f0 [53213.876142] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [53213.876149] Freed by task 637: [53213.876154] __kasan_slab_free+0x130/0x180 [53213.876159] kfree+0x8b/0x1c0 [53213.876164] drm_atomic_state_default_clear+0x2c5/0xa00 [53213.876169] __drm_atomic_state_free+0x30/0xc0 [53213.876174] drm_atomic_helper_update_plane+0xb6/0x350 [53213.876179] __setplane_internal+0x48c/0x7f0 [53213.876184] drm_mode_cursor_universal+0x2e7/0x970 [53213.876189] drm_mode_cursor_common+0x493/0x860 [53213.876194] drm_mode_cursor_ioctl+0x7a/0xa0 [53213.876199] drm_ioctl_kernel+0x13d/0x1d0 [53213.876203] drm_ioctl+0x63d/0x920 [53213.876207] amdgpu_drm_ioctl+0xc7/0x1a0 [53213.876212] do_vfs_ioctl+0x173/0xde0 [53213.876216] ksys_ioctl+0x6b/0x80 [53213.876221] __x64_sys_ioctl+0x6a/0xb0 [53213.876225] do_syscall_64+0x95/0x2f0 [53213.876230] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [53213.876239] The buggy address belongs to the object at ffff8801063aa880 which belongs to the cache kmalloc-1024 of size 1024 [53213.876247] The buggy address is located 520 bytes inside of 1024-byte region [ffff8801063aa880, ffff8801063aac80) [53213.876252] The buggy address belongs to the page: [53213.876258] page:ffffea000418ea00 count:1 mapcount:0 mapping:0000000000000000 index:0x0 compound_mapcount: 0 [53213.876268] flags: 0x2000000000008100(slab|head) [53213.876278] raw: 2000000000008100 0000000000000000 0000000000000000 00000001801c001c [53213.876284] raw: dead000000000100 dead000000000200 ffff8803f3402c40 0000000000000000 [53213.876288] page dumped because: kasan: bad access detected [53213.876294] Memory state around the buggy address: [53213.876300] ffff8801063aa980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [53213.876305] ffff8801063aaa00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [53213.876310] >ffff8801063aaa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [53213.876313] ^ [53213.876319] ffff8801063aab00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [53213.876324] ffff8801063aab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [53213.876327] ================================================================== [53213.876331] Disabling lock debugging due to kernel taint I've obverved this already with kernel 4.14, 4.15 and 4.16. -- You are receiving this mail because: You are watching the assignee of the bug.

1 18

[Bug 199653] New: [AMDGPU][DC] BUG: unable to handle kernel NULL pointer dereference (trace decoded)
by bugzilla-daemon＠bugzilla.kernel.org 17 Aug '18

17 Aug '18

https://bugzilla.kernel.org/show_bug.cgi?id=199653 Bug ID: 199653 Summary: [AMDGPU][DC] BUG: unable to handle kernel NULL pointer dereference (trace decoded) Product: Drivers Version: 2.5 Kernel Version: drm-next-4.18-wip (agd5f, AMDGPU) Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: marcus.husar(a)gmail.com Regression: No Created attachment 275827 --> https://bugzilla.kernel.org/attachment.cgi?id=275827&action=edit Call trace of crash decoded with decode_stacktrace.sh kernel: BUG: unable to handle kernel NULL pointer dereference at 00000000000002e4 This happens multiple times a day on my machine. It leads to a complete system freeze. Yesterday I was lucky and got a stack trace. It mostly happens browsing the web with Firefox (WebRender enabled, XWayland, Gnome-Shell) when the cursor moves or rotates. But it can happen anywhere and anytime. The used kernel is from branch drm-next-4.18-wip@92fb374 of Alex Deucher, AMD (agd5f). See: git://people.freedesktop.org/~agd5f/linux. My machine: * Hardware name: Acer Swift SF315-41/Becks_RR, BIOS V1.04 01/09/2018 * Ryzen Mobile 2500U * Firmware: VCN: 1.73 (latest available version) * My kernel is tainted because the i2c designware driver emits a warning during boot. This should be unrelated to AMDGPU (see attachment i2c_designware_trace.txt). Please ask if anything else is needed. -- You are receiving this mail because: You are watching the assignee of the bug.

1 11

[Bug 104817] [Raven][GALLIUM_DDEBUG] system crashes/freezes randomly every few minutes/hours
by bugzilla-daemon＠freedesktop.org 17 Aug '18

17 Aug '18

https://bugs.freedesktop.org/show_bug.cgi?id=104817 Bug ID: 104817 Summary: [Raven][GALLIUM_DDEBUG] system crashes/freezes randomly every few minutes/hours Product: Mesa Version: git Hardware: All OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: marcus.husar(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 137000 --> https://bugs.freedesktop.org/attachment.cgi?id=137000&action=edit GALLIUM_DDEBUG: folder ddebug_dumps with multiple dumps OpenGL renderer string: AMD RAVEN (DRM 3.23.0 / 4.16.0-2.fc27.x86_64, LLVM 6.0.0) My system is an Acer SF315-41 (Ryzen Mobile 5 2500U) with Fedora 27, Kernel 4.16-drm-next (based on 4.15-rc8), LLVM 6.0.0-rc1, Mesa 18.0.0-rc2. I can reproduce these crashes from kernel-4.15-rcX/mesa-17.3/llvm5 to kernel-4.16-drm-next/mesa-18-rc2/llvm6-rc1 and in between. They mostly appear while watching videos (firefox/totem), switching tabs in firefox, resizing windows (gnome-shell) or gaming. With amdgpu.lockup_timeout=2000 and amdgpu.GALLIUM_DDEBUG=2000 I was able to gather lots of dumps within a few minutes (see attachment). As you can see in the dumps the GPU lockup results sometimes in a CPU lockup (kernel bluetooth deadlock) as a result of gnome shell’s complete freezing. I can reproduce amdgpu crashes also with an USB mouse and bluetooth disabled. Not very often I can find some kernel errors in the logfiles that result from a crash. I’ll attach the few I found in the last two weeks. -- You are receiving this mail because: You are the assignee for the bug.

1 10

Re: RFC for a render API to support adaptive sync and VRR
by Harry Wentland 17 Aug '18

17 Aug '18

Adding dri-devel, which I should've included from the start. On 2018-04-09 03:56 PM, Harry Wentland wrote: > === What is adaptive sync and VRR? === > > Adaptive sync has been part of the DisplayPort spec for a while now and allows graphics adapters to drive displays with varying frame timings. VRR (variable refresh rate) is essentially the same, but defined for HDMI. > > > > === Why allow variable frame timings? === > > Variable render times don't align with fixed refresh rates, leading to > stuttering, tearing, and/or input lag. > > e.g. (rc = render completion, dr = display refresh) > > rc B C D E F > dr A B C C D E F > > ^ ^ > frame missed > repeated display > twice refresh > > > > === Other use cases of adaptive sync ==== > > Beside the variable render case, adaptive sync also allows adjustment of refresh rates without a mode change. One such use case would be 24 Hz video. > > > > === A DRM render API to support variable refresh rates === > > In order to benefit from adaptive sync and VRR userland needs a way to let us know whether to vary frame timings or to target a different frame time. These can be provided as atomic properties on a CRTC: > * bool variable_refresh_compatible > * int target_frame_duration_ns (nanosecond frame duration) > > This gives us the following cases: > > variable_refresh_compatible = 0, target_frame_duration_ns = 0 > * drive monitor at timing's normal refresh rate > > variable_refresh_compatible = 1, target_frame_duration_ns = 0 > * send new frame to monitor as soon as it's available, if within min/max of monitor's reported capabilities > > variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0 > * send new frame to monitor with the specified target_frame_duration_ns > > When a target_frame_duration_ns or variable_refresh_compatible cannot be supported the atomic check will reject the commit. > > > > === Previous discussions === > > https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html > > > > === Feedback and moving forward === > > I'm hoping to get some feedback on this or continue the discussion on how adaptive sync / VRR might look like in the DRM ecosystem. Once there are no major concerns or objections left we'll probably start creating some patches to sketch this out a bit better and see how it looks in practice. > > > > Cheers, > Harry > _______________________________________________ > amd-gfx mailing list > amd-gfx(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx >

13 45

[PATCH 0/5] RESEND: dma-buf cleanup
by Daniel Vetter 17 Aug '18

17 Aug '18

Hi all, This is a resend of my dma-buf cleanup with the patches that didn't yet get and ack/r-b. Feedback very much welcome. Thanks, Daniel Daniel Vetter (5): drm/i915: Remove unecessary dma_fence_ops drm/msm: Remove unecessary dma_fence_ops drm/nouveau: Remove unecessary dma_fence_ops drm/vgem: Remove unecessary dma_fence_ops dma-fence: Polish kernel-doc for dma-fence.c Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/dma-fence.c | 147 ++++++++++++------ drivers/gpu/drm/i915/i915_gem_clflush.c | 7 - .../gpu/drm/i915/selftests/i915_sw_fence.c | 8 - drivers/gpu/drm/msm/msm_fence.c | 8 - drivers/gpu/drm/nouveau/nouveau_fence.c | 1 - drivers/gpu/drm/vgem/vgem_fence.c | 14 -- 7 files changed, 109 insertions(+), 82 deletions(-) -- 2.18.0

5 15

[PATCH 0/3] Add Mali DP pixel formats
by Alexandru Gheorghe 16 Aug '18

16 Aug '18

Mali DP supports a bunch of pixel formats that don't have a fourcc code defined in drm_fourcc.h, so this patchset adds the definition for those formats and enables them in mali-dp driver. The following new formats will be added: Packed YCbCr444 * DRM_FORMAT_XYUV8888 * DRM_FORMAT_XVYU2101010 Two plane 10 bits format. * DRM_FORMAT_P010 Packed YCbCr420 2x2 tiled formats * DRM_FORMAT_Y0L0 * DRM_FORMAT_X0L0 * DRM_FORMAT_Y0L2 * DRM_FORMAT_X0L2 The difference between X0L0/X0L2 vs Y0L0/Y0L2 is that the later group have two alpha bits per pixel. This group is a bit special because we are dealing with a tiled format where the first 64 bits in memory represent the pixels for a 2x2 tile, so it needs a bit of special handling when it comes to: - pitch: needs to cover both rows that are in the same tile. - min allocation size: since a pitch cover both rows the formulas defined in drm_gem_fb_create don't work anymore. - handling of src_x and src_y offset: same as above since we are dealing with a tiled format drm_fb_cma_get_gem_obj doesn't return the correct address offset. So, for this formats mali-dp needs a special implementation of drm_fb_cma_get_gem_obj and drm_fb_cma_get_gem_addr which are more or less clones of the core functions, except they take into account the tile_size. Other alternatives would be: 1) Add a tile_size to drm_format_info and plumb the drm_core functions to proper handle this special formats. 2) Add a driver hook that checks buffer min_size and avoid duplicating the code from drm_gem_fb_create_with_funcs. If you have an opinion about how this should be handled feel free to suggest it. Alexandru Gheorghe (3): drm/fourcc: Add malidp yuv formats drm: Make drm_gem_fb_alloc available for drivers to use drm: mali-dp: Enable mali specific buffer formats drivers/gpu/drm/arm/malidp_drv.c | 65 +++++++++++++++++++- drivers/gpu/drm/arm/malidp_hw.c | 7 ++- drivers/gpu/drm/arm/malidp_planes.c | 52 +++++++++++++--- drivers/gpu/drm/drm_fourcc.c | 7 +++ drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 +- include/drm/drm_gem_framebuffer_helper.h | 5 ++ include/uapi/drm/drm_fourcc.h | 27 +++++++- 7 files changed, 154 insertions(+), 12 deletions(-) -- 2.18.0

4 10

linux-next: build failure after merge of the xen-tip tree
by Stephen Rothwell 16 Aug '18

16 Aug '18

Hi all, After merging the xen-tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/xen/gntdev-dmabuf.c:360:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .attach = dmabuf_exp_ops_attach, ^~~~~~~~~~~~~~~~~~~~~ Caused by commit a240d6e42e28 ("xen/gntdev: Implement dma-buf export functionality") interacting with commit a19741e5e5a9 ("dma_buf: remove device parameter from attach callback v2") from the drm tree. I have added the following merge fix patch: From: Stephen Rothwell <sfr(a)canb.auug.org.au> Date: Mon, 30 Jul 2018 15:08:21 +1000 Subject: [PATCH] xen/gntdev: fix up for attach callback API change Signed-off-by: Stephen Rothwell <sfr(a)canb.auug.org.au> --- drivers/xen/gntdev-dmabuf.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c index faaa4d3970ea..744cfe9b0311 100644 --- a/drivers/xen/gntdev-dmabuf.c +++ b/drivers/xen/gntdev-dmabuf.c @@ -217,7 +217,6 @@ dmabuf_pages_to_sgt(struct page **pages, unsigned int nr_pages) } static int dmabuf_exp_ops_attach(struct dma_buf *dma_buf, - struct device *target_dev, struct dma_buf_attachment *attach) { struct gntdev_dmabuf_attachment *gntdev_dmabuf_attach; -- 2.18.0 -- Cheers, Stephen Rothwell

2 2

[PATCH 1/6] drm: Let userspace check if driver supports modeset
by José Roberto de Souza 15 Aug '18

15 Aug '18

GPU accelerators usually don't have display block or the display driver part can be disable when building driver(for servers it save some resources) so it is important let userspace check this capability too. Signed-off-by: José Roberto de Souza <jose.souza(a)intel.com> --- drivers/gpu/drm/drm_ioctl.c | 3 +++ include/uapi/drm/drm.h | 1 + 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index ea10e9a26aad..3a8438ae9b51 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -244,6 +244,9 @@ static int drm_getcap(struct drm_device *dev, void *data, struct drm_file *file_ case DRM_CAP_SYNCOBJ: req->value = drm_core_check_feature(dev, DRIVER_SYNCOBJ); return 0; + case DRM_CAP_MODESET: + req->value = drm_core_check_feature(dev, DRIVER_MODESET); + return 0; } /* Other caps only work with KMS drivers */ diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 300f336633f2..85fae6ddbf48 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -649,6 +649,7 @@ struct drm_gem_open { #define DRM_CAP_PAGE_FLIP_TARGET 0x11 #define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12 #define DRM_CAP_SYNCOBJ 0x13 +#define DRM_CAP_MODESET 0x14 /** DRM_IOCTL_GET_CAP ioctl argument type */ struct drm_get_cap { -- 2.18.0

4 11

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2018