Re: [Mesa-dev] [PATCH] radeonsi: Bump number of allowed global buffers to 48 (again, for clover Blender assertion)

[Dieter Nützel]

Thank you Marek and Pierre-Eric,

with

'radeonsi: allocate and resize global_buffers as needed'

Clover OpenCL works with Blender, now.

My patch is obsolete with it.

Great.

Dieter

Am 08.08.2019 18:36, schrieb Jan Vesely:

On Tue, 2019-08-06 at 23:20 -0400, Marek Olšák wrote:

Do you know why global buffers are in the compute state and not in the
context?


Not really. I mostly follow the existing design when it comes to mesa.
I'd assume it's a leftover from r600 which has limited number of cbufs
(and uses shared pool to accommodate global buffers).

cl global buffers are created in cl context so I think there shouldn't
be too much trouble moving it to the driver equivalent of that.

Jan



Marek

On Tue, Aug 6, 2019 at 10:50 PM Dieter Nützel  
wrote:


> Am 20.06.2019 20:44, schrieb Jan Vesely:
> > On Sat, 2019-06-15 at 07:38 +0200, Dieter Nützel wrote:
> > > Am 14.06.2019 08:13, schrieb Jan Vesely:
> > > > On Thu, 2019-06-13 at 21:20 +0200, Dieter Nützel wrote:
> > > > > Blender crash as expected ;-)
> > > > >
> > > > > /home/dieter> trying to save userpref at
> > > > > /home/dieter/.config/blender/2.79/config/userpref.blend ok
> > > > > Read blend: /data/Blender/barbershop_interior_gpu.blend
> > > > > scripts disabled for "/data/Blender/barbershop_interior_gpu.blend",
> > > > > skipping 'generate_customprops.py'
> > > > > skipping driver 'var', automatic scripts are disabled
> > > > > skipping driver 'var', automatic scripts are disabled
> > > > > skipping driver 'var', automatic scripts are disabled
> > > > > skipping driver 'var', automatic scripts are disabled
> > > > > skipping driver 'var', automatic scripts are disabled
> > > > > skipping driver 'var', automatic scripts are disabled
> > > > > skipping driver 'var', automatic scripts are disabled
> > > > > skipping driver 'var', automatic scripts are disabled
> > > > > skipping driver 'var', automatic scripts are disabled
> > > > > Device init success
> > > > > Compiling OpenCL program split
> > > > > Kernel compilation of split finished in 8.41s.
> > > > >
> > > > > Compiling OpenCL program base
> > > > > Kernel compilation of base finished in 4.55s.
> > > > >
> > > > > Compiling OpenCL program denoising
> > > > > Kernel compilation of denoising finished in 2.08s.
> > > > >
> > > > > blender: ../src/gallium/drivers/radeonsi/si_compute.c:319:
> > > > > si_set_global_binding: Assertion `first + n <= MAX_GLOBAL_BUFFERS'
> > > > > failed.
> > > > >
> > > > > [1]Abbruch   blender (core dumped)
> > > >
> > > > The number of max global buffers was bumped in 06bf56725d to fix
> > > > similar crash in luxmark. I guess it needs another bump.
> > >
> > > Hello Jan,
> > >
> > > I'm so blind...
> > > ...bumping it 48 and 64 (first try) works. 33 not ;-)
> > > We shouldn't waste to much memory.
> >
> > Feel free to post a patch. I'm not sure at which point Marek wants to
> > switch to dynamic allocation (or if at all), but there's no limit in
> > OCL so we might end up bumping this every time a new app pushes
> > against the limit.
>
> Hello Jan,
>
> comming 'happily' from vacation and think we should've this in 19.2.
>
> Marek,
>
> do we need dynamic allocation, yet?
>
> Sorry, please see attachment.
> Would be nice, if someone of you could add these lines during commit:
>
>  Fixes assertion failure/crash when running Blender (2.79b) on
> clover.
>  CC: mesa-sta...@lists.freedesktop.org<= ???
>
> Greetings,
> Dieter

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel: Load the driver even if I915_PARAM_REVISION is not found.

[Rafael Antognolli]

On Mon, Aug 19, 2019 at 11:25:38PM +0200, Lionel Landwerlin wrote:
> On 19/08/2019 21:28, Rafael Antognolli wrote:
> > This param is only available starting on kernel 4.16. Use a default
> > value of 0 if it is not found instead.
> 
> 
> I trace the param to :
> 
> 
> commit 27cd44618b92fc8c6889e4628407791e45422bac
> Author: Neil Roberts 
> Date:   Wed Mar 4 14:41:16 2015 +
> 
>     drm/i915: Add I915_PARAM_REVISION
> 
> 
> That seems to be back into 4.1. Could it be another issue?
> 

Yeah, I noticed it later, just ignore this patch.

Thanks for looking, though.

Rafael

> -Lionel
> 
> 
> > 
> > Cc: Jordan Justen 
> > Cc: Mark Janes 
> > ---
> >   src/intel/dev/gen_device_info.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/intel/dev/gen_device_info.c 
> > b/src/intel/dev/gen_device_info.c
> > index 3953a1f4af3..375d13630a5 100644
> > --- a/src/intel/dev/gen_device_info.c
> > +++ b/src/intel/dev/gen_device_info.c
> > @@ -1366,7 +1366,7 @@ gen_get_device_info_from_fd(int fd, struct 
> > gen_device_info *devinfo)
> > return false;
> >  if (!getparam(fd, I915_PARAM_REVISION, >revision))
> > -   return false;
> > +  devinfo->revision = 0;
> >  if (!query_topology(devinfo, fd)) {
> > if (devinfo->gen >= 10) {
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel: Load the driver even if I915_PARAM_REVISION is not found.

[Lionel Landwerlin]

On 19/08/2019 21:28, Rafael Antognolli wrote:

This param is only available starting on kernel 4.16. Use a default
value of 0 if it is not found instead.



I trace the param to :


commit 27cd44618b92fc8c6889e4628407791e45422bac
Author: Neil Roberts 
Date:   Wed Mar 4 14:41:16 2015 +

    drm/i915: Add I915_PARAM_REVISION


That seems to be back into 4.1. Could it be another issue?


-Lionel




Cc: Jordan Justen 
Cc: Mark Janes 
---
  src/intel/dev/gen_device_info.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 3953a1f4af3..375d13630a5 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -1366,7 +1366,7 @@ gen_get_device_info_from_fd(int fd, struct 
gen_device_info *devinfo)
return false;
  
 if (!getparam(fd, I915_PARAM_REVISION, >revision))

-   return false;
+  devinfo->revision = 0;
  
 if (!query_topology(devinfo, fd)) {

if (devinfo->gen >= 10) {



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel: Load the driver even if I915_PARAM_REVISION is not found.

[Rafael Antognolli]

This commit might also need a:

Fixes: 96e1c945f2b ("i965: Move device info initialization to common
code")

On Mon, Aug 19, 2019 at 12:28:55PM -0700, Rafael Antognolli wrote:
> This param is only available starting on kernel 4.16. Use a default
> value of 0 if it is not found instead.
> 
> Cc: Jordan Justen 
> Cc: Mark Janes 
> ---
>  src/intel/dev/gen_device_info.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
> index 3953a1f4af3..375d13630a5 100644
> --- a/src/intel/dev/gen_device_info.c
> +++ b/src/intel/dev/gen_device_info.c
> @@ -1366,7 +1366,7 @@ gen_get_device_info_from_fd(int fd, struct 
> gen_device_info *devinfo)
>return false;
>  
> if (!getparam(fd, I915_PARAM_REVISION, >revision))
> -   return false;
> +  devinfo->revision = 0;
>  
> if (!query_topology(devinfo, fd)) {
>if (devinfo->gen >= 10) {
> -- 
> 2.21.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel: Load the driver even if I915_PARAM_REVISION is not found.

[Rafael Antognolli]

This param is only available starting on kernel 4.16. Use a default
value of 0 if it is not found instead.

Cc: Jordan Justen 
Cc: Mark Janes 
---
 src/intel/dev/gen_device_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 3953a1f4af3..375d13630a5 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -1366,7 +1366,7 @@ gen_get_device_info_from_fd(int fd, struct 
gen_device_info *devinfo)
   return false;
 
if (!getparam(fd, I915_PARAM_REVISION, >revision))
-   return false;
+  devinfo->revision = 0;
 
if (!query_topology(devinfo, fd)) {
   if (devinfo->gen >= 10) {
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 19.2.0 release plan

[Emil Velikov]

On Sunday, 18 August 2019, Matt Turner  wrote:

> On Thu, Aug 8, 2019 at 2:56 AM Emil Velikov 
> wrote:
> >
> > On Wed, 7 Aug 2019 at 21:43, Mark Janes  wrote:
> > >
> > > Eric Engestrom  writes:
> > >
> > > > On 2019-07-31 at 09:38, Emil Velikov 
> wrote:
> > > >> Hi all,
> > > >>
> > > >> Here is the tentative release plan for 19.2.0.
> > > >>
> > > >> As many of you are well aware, it's time to the next branch point.
> > > >> The calendar is already updated, so these are the tentative dates:
> > > >>
> > > >>  Aug 06 2019 - Feature freeze/Release candidate 1
> > > >>  Aug 13 2019 - Release candidate 2
> > > >>  Aug 20 2019 - Release candidate 3
> > > >>  Aug 27 2019 - Release candidate 4/final release
> > > >>
> > > >> This gives us around 1 week until the branch point.
> > > >>
> > > >> Note: In the spirit of keeping things clearer and more transparent,
> we
> > > >> will be keeping track of any features planned for the release in
> > > >> Bugzilla [1].
> > > >>
> > > >> Do add a separate "Depends on" for each work you have planned.
> > > >> Alternatively you can reply to this email and I'll add them for you.
> > > >>
> > > >> [1] https://bugs.freedesktop.org/show_bug.cgi?id=111265
> > > >
> > > > Thanks!
> > > >
> > > > As per previous discussions (I don't remember where, sorry) as well
> as
> > > > internal discussions, I think we should add all currently open
> > > > regressions since 19.1 as blockers for this release.
> > >
> > > My understanding is that the "feature tracker" blocks the creation of
> > > the release branchpoint.  A separate "release tracker" blocks the
> > > release of 19.2.0.  Unfixed regressions go on the "release tracker",
> not
> > > the "feature tracker".  We backport bug fixes to release branches, but
> > > we don't backport features.
> > >
> > Yes that is correct. We are interested in features for the next few days.
> > Afterwords we'll focus on bugfixes.
>
> The last bug in the feature tracker was closed on the 14th. Can we make
> RC1 now?
>

Hi Matt,

Sure thing. I'm about to board the plane in a few minutes, I'll roll RC1
first thing tomorrow morning.

Thanks
Emil
P.S. Pardon the html formatting
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111430] modesetting driver causes artefacts on HD Graphics 620

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=111430

--- Comment #1 from Vova  ---
Created attachment 145100
  --> https://bugs.freedesktop.org/attachment.cgi?id=145100=edit
artefacts in konsole

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111430] modesetting driver causes artefacts on HD Graphics 620

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=111430

Bug ID: 111430
   Summary: modesetting driver causes artefacts on HD Graphics 620
   Product: Mesa
   Version: 19.1
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/X11
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: vova7...@mail.ru
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 145099
  --> https://bugs.freedesktop.org/attachment.cgi?id=145099=edit
artefacts lines in kate

I using "intel" Xorg driver at present time because modesetting driver has
artefacts on kde5. Artefacts is like lines on konsole app or kate, blinking on
gwenview and other. Another thing: in wayland session with kde is all fine, so
I think this is not problem of kwin composition, but it not 100%

Operating System: Arch Linux 
KDE Plasma Version: 5.16.4
KDE Frameworks Version: 5.60.0
Qt Version: 5.13.0
Kernel Version: 5.2.9-arch1-1-ARCH
OS Type: 64-bit
Processors: 4 × Intel® Core™ i7-7500U CPU @ 2.70GHz
Memory: 7,7 GiB
Mesa: 19.1.4-1

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] radv/gfx10: do not emit PA_SC_TILE_STEERING_OVERRIDE twice

[Samuel Pitoiset]

CLEAR_STATE emits it for us.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/si_cmd_buffer.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index a5057fe25a2..68ec925f2b5 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -366,8 +366,6 @@ si_emit_graphics(struct radv_physical_device 
*physical_device,
radeon_set_context_reg(cs, R_028C50_PA_SC_NGG_MODE_CNTL,
   S_028C50_MAX_DEALLOCS_IN_WAVE(512));
radeon_set_context_reg(cs, 
R_028C58_VGT_VERTEX_REUSE_BLOCK_CNTL, 14);
-   radeon_set_context_reg(cs, 
R_02835C_PA_SC_TILE_STEERING_OVERRIDE,
-  
physical_device->rad_info.pa_sc_tile_steering_override);
radeon_set_context_reg(cs, R_02807C_DB_RMI_L2_CACHE_CONTROL,
   
S_02807C_Z_WR_POLICY(V_02807C_CACHE_STREAM_WR) |
   
S_02807C_S_WR_POLICY(V_02807C_CACHE_STREAM_WR) |
-- 
2.22.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] radv: do not emit PKT3_CONTEXT_CONTROL with AMDGPU 3.6.0+

[Samuel Pitoiset]

It's emitted by the kernel.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_device.c   | 9 ++---
 src/amd/vulkan/si_cmd_buffer.c | 9 ++---
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 05d09bb08eb..110808fb98d 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -2008,9 +2008,12 @@ VkResult radv_CreateDevice(
device->empty_cs[family] = device->ws->cs_create(device->ws, 
family);
switch (family) {
case RADV_QUEUE_GENERAL:
-   radeon_emit(device->empty_cs[family], 
PKT3(PKT3_CONTEXT_CONTROL, 1, 0));
-   radeon_emit(device->empty_cs[family], 
CONTEXT_CONTROL_LOAD_ENABLE(1));
-   radeon_emit(device->empty_cs[family], 
CONTEXT_CONTROL_SHADOW_ENABLE(1));
+ /* Since amdgpu version 3.6.0, CONTEXT_CONTROL is emitted 
by the kernel */
+   if (device->physical_device->rad_info.drm_minor < 6) {
+   radeon_emit(device->empty_cs[family], 
PKT3(PKT3_CONTEXT_CONTROL, 1, 0));
+   radeon_emit(device->empty_cs[family], 
CONTEXT_CONTROL_LOAD_ENABLE(1));
+   radeon_emit(device->empty_cs[family], 
CONTEXT_CONTROL_SHADOW_ENABLE(1));
+   }
break;
case RADV_QUEUE_COMPUTE:
radeon_emit(device->empty_cs[family], PKT3(PKT3_NOP, 0, 
0));
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 701b2398b50..a5057fe25a2 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -161,9 +161,12 @@ si_emit_graphics(struct radv_physical_device 
*physical_device,
 {
int i;
 
-   radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0));
-   radeon_emit(cs, CONTEXT_CONTROL_LOAD_ENABLE(1));
-   radeon_emit(cs, CONTEXT_CONTROL_SHADOW_ENABLE(1));
+   /* Since amdgpu version 3.6.0, CONTEXT_CONTROL is emitted by the kernel 
*/
+   if (physical_device->rad_info.drm_minor < 6) {
+   radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0));
+   radeon_emit(cs, CONTEXT_CONTROL_LOAD_ENABLE(1));
+   radeon_emit(cs, CONTEXT_CONTROL_SHADOW_ENABLE(1));
+   }
 
if (physical_device->has_clear_state) {
radeon_emit(cs, PKT3(PKT3_CLEAR_STATE, 0, 0));
-- 
2.22.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111406] [regression] - build failure on arm64

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=111406

--- Comment #1 from Fabio Pedretti  ---
Notes:
- builds fine on Ubuntu eoan, fails on disco and bionic
- builds fine on amd64 and i386
- I am compiling with -flto

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111408] [clover] build failure ‘clang::Language’ has not been declared

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=111408

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #1 from Michel Dänzer  ---
You need clang SVN r367864 or newer. clang doesn't provide any way for clover
to continue building against older SVN trunk snapshots.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 110662] shadow artifacts in Assassin's Creed: Unity

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110662

Michel Dänzer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|NOTOURBUG   |---

--- Comment #20 from Michel Dänzer  ---
(In reply to tempel.julian from comment #19)
> But the issue in Unity is still there when using LLVM. So, afterall, it
> seems it is a bug in LLVM and not radv (hence closing).

It's too early too conclude that. RADV could be feeding something bad to LLVM.
AMDVLK also uses LLVM, after all.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Bug 111370] Cannot get OpenCL visible with Radeon VII installation

[Mihai]

I am not sure if their amdgpu-pro supports Radeon VII. Have you also tried
ROCm? Their effort is mostly focused around ROCm these days.
You could try it. If you encounter errors, this is their issue page:
https://github.com/RadeonOpenCompute/ROCm/issues

You could also pinpoint if there an issue of incompatibility between the
hardware by blacklisting the modules.

---
Sent from mobile, apologies for typos.

On Sat, 10 Aug 2019, 16:31 ,  wrote:

> Bug ID 111370 
> Summary Cannot get OpenCL visible with Radeon VII installation
> Product Mesa
> Version unspecified
> Hardware x86-64 (AMD64)
> OS Linux (All)
> Status NEW
> Severity normal
> Priority medium
> Component Drivers/Vulkan/radeon
> Assignee mesa-dev@lists.freedesktop.org
> Reporter charlesshe...@my.unt.edu
> QA Contact mesa-dev@lists.freedesktop.org
>
> Created attachment 145019 
>  [details] 
> 
> requested reports from Radeon VII installation instructions
>
> I am a post doctoral researcher at University of North Texas.  We recently
> purchased a Dell 7425 system with Dual AMD EPYC 7281 16-Core Processors, an 
> AMD
> Radeon VII graphics card from Sapphire Technology and a Xilinx Alveo FPGA
> accelerator card.  This equipment was purchased to analyze the differences in
> various algorithms' performance on CPU, GPU, and FPGA implementations with
> OpenCL.  So far, we have been unable to get either the Radeon VII or the Alveo
> to display as an OpenCL platform.
>
> Radeon drivers were downloaded from AMD website and the amdgpu-pro-install
> script was used for the installation. The install script listed this site to
> report problems if we did not have an AMD Customer Engagement Representative.
> Perhaps someone here could help me get one of these representatives?
>
> This may actually be a duplicate of 110035, although I am using 18.04.1 rather
> than 18.04.2 and I login remotely and use command line access to the OpenCL
> platforms.
>
> I have attached the reports suggested by the installation instructions.
>
> I apologize if this is the wrong location to file this issue; I feel I should
> be dealing with AMD customer support staff, but have not been able to find a
> contact for support in the install instructions except this forum.  Please
> direct me to the correct location if possible.
>
> Is it possible the Xilinx and Radeon OpenCL platforms conflict with each 
> other?
>
> Thank you, Charles
>
> --
> You are receiving this mail because:
>
>- You are the assignee for the bug.
>- You are the QA Contact for the bug.
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev