Re: Spam

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 lik

Spam

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

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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=98502 Emil Velikov changed: What|Removed |Added Status|REOPENED|RESOLVED

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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=98502 Eugene Shalygin changed: What|Removed |Added Resolution|FIXED

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

https://bugs.freedesktop.org/show_bug.cgi?id=98502 Emil Velikov changed: What|Removed |Added Resolution|--- |FIXED

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

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

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

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

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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=98502 Eugene Shalygin changed: What|Removed |Added CC|

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

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]

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

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 > >

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

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

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

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

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

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

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

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

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

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 > >

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

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 > >

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

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

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

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

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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=98502 Andreas Radke changed: What|Removed |Added CC|

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

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

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

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

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

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

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

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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=98502 Michel Dänzer changed: What|Removed |Added CC|

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

.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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.