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&
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,
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_
https://bugs.freedesktop.org/show_bug.cgi?id=98502
Emil Velikov changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
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 beca
https://bugs.freedesktop.org/show_bug.cgi?id=98502
Eugene Shalygin changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=98502
Emil Velikov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
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
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 of
https://bugs.freedesktop.org/show_bug.cgi?id=98502
Eugene Shalygin changed:
What|Removed |Added
CC||eugene.shalygin+bugzilla.FD
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)
>
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.
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 surpri
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 Conta
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,
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
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
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
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
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 h
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.
https://bugs.freedesktop.org/show_bug.cgi?id=98502
Andreas Radke changed:
What|Removed |Added
CC||andy...@archlinux.org
--
You are receiv
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
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, p
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 yo
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. Dupli
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.
AFAIC
https://bugs.freedesktop.org/show_bug.cgi?id=98502
Michel Dänzer changed:
What|Removed |Added
CC||emil.l.veli...@gmail.com
--
You are rec
.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
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&action=edit
Bisect log
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact f
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 att
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 t
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 m
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
* it prefetches up to a certain amount. This avoids dmesg spam.
+*/
ret = nouveau_bo_new(dev, NOUVEAU_BO_VRAM, 1 << 16,
-3 << NV50_CODE_BO_SIZE_LOG2, NULL, &screen->code);
+4 << NV50_CODE_BO_SIZE_LOG2, NUL
Kenneth Graunke 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 m
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
mping 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.
pgp
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
h
On March 3, 2013 12:14:54 AM Vadim Girlin wrote:
> On 03/02/2013 10:06 AM, Sebastien Caty wrote:
> > On March 1, 2013 06:24:01 PM Matt Turner wrote:
> >> On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty
> >
> > wrote:
> >>> Trying to dig more and found out which shader is causing trouble but I
> >>
41 matches
Mail list logo
