Re: Spam

[Matt Turner]

On Mon, Aug 28, 2023 at 8:25 AM Mike Blumenkrantz
 wrote:
> Hi,
>
> As everyone has likely noticed, we've had a significant uptick of spam on 
> Mesa-related IRC channels lately. Sometimes these occurrences go on for many 
> hours before someone takes action.
>
> I'd like to request that all commonly-affected channels (#dri-devel, 
> #intel-3d, #freedesktop, ???) take some time over the next week and staff up 
> on more moderators for greater coverage.

It seems absurd that we cannot prevent a single Estonian man (with
mental health problems?) from spamming our channels for more than 10
years across two IRC networks.

Here's a similar thread from llvm-dev about the same person:
https://groups.google.com/g/llvm-dev/c/VaFMoTRdt40/m/k4EmXJRqBgAJ

Do we have any information about the real-life person? If so, maybe we
can contact their ISP or something?

Spam

[Mike Blumenkrantz]

Hi,

As everyone has likely noticed, we've had a significant uptick of spam on
Mesa-related IRC channels lately. Sometimes these occurrences go on for
many hours before someone takes action.

I'd like to request that all commonly-affected channels (#dri-devel,
#intel-3d, #freedesktop, ???) take some time over the next week and staff
up on more moderators for greater coverage.


Mike

Re: [Mesa-dev] ***SPAM*** [PATCH v2 16/22] clover: Implement clCreateProgramWithILKHR

[Francisco Jerez]

Pierre Moreau  writes:

> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/api/dispatch.hpp |  4 ++
>  src/gallium/state_trackers/clover/api/program.cpp  | 29 -
>  src/gallium/state_trackers/clover/core/program.cpp | 68 
> +-
>  src/gallium/state_trackers/clover/core/program.hpp | 14 +
>  4 files changed, 110 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp 
> b/src/gallium/state_trackers/clover/api/dispatch.hpp
> index 0910e19422..21bd379fe6 100644
> --- a/src/gallium/state_trackers/clover/api/dispatch.hpp
> +++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
> @@ -900,6 +900,10 @@ namespace clover {
> cl_int
> IcdGetPlatformIDsKHR(cl_uint num_entries, cl_platform_id *rd_platforms,
>  cl_uint *rnum_platforms);
> +
> +   cl_program
> +   CreateProgramWithILKHR(cl_context d_ctx, const void *il,
> +  const size_t length, cl_int *r_errcode);

Make the the length argument non-const to match the spec's type
signature.

>  }
>  
>  #endif
> diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
> b/src/gallium/state_trackers/clover/api/program.cpp
> index 6ec87ad128..ed3b679c7c 100644
> --- a/src/gallium/state_trackers/clover/api/program.cpp
> +++ b/src/gallium/state_trackers/clover/api/program.cpp
> @@ -22,6 +22,7 @@
>  
>  #include "api/util.hpp"
>  #include "core/program.hpp"
> +#include "spirv/invocation.hpp"
>  #include "util/u_debug.h"
>  
>  #include 
> @@ -128,6 +129,30 @@ clCreateProgramWithBinary(cl_context d_ctx, cl_uint n,
> return NULL;
>  }
>  
> +cl_program
> +clover::CreateProgramWithILKHR(cl_context d_ctx, const void *il,
> +   const size_t length, cl_int *r_errcode) try {
> +   auto  = obj(d_ctx);
> +
> +   if (!il || !length)
> +  throw error(CL_INVALID_VALUE);
> +
> +   uint32_t type = UINT32_MAX;

Since you're using pipe_shader_ir enumerants to represent the IL format
it would be a good idea to declare the IL type variables as such here
and below.

> +   if (spirv::is_binary_spirv(reinterpret_cast(il)))
> +  type = PIPE_SHADER_IR_SPIRV;
> +
> +   if (type == UINT32_MAX)
> +  throw error(CL_INVALID_VALUE);
> +
> +   // initialize a program object with it.

Capitalize the comment.

> +   ret_error(r_errcode, CL_SUCCESS);
> +   return new program(ctx, il, length, type);
> +
> +} catch (error ) {
> +   ret_error(r_errcode, e);
> +   return NULL;
> +}
> +
>  CLOVER_API cl_program
>  clCreateProgramWithBuiltInKernels(cl_context d_ctx, cl_uint n,
>const cl_device_id *d_devs,
> @@ -183,7 +208,7 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
>  
> validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
>  
> -   if (prog.has_source) {
> +   if (prog.has_source || prog.has_il) {
>prog.compile(devs, opts);
>prog.link(devs, opts, { prog });
> } else if (any_of([&](const device ){
> @@ -221,7 +246,7 @@ clCompileProgram(cl_program d_prog, cl_uint num_devs,
> if (bool(num_headers) != bool(header_names))
>throw error(CL_INVALID_VALUE);
>  
> -   if (!prog.has_source)
> +   if (!prog.has_source && !prog.has_il)
>throw error(CL_INVALID_OPERATION);
>  
> for_each([&](const char *name, const program ) {
> diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
> b/src/gallium/state_trackers/clover/core/program.cpp
> index 976213ef95..b9ba38d4e6 100644
> --- a/src/gallium/state_trackers/clover/core/program.cpp
> +++ b/src/gallium/state_trackers/clover/core/program.cpp
> @@ -24,24 +24,51 @@
>  #include "llvm/invocation.hpp"
>  #include "spirv/invocation.hpp"
>  #include "tgsi/invocation.hpp"
> +#include "spirv/invocation.hpp"
> +
> +#include 
>  
>  using namespace clover;
>  
>  program::program(clover::context , const std::string ) :
> -   has_source(true), context(ctx), _source(source), _kernel_ref_counter(0) {
> +   has_source(true), has_il(false), il_type(UINT32_MAX), context(ctx),
> +   _source(source), _kernel_ref_counter(0), _il(nullptr), _length(0) {
>  }
>  
>  program::program(clover::context ,
>   const ref_vector ,
>   const std::vector ) :
> -   has_source(false), context(ctx),
> -   _devices(devs), _kernel_ref_counter(0) {
> +   has_source(false), has_il(false), il_type(UINT32_MAX), context(ctx),
> +   _devices(devs), _kernel_ref_counter(0), _il(nullptr), _length(0) {
> for_each([&](device , const module ) {
>   _builds[] = { bin };
>},
>devs, binaries);
>  }
>  
> +program::program(clover::context , const void *il, const size_t length,

il/length (and their program member counterparts) look like an
open-coded std::vector.

> + const uint32_t type) :
> +   has_source(false), has_il(true), il_type(type), context(ctx),
> +   _kernel_ref_counter(0), 

[Mesa-dev] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #27 from Emil Velikov  ---
(In reply to Eugene Shalygin from comment #26)
> (In reply to Eugene Shalygin from comment #25)
> > Just found that dGPU wakes up when I connect an Android phone via USB.
> 
> No, any USB device makes that. kernel 4.10.8.

While the side effects are similar, the issue seems unrelated. There are some
suggestions in comment 23, that you might want to explode.

In either case, please keep it a separate bug report. Thank you!

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #26 from Eugene Shalygin  
---
(In reply to Eugene Shalygin from comment #25)
> Just found that dGPU wakes up when I connect an Android phone via USB.

No, any USB device makes that. kernel 4.10.8.

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

Eugene Shalygin  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #25 from Eugene Shalygin  
---
Just found that dGPU wakes up when I connect an Android phone via USB. And what
is worse, the dGPU does not power off after that until reboot.

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #24 from Emil Velikov  ---
Back to the original issue:

kernel, libdrm and mesa changes are in v4.10, v2.4.75 and [to be announced]
V17.1.0 respectively.

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #23 from Emil Velikov  ---
(In reply to Eugene Shalygin from comment #22)

> I don't quite understand the situation too. I observe two opposite
> behaviours with the same kernel version (4.9): lspci wakes up dGPU on
> ArchLinux or not (Gentoo). Which one is bugged?

As I said earlier - first, you want to ensure that the dGPU is powered off in
_both_ cases (Arch vs Gentoo). Assuming you're OK with building your own kernel
a couple of printfs is all you need.

If the state is not the same - check you can the conditions under which the
device should be powered-off - powertop toggles, something using your dGPU,
etc.

If they are - check with the lspci/other version and thus code used on both
systems.

In either case all this sounds unrelated to this bug, so I'd suggest keeping it
separate.

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #22 from Eugene Shalygin  
---
(In reply to Mauro Santos from comment #21)
> The difference between both is that with 4.4.52 the device stays powered off
> when using lspci but with 4.9.11 the device is automatically powered on.
> This is using all the same software versions, the only difference is booting
> into different kernel versions.

I don't quite understand the situation too. I observe two opposite behaviours
with the same kernel version (4.9): lspci wakes up dGPU on ArchLinux or not
(Gentoo). Which one is bugged?

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #21 from Mauro Santos  ---
(In reply to Alex Deucher from comment #20)
> Previously lspci would just read back from pci config space for stuff that
> was not cached which resulted in reading back all ones if the device was
> powered off, hence the rev ff.  The pci revision id is now cached so it's no
> longer read back from pci config space which is why is shows the proper
> value (rev 81).

You lost me here, I assume that by caching you mean the sysfs patch that adds
the revision field. I have tested with 4.4.52 and 4.9.11 and those do not have
that patch.

The difference between both is that with 4.4.52 the device stays powered off
when using lspci but with 4.9.11 the device is automatically powered on. This
is using all the same software versions, the only difference is booting into
different kernel versions.

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

Eugene Shalygin  changed:

   What|Removed |Added

 CC||eugene.shalygin+bugzilla.FD
   ||o...@gmail.com

-- 
You are receiving this mail because:
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #20 from Alex Deucher  ---
(In reply to Mauro Santos from comment #19)
> With 4.4.52 lspci says:  
> 03:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI]
> Mars [Radeon HD 8670A/8670M/8750M] [1002:6600] (rev ff)
> 
> With 4.9.11 lspci says:
> 03:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI]
> Mars [Radeon HD 8670A/8670M/8750M] [1002:6600] (rev 81)
> 
> Notice that the revision is different so I would bet the kernel was not
> behaving properly before.

Previously lspci would just read back from pci config space for stuff that was
not cached which resulted in reading back all ones if the device was powered
off, hence the rev ff.  The pci revision id is now cached so it's no longer
read back from pci config space which is why is shows the proper value (rev
81).

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #19 from Mauro Santos  ---
(In reply to Emil Velikov from comment #18)
> (In reply to Eugene Shalygin from comment #17)
> > To clarify: lspci was never waking up the dGPU. I assume that it was always
> > reading the device config file.
> 
> The kernel behaviour change(?) does sound surprising. I suggest checking
> that the device was powered off in both cases - leaning that it might not
> have been.

I do have to say that I see the same behavior, although at the time what made
me notice the change is behavior was a mesa update. The only change for the
following tests was booting with a different kernel.

With 4.4.52 lspci says:  
03:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Mars
[Radeon HD 8670A/8670M/8750M] [1002:6600] (rev ff)

With 4.9.11 lspci says:
03:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Mars
[Radeon HD 8670A/8670M/8750M] [1002:6600] (rev 81)

Notice that the revision is different so I would bet the kernel was not
behaving properly before.

Also /sys/kernel/debug/dri/1/radeon_pm_info says the following right after
using lspci:
With kernel 4.4.52:
PX asic powered off

With kernel 4.9.11:
uvdvclk: 0 dclk: 0
power level 0sclk: 3 mclk: 15000 vddc: 900 vddci: 0 pcie gen: 2

> That said, it sounds like the root of your issue is different than the one
> covered here - pardon for dragging you :-\

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #18 from Emil Velikov  ---
(In reply to Eugene Shalygin from comment #17)
> To clarify: lspci was never waking up the dGPU. I assume that it was always
> reading the device config file.

The kernel behaviour change(?) does sound surprising. I suggest checking that
the device was powered off in both cases - leaning that it might not have been.

That said, it sounds like the root of your issue is different than the one
covered here - pardon for dragging you :-\

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #17 from Eugene Shalygin  
---
To clarify: lspci was never waking up the dGPU. I assume that it was always
reading the device config file.

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #16 from Eugene Shalygin  
---
> Eugene if behaviour has changed across kernel versions...

I'm confident that from 2014 and up to 4.10.0 on my Gentoo machine this was
never the case. I don't quite understand what do I need to bisect, because the
same kernel sources (4.9.11) compiled using the same config give different
results on two identical laptops. May it be that a difference in environment
(at compile-time or run-time) causes this problem?

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #15 from Emil Velikov  ---
(In reply to Mauro Santos from comment #13)

> Aren't most patches in mesa and libdrm by now? At least the versions
> provided by Arch already seem to have the patches (or at least some of them).
> 
You know that everything is open-source right ;-)

Arch has also gone full rd mode and is patching mesa for EGL GLVND, but
none of the above patches are included. Yet the kernel and libdrm are vanilla.

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #14 from Emil Velikov  ---
(In reply to Tobias Droste from comment #12)
> (In reply to Eugene Shalygin from comment #11)
> > I have the same problem: Qt5 wakes up dGPU on launch [1]. However, I believe
> > that this is a kernel problem: the dGPU wakes up when a program tries to
> > read from /sys/bus/pci/devices//config. This was not happening with
> > 4.7 and when I use Arch's current LTS kernel (4.4) it also works fine [2].
> 
> As soon as all the patches landed (from comment #10) there's no need to
> check /sys/bus/pci/devices//config anymore, because there's a new
> API to get that info that doesn't need to wake up the device and the problem
> goes away. But right now the mesa patches are not applied as far as I can
> tell.
> 
Yes and no - yes the patches in comment #10 will help from graphics POV, but no
they won't help with the 'generic case' that Eugene is talking about. With
"generic case" being anyone reading the ./config file will wake up the device.

Eugene if behaviour has changed across kernel versions [i.e. you're confident
that with kernel X the dGPU was powered off and reading ./config did not wake
it up] feel free to bisect and report it.

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #13 from Mauro Santos  ---
(In reply to Tobias Droste from comment #12)
> (In reply to Eugene Shalygin from comment #11)
> > I have the same problem: Qt5 wakes up dGPU on launch [1]. However, I believe
> > that this is a kernel problem: the dGPU wakes up when a program tries to
> > read from /sys/bus/pci/devices//config. This was not happening with
> > 4.7 and when I use Arch's current LTS kernel (4.4) it also works fine [2].
> 
> As soon as all the patches landed (from comment #10) there's no need to
> check /sys/bus/pci/devices//config anymore, because there's a new
> API to get that info that doesn't need to wake up the device and the problem
> goes away. But right now the mesa patches are not applied as far as I can
> tell.
> 

Aren't most patches in mesa and libdrm by now? At least the versions provided
by Arch already seem to have the patches (or at least some of them).

The only missing piece seems to be the kernel patch which should land once
kernel 4.10 leaves testing.

However 4.9 does not have the patch and as it an LTS release it will stick
around for a while, it would be nice if the sysfs patch was also included in
4.9.

> > 
> > I can't believe that this is intentional [...]
> 
> It's not :-)

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #12 from Tobias Droste  ---
(In reply to Eugene Shalygin from comment #11)
> I have the same problem: Qt5 wakes up dGPU on launch [1]. However, I believe
> that this is a kernel problem: the dGPU wakes up when a program tries to
> read from /sys/bus/pci/devices//config. This was not happening with
> 4.7 and when I use Arch's current LTS kernel (4.4) it also works fine [2].

As soon as all the patches landed (from comment #10) there's no need to check
/sys/bus/pci/devices//config anymore, because there's a new API to get
that info that doesn't need to wake up the device and the problem goes away.
But right now the mesa patches are not applied as far as I can tell.

> 
> I can't believe that this is intentional [...]

It's not :-)

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #11 from Eugene Shalygin  
---
I have the same problem: Qt5 wakes up dGPU on launch [1]. However, I believe
that this is a kernel problem: the dGPU wakes up when a program tries to read
from /sys/bus/pci/devices//config. This was not happening with 4.7 and
when I use Arch's current LTS kernel (4.4) it also works fine [2].

I can't believe that this is intentional, because a) waking up dGPU on every
program launch does not make any sense and b) when the dGPU is disable via
acpi_call, any program hangs reading the same file. What puzzles me most is the
following: I have two almost identical laptops (for this bug they can be
treated as identical, I believe) and the second one, running Gentoo, is free
from this problem with the same versions of kernel. Moreover, with kernel
configured using config from the second one, the first one still shows the
problematic behaviour. 

[1] https://bugs.archlinux.org/task/52452
[2] https://bugzilla.kernel.org/show_bug.cgi?id=194721

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #10 from Emil Velikov  ---
Guys, the kernel (v4.10) has been updated to provide the revision field [1], at
the same time libdrm (v2.4.75) has API which does not fetch it [2] and the mesa
patches [3] to us the new API has been updated.

Sadly applying [3] triggers a libtool bug^Wfeature where linking fails on the
Intel CI. Once we get a workaround for that I'll apply [3].


[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=702ed3be1b1bf4dea05954168321741c0910c645
[2]
https://cgit.freedesktop.org/mesa/drm/commit/?id=11687bf4180f7e21045ed9c4730533c40fe01ea5
[3] https://patchwork.freedesktop.org/series/19714/

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

Andreas Radke  changed:

   What|Removed |Added

 CC||andy...@archlinux.org

-- 
You are receiving this mail because:
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #9 from Michel Dänzer  ---
I'm not sure what exactly you're asking me to do. Can you just ask on the
amd-gfx mailing list directly?

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #8 from Emil Velikov  ---
The kernel patch is out and should fit the mailing list archives in due time. 

Michel since Jammy is no longer around can you check (forward to AMDGPU-PRO
team)  about the implications of the "cheat" route, please ?

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #7 from Mauro Santos  ---
As a user, any band aid that will mask the problem until the proper long term
fix is in place will be very much welcomed.

As to how it is implemented, I am not familiar with the mesa and/or libdrm
code, if you think the cheat option will be the best stopgap measure I'll trust
your judgement.

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #6 from Emil Velikov  ---
Short term ideas:
libdrm
 - cheat, don't parse ./config. Read the revision_id file and set to zero if
missing. Default for all or toggle {config,revision_id} by envvar/API ?
 - roll revision_id-less API. Duplication of (already tad nasty) code :-(

mesa
 - go back to manual sysfs parsing in mesa
I'd like to avoid that if possible - makes BSD/other integration cumbersome,
code duplication (?)


Fwiw, I'm leaning for the "cheat" since no open-source user-space (seems to)
depend on the revision_id value, and aim for getting a kernel patch for
revision_id upstreamed.

Opinions/other ideas ?

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #5 from Emil Velikov  ---
That's because the drmDevice API retrieves the device revision id.

IIRC that was something explicitly requested by Jammy and the only way to get
the info is to parse ./config which wakes up the device.

AFAICT if using libudev one also needs to parse ./config since the kernel does
not expose a revision_id file/info like the {subsystem_,}{device,vendor} ones.

I think we'd really want to change that [in the long term]. There was a patch
for it, but seems like it never got sent/merged.

-- 
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 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||emil.l.veli...@gmail.com

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

Re: [Mesa-dev] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[mike . gorchak . qnx]

  JSent from my BlackBerry 10 smartphone on the Rogers network.From: bugzilla-dae...@freedesktop.orgSent: Sunday, October 30, 2016 10:25To: mesa-dev@lists.freedesktop.orgSubject: [Mesa-dev] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

  



  Bug ID
  98502
  



  Summary
  Delay when starting firefox, thunderbird or chromium and dmesg spam
  



  Product
  Mesa
  



  Version
  13.0
  



  Hardware
  x86-64 (AMD64)
  



  OS
  Linux (All)
  



  Status
  NEW
  



  Severity
  normal
  



  Priority
  medium
  



  Component
  Mesa core
  



  Assignee
  mesa-dev@lists.freedesktop.org
  



  Reporter
  registo.maill...@gmail.com
  



  QA Contact
  mesa-dev@lists.freedesktop.org
  

  

With mesa 13.0.0rc2 I'm seeing a 2 to 3 second delay when starting firefox,
thunderbird or chromium. This happens every time the programs are closed (all
instances) and run again. Glxgears (without prime offloading) also seems to be
affected as well as lspci, this wasn't the case before with mesa 12.0.3.

When this happens the following messages are logged in dmesg:

[drm] probing gen 2 caps for device 8086:9d18 = 9724043/e
[drm] enabling PCIE gen 3 link speeds, disable with radeon.pcie_gen2=0
[drm] PCIE GART of 2048M enabled (table at 0x001D6000).
radeon :03:00.0: WB enabled
radeon :03:00.0: fence driver on ring 0 use gpu addr 0x8c00 and
cpu addr 0x88042bbafc00
radeon :03:00.0: fence driver on ring 1 use gpu addr 0x8c04 and
cpu addr 0x88042bbafc04
radeon :03:00.0: fence driver on ring 2 use gpu addr 0x8c08 and
cpu addr 0x88042bbafc08
radeon :03:00.0: fence driver on ring 3 use gpu addr 0x8c0c and
cpu addr 0x88042bbafc0c
radeon :03:00.0: fence driver on ring 4 use gpu addr 0x8c10 and
cpu addr 0x88042bbafc10
radeon :03:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and
cpu addr 0xc90002235a18
radeon :03:00.0: failed VCE resume (-110).
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 1 succeeded in 1 usecs
[drm] ring test on 2 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 4 usecs
[drm] ring test on 4 succeeded in 4 usecs
[drm] ring test on 5 succeeded in 2 usecs
[drm] UVD initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 1 succeeded in 0 usecs
[drm] ib test on ring 2 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 4 succeeded in 0 usecs
[drm] ib test on ring 5 succeeded

I'm using a laptop with an Intel iGPU with and an AMD dGPU, it seems that with
mesa 13.0.0rc2 all the gpus in the system (iGPU+dGPU) are probed instead of
only the gpu that is going to be used (iGPU).

Given that the dGPU is usually automatically turned off for power saving it
takes 2 to 3 seconds to be re-initialized and this causes the delay on jOnstartup
for the programs I've mentioned before (I suspect many more are affected).

This might not be an actual bug (new intended behavior?) but it is a change in
behavior and it is annoying as opening any affected application will incur a 2
to 3 second delay on startup, even if all files are already cached iI. Njninibn ram and
the startup would otherwise be virtually instant.

OS: Arch Linux x86-64, kernel 4.8.4, mesa 13.0.0rc2, xorg 1.18.4 using the
modesetting driver for all cards.

Machine: Lenovo E560, iGPU HD Graphics 520 (rev 07), dGPU [AMD/ATI] Mars
[Radeon HD 8670A/8670M/8750M] (rev 81)

  


  
  You are receiving this mail because:

  
  You are the assignee for the bug.
  You are the QA Contact for the b. 
  



Sep 05, 2014_767.m4a
Description: Binary data
___
mesa-dev

[Mesa-dev] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #4 from Mauro Santos  ---
Created attachment 127635
  --> https://bugs.freedesktop.org/attachment.cgi?id=127635=edit
Bisect log

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #3 from Mauro Santos  ---
After bisecting (hope I've done it right), the first bad commit is
be239326aa4f9317d42ee07f0f51179c8b3d5b22

I've tried to revert this commit and test again but I haven't been able to do
so.

Bisect log is attached.

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #2 from Mauro Santos  ---
I'll try to bisect and see if I can find the offending commit, I'll post back
when I have a result.

Are there any tests you'd like me to do or other information you'd like me to
post?

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher  ---
If this is a regression can you bisect?

-- 
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] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

Bug ID: 98502
   Summary: Delay when starting firefox, thunderbird or chromium
and dmesg spam
   Product: Mesa
   Version: 13.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: registo.maill...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

With mesa 13.0.0rc2 I'm seeing a 2 to 3 second delay when starting firefox,
thunderbird or chromium. This happens every time the programs are closed (all
instances) and run again. Glxgears (without prime offloading) also seems to be
affected as well as lspci, this wasn't the case before with mesa 12.0.3.

When this happens the following messages are logged in dmesg:

[drm] probing gen 2 caps for device 8086:9d18 = 9724043/e
[drm] enabling PCIE gen 3 link speeds, disable with radeon.pcie_gen2=0
[drm] PCIE GART of 2048M enabled (table at 0x001D6000).
radeon :03:00.0: WB enabled
radeon :03:00.0: fence driver on ring 0 use gpu addr 0x8c00 and
cpu addr 0x88042bbafc00
radeon :03:00.0: fence driver on ring 1 use gpu addr 0x8c04 and
cpu addr 0x88042bbafc04
radeon :03:00.0: fence driver on ring 2 use gpu addr 0x8c08 and
cpu addr 0x88042bbafc08
radeon :03:00.0: fence driver on ring 3 use gpu addr 0x8c0c and
cpu addr 0x88042bbafc0c
radeon :03:00.0: fence driver on ring 4 use gpu addr 0x8c10 and
cpu addr 0x88042bbafc10
radeon :03:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and
cpu addr 0xc90002235a18
radeon :03:00.0: failed VCE resume (-110).
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 1 succeeded in 1 usecs
[drm] ring test on 2 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 4 usecs
[drm] ring test on 4 succeeded in 4 usecs
[drm] ring test on 5 succeeded in 2 usecs
[drm] UVD initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 1 succeeded in 0 usecs
[drm] ib test on ring 2 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 4 succeeded in 0 usecs
[drm] ib test on ring 5 succeeded

I'm using a laptop with an Intel iGPU with and an AMD dGPU, it seems that with
mesa 13.0.0rc2 all the gpus in the system (iGPU+dGPU) are probed instead of
only the gpu that is going to be used (iGPU).

Given that the dGPU is usually automatically turned off for power saving it
takes 2 to 3 seconds to be re-initialized and this causes the delay on startup
for the programs I've mentioned before (I suspect many more are affected).

This might not be an actual bug (new intended behavior?) but it is a change in
behavior and it is annoying as opening any affected application will incur a 2
to 3 second delay on startup, even if all files are already cached in ram and
the startup would otherwise be virtually instant.

OS: Arch Linux x86-64, kernel 4.8.4, mesa 13.0.0rc2, xorg 1.18.4 using the
modesetting driver for all cards.

Machine: Lenovo E560, iGPU HD Graphics 520 (rev 07), dGPU [AMD/ATI] Mars
[Radeon HD 8670A/8670M/8750M] (rev 81)

-- 
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] [PATCH] intel: Don't spam intelReadPixels: fallback to swrast in non-PBO case.

[Eric Anholt]

Kenneth Graunke kenn...@whitecape.org writes:

 When an application is using PBOs, we attempt to use the BLT engine to
 perform ReadPixels.  If that fails due to some restrictions, it's useful
 to raise a performance warning.

 In the non-PBO case, we always use a CPU mapping since getting the data
 into client memory requires a CPU-side copy.  This is a very common case,
 so raising a performance warning is annoying.  In particular, apitrace's
 image dumping code hits this path, causing it to print hundreds of
 thousands of performance warnings via ARB_debug_output.  This tends to
 obscure actual errors or other important messages.

Reviewed-by: Eric Anholt e...@anholt.net


pgpS5gCKoZ7pC.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel: Don't spam intelReadPixels: fallback to swrast all the time.

[Kenneth Graunke]

Unless the application is using PBOs, any call to glReadPixels will hit
this message.  Hitting this does mean mapping the buffer and accessing
it via the CPU, but that isn't necessarily the worst thing in the world.

apitrace's image dumping code hits this path, causing it to spam
hundreds of thousands of performance warnings via ARB_debug_output,
which makes it difficult to see actual errors.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/intel/intel_pixel_read.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_pixel_read.c 
b/src/mesa/drivers/dri/intel/intel_pixel_read.c
index 6b715d0..dd482af 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_read.c
@@ -188,8 +188,6 @@ intelReadPixels(struct gl_context * ctx,
intel_prepare_render(intel);
intel-front_buffer_dirty = dirty;
 
-   perf_debug(%s: fallback to swrast\n, __FUNCTION__);
-
/* Update Mesa state before calling _mesa_readpixels().
 * XXX this may not be needed since ReadPixels no longer uses the
 * span code.
-- 
1.8.2.3

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

Re: [Mesa-dev] [PATCH] intel: Don't spam intelReadPixels: fallback to swrast all the time.

[Eric Anholt]

Kenneth Graunke kenn...@whitecape.org writes:

 Unless the application is using PBOs, any call to glReadPixels will hit
 this message.  Hitting this does mean mapping the buffer and accessing
 it via the CPU, but that isn't necessarily the worst thing in the world.

 apitrace's image dumping code hits this path, causing it to spam
 hundreds of thousands of performance warnings via ARB_debug_output,
 which makes it difficult to see actual errors.

Maybe only do so when dumping out of the PBO path?  It seems like this
is something useful to know about in that case.


pgpA16ElFYZ74.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel: Don't spam intelReadPixels: fallback to swrast in non-PBO case.

[Kenneth Graunke]

When an application is using PBOs, we attempt to use the BLT engine to
perform ReadPixels.  If that fails due to some restrictions, it's useful
to raise a performance warning.

In the non-PBO case, we always use a CPU mapping since getting the data
into client memory requires a CPU-side copy.  This is a very common case,
so raising a performance warning is annoying.  In particular, apitrace's
image dumping code hits this path, causing it to print hundreds of
thousands of performance warnings via ARB_debug_output.  This tends to
obscure actual errors or other important messages.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/intel/intel_pixel_read.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_pixel_read.c 
b/src/mesa/drivers/dri/intel/intel_pixel_read.c
index 6b715d0..ebdc528 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_read.c
@@ -89,12 +89,7 @@ do_blit_readpixels(struct gl_context * ctx,
if (!src)
   return false;
 
-   if (!_mesa_is_bufferobj(pack-BufferObj)) {
-  /* PBO only for now:
-   */
-  DBG(%s - not PBO\n, __FUNCTION__);
-  return false;
-   }
+   assert(_mesa_is_bufferobj(pack-BufferObj));
 
struct gl_renderbuffer *rb = ctx-ReadBuffer-_ColorReadBuffer;
struct intel_renderbuffer *irb = intel_renderbuffer(rb);
@@ -178,9 +173,15 @@ intelReadPixels(struct gl_context * ctx,
 
DBG(%s\n, __FUNCTION__);
 
-   if (do_blit_readpixels
-   (ctx, x, y, width, height, format, type, pack, pixels))
-  return;
+   if (_mesa_is_bufferobj(pack-BufferObj)) {
+  /* Using PBOs, so try the BLT based path. */
+  if (do_blit_readpixels(ctx, x, y, width, height, format, type, pack,
+ pixels)) {
+ return;
+  }
+
+  perf_debug(%s: fallback to CPU mapping in PBO case\n, __FUNCTION__);
+   }
 
/* glReadPixels() wont dirty the front buffer, so reset the dirty
 * flag after calling intel_prepare_render(). */
@@ -188,8 +189,6 @@ intelReadPixels(struct gl_context * ctx,
intel_prepare_render(intel);
intel-front_buffer_dirty = dirty;
 
-   perf_debug(%s: fallback to swrast\n, __FUNCTION__);
-
/* Update Mesa state before calling _mesa_readpixels().
 * XXX this may not be needed since ReadPixels no longer uses the
 * span code.
-- 
1.8.2.3

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