Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save
Op 04-09-17 om 21:02 schreef Christian König: > From: Christian König > > Stop requiring that the src reservation object is locked for this operation. > > Signed-off-by: Christian König > --- > drivers/dma-buf/reservation.c | 56 > --- > 1 file changed, 42 insertions(+), 14 deletions(-) > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c > index dec3a81..b44d9d7 100644 > --- a/drivers/dma-buf/reservation.c > +++ b/drivers/dma-buf/reservation.c > @@ -266,8 +266,7 @@ EXPORT_SYMBOL(reservation_object_add_excl_fence); > * @dst: the destination reservation object > * @src: the source reservation object > * > -* Copy all fences from src to dst. Both src->lock as well as dst-lock must be > -* held. > +* Copy all fences from src to dst. dst-lock must be held. > */ > int reservation_object_copy_fences(struct reservation_object *dst, > struct reservation_object *src) Could this be implemented using reservation_object_get_fences_rcu? You're essentially duplicating its functionality. Cheers, Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 Thomas DEBESSE changed: What|Removed |Added Attachment #134125|0 |1 is obsolete|| --- Comment #169 from Thomas DEBESSE --- Created attachment 134127 --> https://bugs.freedesktop.org/attachment.cgi?id=134127&action=edit kernel patch: set "high" default DPM level instead of "auto" for 0x67B0/0x67B1 variants Sorry, there was a stupid typo in the patch, this is now fixed. I'm running on that code and it works. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101594] Blender doesn't detect OpenCL with Clover
https://bugs.freedesktop.org/show_bug.cgi?id=101594 --- Comment #4 from Luke A. Guest --- Here's the output of Cycles trying to render the BMW testbench: $ CYCLES_OPENCL_SPLIT_KERNEL_TEST=1 ~/opt/blender-2.78c-linux-glibc219-x86_64/blender --debug-cycles Read new prefs: /home/laguest/.config/blender/2.78/config/userpref.blend found bundled python: /home/laguest/opt/blender-2.78c-linux-glibc219-x86_64/2.78/python I0910 10:20:49.989137 28885 blender_python.cpp:182] Debug flags initialized to: CPU flags: AVX2 : True AVX: True SSE4.1 : True SSE3 : True SSE2 : True CUDA flags: Adaptive Compile: False OpenCL flags: Device type : ALL Kernel type : SPLIT Debug : False read blend: /home/laguest/Downloads/BMW1M-MikePan.blend skipping driver '100*power', automatic scripts are disabled skipping driver '90*brake', automatic scripts are disabled skipping driver '-100*power', automatic scripts are disabled skipping driver '-90*brake', automatic scripts are disabled I0910 10:21:04.794803 28885 device_cuda.cpp:1363] CUEW initialization failed: Error opening the library I0910 10:21:04.851470 28885 device_opencl.cpp:58] CLEW initialization succeeded. I0910 10:21:04.851496 28885 opencl_util.cpp:741] Enumerating devices for platform Clover. I0910 10:21:04.851511 28885 opencl_util.cpp:802] Adding new device AMD Radeon (TM) R9 390 Series (HAWAII / DRM 3.18.0 / 4.13.0-lg+, LLVM 6.0.0). I0910 10:21:04.851524 28885 opencl_util.cpp:568] Forcing split kernel to use. skipping driver '-90*brake', automatic scripts are disabled skipping driver '90*brake', automatic scripts are disabled skipping driver '100*power', automatic scripts are disabled skipping driver '-100*power', automatic scripts are disabled write exr tmp file, 1920x1080, /tmp/blender_1J9xso/BMW1M-MikePan.blend_Scene_RenderLayer.exr I0910 10:21:23.147378 28922 util_system.cpp:77] Detected 1 CPU groups. I0910 10:21:23.147434 28922 util_system.cpp:80] Group 0 has 8 threads. I0910 10:21:23.147442 28922 util_task.cpp:203] Creating pool of 8 threads. I0910 10:21:23.147922 28922 device_cpu.cpp:83] Will be using AVX kernels. I0910 10:21:23.539211 28931 session.cpp:658] Requested features: Experimental features: Off Max closure count: 5 Max nodes group: 0 Nodes features: 4 Use hair: False Use object motion: False Use camera motion: False Use Baking: False Use Subsurface: False Use Volume: False Use Branched Integrator: False Use Patch Evaluation: False Use Transparent Shadows: True I0910 10:21:23.539269 28931 svm.cpp:98] Total 28 shaders. I0910 10:21:23.539377 28931 svm.cpp:66] Compilation summary: Shader name: BMWSilver Number of SVM nodes: 8 Peak stack usage:4 Time (in seconds): Finalize: 0.12 Bump finalize: 0.00 Finalize:0.12 Surface: 0.06 Bump: 0.00 Volume:0.01 Displacement: 0.00 Generate:0.07 Total: 0.20 I0910 10:21:23.539415 28931 svm.cpp:66] Compilation summary: Shader name: BMWWhite Number of SVM nodes: 8 Peak stack usage:4 Time (in seconds): Finalize: 0.05 Bump finalize: 0.00 Finalize:0.05 Surface: 0.02 Bump: 0.00 Volume:0.01 Displacement: 0.00 Generate:0.03 Total: 0.08 I0910 10:21:23.540022 28923 svm.cpp:66] Compilation summary: Shader name: default_empty Number of SVM nodes: 3 Peak stack usage:0 Time (in seconds): Finalize: 0.33 Bump finalize: 0.00 Finalize:0.33 Surface: 0.01 Bump: 0.00 Volume:0.02 Displacement: 0.01 Generate:0.04 Total: 0.38 I0910 10:21:23.540033 28930 svm.cpp:66] Compilation summary: Shader name: BMWBlue Number of SVM nodes: 8 Peak stack usage:4 Time (in seconds): Finalize: 0.41 Bump finalize: 0.00 Finalize:0.41 Surface: 0.19 Bump: 0.00 Volume:0.01 Displacement: 0.01 Generate:0.21 Total: 0.63 I0910 10:21:23.540089 28930 svm.cpp:66] Compilation summary: Shader name: Chrome Number of SVM nodes: 8 Peak stack usage:4 Time (in seconds): Finalize: 0.05 Bump finalize: 0.00 Finalize:0.05 Surface: 0.03 Bump: 0.00 Volume:0.01 Displacement: 0.00 Generate:0.04 Total: 0.10 I0910 10:21:23.540134 28930 svm.cpp:66] Compilation summary: Shader name: ChromeMatte Number of SVM nodes: 12 Peak stack usage:4 Time (in seconds): Finalize: 0.09 Bump finalize: 0.00 Finalize:0.09 Surface: 0.07 Bump: 0.00 Volume:0.01 Displacement: 0.01
[Bug 102625] Game Crashlands crashes on startup
https://bugs.freedesktop.org/show_bug.cgi?id=102625 --- Comment #5 from Philipp Überbacher --- With xf86-video-amdgpu 1.4.0 and mesa 17.2.0 the game starts for me. Seems this bug has already been fixed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102625] Game Crashlands crashes on startup
https://bugs.freedesktop.org/show_bug.cgi?id=102625 --- Comment #6 from Philipp Überbacher --- In this particular situation it would be good to know what fixed the issue and whether there is a workaround available. Any ideas? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102625] Game Crashlands crashes on startup
https://bugs.freedesktop.org/show_bug.cgi?id=102625 --- Comment #7 from ratatosk.yggdra...@googlemail.com --- As far as I know there was an update of the game engine included. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #170 from Jon Doane --- (In reply to Stefan from comment #160) > Jon Doane, to alleviate your pains, set radeon.dpm=0 as a boot option. Crippling GPU performance is not a solution and doesn't alleviate pains because it basically forces me to not do anything 3d-related. I would rather boot with X disabled so I can force the perf level to high. This is what I used to do and it's not an acceptable solution. (In reply to Thomas DEBESSE from comment #164) > (In reply to Jon Doane from comment #159) > > I've literally been doing: > > "echo high > /sys/class/device/drm/card0/power_dpm_force_performance_level" > > every day to boot my machine for over a year > > See comment 55 if your system is running systemd, you can use this service: > > https://github.com/illwieckz/dpm-query/ > > It will do it for you at startup, it's painless and I'm using it since 19 > months without any issue. This sounds a lot like what I've been doing manually which sounds nice. Thanks for the input. I honestly would like a solution that doesn't cause my machine to draw an additional 90 watts at idle though. As I said, I've been doing this for well over a year now and I'd prefer a solution, not a hack, considering how old this issue is. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102552] Null dereference due to not checking return value of util_format_description
https://bugs.freedesktop.org/show_bug.cgi?id=102552
Pauk Denis changed:
What|Removed |Added
Attachment #134056|0 |1
is obsolete||
--- Comment #6 from Pauk Denis ---
Created attachment 134129
--> https://bugs.freedesktop.org/attachment.cgi?id=134129&action=edit
gallium/{r600,radeonsi}: Fix segfault with color format
Fix radeonsi
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102552] Null dereference due to not checking return value of util_format_description
https://bugs.freedesktop.org/show_bug.cgi?id=102552 --- Comment #7 from Pauk Denis --- In 'si_is_sampler_format_supported': 'util_format_get_first_non_void_channel' - tried to check 'struct util_format_description' before 'si_translate_texformat' call so we have segfault before check. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196777] Virtual guest using video device QXL does not reach GDM
https://bugzilla.kernel.org/show_bug.cgi?id=196777 Krzysztof Nowicki (kri...@op.pl) changed: What|Removed |Added CC||kri...@op.pl --- Comment #1 from Krzysztof Nowicki (kri...@op.pl) --- I have bisected this to a series of commits introducing atomic modesetting to the QXL driver (more specifically commit 3538e80a869be74764ae7db484b371894f04d0f8). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #171 from Thomas DEBESSE --- > This sounds a lot like what I've been doing manually which sounds nice. > Thanks for the input. I honestly would like a solution that doesn't cause my > machine to draw an additional 90 watts at idle though. Unlike the kernel patch above, that systemd service is setting the GPU to "low battery" by default, which is the most energy saving profile. The provided `dpm query` tool allows you to change that at any time. That's what I'm doing: at init, my GPU is set to "low battery" profile, and when I need to do some heavy time, I do that: dpm-query set all high performance And then once the heavy task is done, I do that to save energy again: dpm-query set all low battery With the default config for the service, you just have to add your own user to the "video" group to have the right to change the profile as user. So, even if the patch above get merged one day, this service and tool is still useful, it's an easy way to change the default profile, whatever the default is. Notice that the kernel patch above only set the level to "high", but keep the state to "balanced", so it's still adaptative. What "high balanced" does is setting the shader and memory frequencies to the max, which is drawing more power than default, but you will notice the fan are still idling and stopped if you do nothing because it's still saving a lot of energy. If you set "high performance" the fan will almost instantaneously start because there is no saving anymore. So "high balanced" is less energy saving that "auto balanced", but is still saving a lot of energy because it does not have to cold the chip while doing nothing (meaning the chip does nothing strong enough to get hot). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101594] Blender doesn't detect OpenCL with Clover
https://bugs.freedesktop.org/show_bug.cgi?id=101594 --- Comment #5 from Jan Vesely --- anything specific you wanted to highlight? It does detect your GPU: > I0910 10:21:04.851496 28885 opencl_util.cpp:741] Enumerating devices for > platform Clover. > I0910 10:21:04.851511 28885 opencl_util.cpp:802] Adding new device AMD Radeon > (TM) R9 390 Series (HAWAII / DRM 3.18.0 / 4.13.0-lg+, LLVM 6.0.0). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)
https://bugs.freedesktop.org/show_bug.cgi?id=102646 Bug ID: 102646 Summary: Screen flickering under amdgpu-experimental (buffer corruptions?) Product: Mesa Version: 17.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: katof...@protonmail.com QA Contact: dri-devel@lists.freedesktop.org GPU/Stack: R9 390x/amdgpu-experimental/xf86-video-amdgpu/radeonsi CPU: R7 1700x Distro/Kernel: Manjaro/4.12.11 Display: ASUS VG248QE 144hz. Desktop Environment: KDE Under games and on the desktop(occasionally) there is screen flickering. Example: https://vid.me/n0t1r (sorry for audio/video, OBS is unable to capture the flickering) This happens at every screen frequency that I am capable of achieving (60-144hz), on HDMI and Display Port. I have tried all sorts of Vsync options, and the Compton compositor. However, none of those worked. Let me know what other information you want. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)
https://bugs.freedesktop.org/show_bug.cgi?id=102646 Justin Mitzel changed: What|Removed |Added Severity|normal |major -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101594] Blender doesn't detect OpenCL with Clover
https://bugs.freedesktop.org/show_bug.cgi?id=101594 --- Comment #6 from Luke A. Guest --- While it does render, it's not a perfect render, there are "dithered" areas which should not be there and which should be smooth colour. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/tve200: Clean up panel bridging
This makes use of the drm_simple_display_pipe_attach_bridge()
call and removes the two calls removing the bridge, which were
erroneous: they unregister the bridge which is not what
we want, we just want to unreference it and that is already
handled by the core.
Reviewed-by: Eric Anholt
Acked-by: Daniel Vetter
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Dropped the encoder field from private data.
---
drivers/gpu/drm/tve200/tve200_display.c | 3 ---
drivers/gpu/drm/tve200/tve200_drm.h | 1 -
drivers/gpu/drm/tve200/tve200_drv.c | 30 +-
3 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/tve200/tve200_display.c
b/drivers/gpu/drm/tve200/tve200_display.c
index cfdffc15a2ce..fd193377c3c0 100644
--- a/drivers/gpu/drm/tve200/tve200_display.c
+++ b/drivers/gpu/drm/tve200/tve200_display.c
@@ -332,8 +332,5 @@ int tve200_display_init(struct drm_device *drm)
if (ret)
return ret;
- /* We need the encoder to attach the bridge */
- priv->encoder = &priv->pipe.encoder;
-
return 0;
}
diff --git a/drivers/gpu/drm/tve200/tve200_drm.h
b/drivers/gpu/drm/tve200/tve200_drm.h
index b463624c1f29..628b79324c48 100644
--- a/drivers/gpu/drm/tve200/tve200_drm.h
+++ b/drivers/gpu/drm/tve200/tve200_drm.h
@@ -100,7 +100,6 @@ struct tve200_drm_dev_private {
struct drm_device *drm;
struct drm_connector *connector;
- struct drm_encoder *encoder;
struct drm_panel *panel;
struct drm_bridge *bridge;
struct drm_simple_display_pipe pipe;
diff --git a/drivers/gpu/drm/tve200/tve200_drv.c
b/drivers/gpu/drm/tve200/tve200_drv.c
index c22644692a88..eae38b669f0a 100644
--- a/drivers/gpu/drm/tve200/tve200_drv.c
+++ b/drivers/gpu/drm/tve200/tve200_drv.c
@@ -87,6 +87,14 @@ static int tve200_modeset_init(struct drm_device *dev)
ret = PTR_ERR(bridge);
goto out_bridge;
}
+ } else {
+ /*
+* TODO: when we are using a different bridge than a panel
+* (such as a dumb VGA connector) we need to devise a different
+* method to get the connector out of the bridge.
+*/
+ dev_err(dev->dev, "the bridge is not a panel\n");
+ goto out_bridge;
}
ret = tve200_display_init(dev);
@@ -95,21 +103,13 @@ static int tve200_modeset_init(struct drm_device *dev)
goto out_bridge;
}
- if (bridge) {
- ret = drm_bridge_attach(priv->encoder, bridge, NULL);
- if (ret)
- goto out_bridge;
- }
-
- /*
-* TODO: when we are using a different bridge than a panel
-* (such as a dumb VGA connector) we need to devise a different
-* method to get the connector out of the bridge.
-*/
- if (!panel) {
- dev_err(dev->dev, "the bridge is not a panel\n");
+ ret = drm_simple_display_pipe_attach_bridge(&priv->pipe,
+ bridge);
+ if (ret) {
+ dev_err(dev->dev, "failed to attach bridge\n");
goto out_bridge;
}
+
priv->panel = panel;
priv->connector = panel->connector;
priv->bridge = bridge;
@@ -138,8 +138,6 @@ static int tve200_modeset_init(struct drm_device *dev)
out_bridge:
if (panel)
drm_panel_bridge_remove(bridge);
- else
- drm_bridge_remove(bridge);
drm_mode_config_cleanup(dev);
finish:
return ret;
@@ -275,8 +273,6 @@ static int tve200_remove(struct platform_device *pdev)
drm_fbdev_cma_fini(priv->fbdev);
if (priv->panel)
drm_panel_bridge_remove(priv->bridge);
- else
- drm_bridge_remove(priv->bridge);
drm_mode_config_cleanup(drm);
clk_disable_unprepare(priv->pclk);
drm_dev_unref(drm);
--
2.13.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101594] Blender doesn't detect OpenCL with Clover
https://bugs.freedesktop.org/show_bug.cgi?id=101594 --- Comment #7 from Jan Vesely --- (In reply to Luke A. Guest from comment #6) > While it does render, it's not a perfect render, there are "dithered" areas > which should not be there and which should be smooth colour. it's surprising that it completed given bug #102009 on a very similar hw. either way it is a different bug. please open a new bug report if it hasn't been reported yet. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #1 from Justin Mitzel --- Update: This does not appear to happen under KDE wayland -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #2 from Justin Mitzel --- It also does not happen on XFCE nor lxqt. I tried openbox/KDE and the problem happened there. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #3 from Michel Dänzer --- Please attach the corresponding dmesg output and Xorg log file. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Fix an error handling in 'intel_framebuffer_init()'
We should go through the error handling path to decrease the
'framebuffer_references' as done everywhere else in this function.
Fixes: 2e2adb05736c ("drm/i915: Add render decompression support")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7cd392f2cd94..478fa449003f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14077,7 +14077,7 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
if (mode_cmd->handles[i] != mode_cmd->handles[0]) {
DRM_DEBUG_KMS("bad plane %d handle\n", i);
- return -EINVAL;
+ goto err;
}
stride_alignment = intel_fb_stride_alignment(fb, i);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102414] Hawaii gpu (R9 290) and the troubles with the amd-staging-drm-next branch
https://bugs.freedesktop.org/show_bug.cgi?id=102414 --- Comment #6 from Vadim Girlin --- Created attachment 134152 --> https://bugs.freedesktop.org/attachment.cgi?id=134152&action=edit dmesg after failed resume The latest amd-staging-drm-next branch fails to resume from suspend properly for me. It worked previously (when it was possible to perform a suspend). After resume the screen is mostly blue now with some dynamic random noise - horizontal black lines etc. Though I hear the sound via the display port audio from the video that was playing at the moment of suspend, so at least that part seems to work. There are some amdgpu backtraces in the attached dmesg before and after the suspend/resume, but I didn't notice any real issues before suspend so far, the only problem is that the display is unusable after resume. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
