All of lore.kernel.org
 help / color / mirror / Atom feed
From: machion@disroot.org
To: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@vger.kernel.org, regressions@lists.linux.dev,
	amd-gfx@lists.freedesktop.org, alexander.deucher@amd.com,
	christian.koenig@amd.com
Subject: Re: Unplayable framerates in game but specific kernel versions work,  maybe amdgpu problem
Date: Fri, 10 Oct 2025 11:06:47 +0200	[thread overview]
Message-ID: <748446b7fa6a53f31c69a4e40257adae@disroot.org> (raw)
In-Reply-To: <fadf714ecdc2e3bd5bed0c3ee69177a1@disroot.org>

Hi again,

I have a question:

Would it be possible to make the "memory management/buffering" methodes 
switchable through a conf file (obviously amdgpu.conf)?
So that I don't have to keep an old kernel version installed just to 
play my game.

Marion


Am 2025-06-17 11:42, schrieb machion@disroot.org:
> I feared that.
> 
> It seems a crazy problem, when many people are affected and in opposite 
> ways.
> This ReBAR/UEFI thing is also new to me, but I don't have this on my 
> system either (using BIOS/MBR).
> 
> I hope, it can be fixed for all scenarios.
> 
> Marion
> 
> Am 2025-06-16 15:29, schrieb Alex Deucher:
>> On Fri, Jun 13, 2025 at 3:38 PM <machion@disroot.org> wrote:
>>> 
>>> Hi,
>>> sorry for the delay.
>>> Besides less time, I had to make myself familiar with bisecting and
>>> again kernel compiling. Last time I compiled the kernel myself was
>>> around 2010 I think.
>>> 
>>> Anyway it seems I found the bad commit. The result after bisecting 10
>>> commits is:
>>> 
>>> a53d959fe660341788cb8dbc3ac3330d90a09ecf is the first bad commit
>>> commit a53d959fe660341788cb8dbc3ac3330d90a09ecf
>>> Author: Christian König <christian.koenig@amd.com>
>>> Date:   Thu Mar 20 14:46:18 2025 +0100
>>> 
>>>      drm/amdgpu: immediately use GTT for new allocations
>>> 
>>>      commit a755906fb2b8370c43e91ba437ae1b3e228e8b02 upstream.
>>> 
>>>      Only use GTT as a fallback if we already have a backing store. 
>>> This
>>>      prevents evictions when an application constantly allocates and
>>> frees new
>>>      memory.
>>> 
>>>      Partially fixes
>>>      
>>> https://gitlab.freedesktop.org/drm/amd/-/issues/3844#note_2833985.
>>> 
>>>      Signed-off-by: Christian König <christian.koenig@amd.com>
>>>      Fixes: 216c1282dde3 ("drm/amdgpu: use GTT only as fallback for
>>> VRAM|GTT")
>>>      Acked-by: Alex Deucher <alexander.deucher@amd.com>
>>>      Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>>>      Cc: stable@vger.kernel.org
>>>      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> 
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> Unfortunately reverting that commit will reintroduce a similar
>> performance issue for lots of other uses.  See:
>> https://gitlab.freedesktop.org/drm/amd/-/issues/3844#note_2827990
>> for a description of the fundemental problem.
>> 
>> Alex
>> 
>>> 
>>> Marion
>>> 
>>> 
>>> Am 2025-05-08 15:18, schrieb Alex Deucher:
>>> > On Thu, May 8, 2025 at 9:13 AM <machion@disroot.org> wrote:
>>> >>
>>> >> Hello kernel/driver developers,
>>> >>
>>> >> I hope, with my information it's possible to find a bug/problem in the
>>> >> kernel. Otherwise I am sorry, that I disturbed you.
>>> >> I only use LTS kernels, but I can narrow it down to a hand full of
>>> >> them,
>>> >> where it works.
>>> >>
>>> >> The PC: Manjaro Stable/Cinnamon/X11/AMD Ryzen 5 2600/Radeon HD
>>> >> 7790/8GB
>>> >> RAM
>>> >> I already asked the Manjaro community, but with no luck.
>>> >>
>>> >> The game: Hellpoint (GOG Linux latest version, Unity3D-Engine v2021),
>>> >> uses vulkan
>>> >>
>>> >> ---
>>> >>
>>> >> I came a long road of kernels. I had many versions of 5.4, 5.10, 5.15,
>>> >> 6.1 and 6.6 and and the game was always unplayable, because the frames
>>> >> where around 1fps (performance of PC is not the problem).
>>> >> I asked the mesa and cinnamon team for help in the past, but also with
>>> >> no luck.
>>> >> It never worked, till on 2025-03-29 when I installed 6.12.19 for the
>>> >> first time and it worked!
>>> >>
>>> >> But it only worked with 6.12.19, 6.12.20 and 6.12.21
>>> >> When I updated to 6.12.25, it was back to unplayable.
>>> >
>>> > Can you bisect to see what fixed it in 6.12.19 or what broke it in
>>> > 6.12.25?  For example if it was working in 6.12.21 and not working in
>>> > 6.12.25, you can bisect between 6.12.21 and .25.
>>> >
>>> > Alex
>>> >
>>> >>
>>> >> For testing I installed 6.14.4 with the same result. It doesn't work.
>>> >>
>>> >> I also compared file /proc/config.gz of both kernels (6.12.21 <>
>>> >> 6.14.4), but can't seem to see drastic changes to the graphical part.
>>> >>
>>> >> I presume it has something to do with amdgpu.
>>> >>
>>> >> If you need more information, I would be happy to help.
>>> >>
>>> >> Kind regards,
>>> >> Marion

WARNING: multiple messages have this Message-ID (diff)
From: machion@disroot.org
To: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@vger.kernel.org, regressions@lists.linux.dev,
	amd-gfx@lists.freedesktop.org, alexander.deucher@amd.com,
	christian.koenig@amd.com
Subject: Re: Unplayable framerates in game but specific kernel versions work, maybe amdgpu problem
Date: Fri, 10 Oct 2025 11:06:47 +0200	[thread overview]
Message-ID: <748446b7fa6a53f31c69a4e40257adae@disroot.org> (raw)
In-Reply-To: <fadf714ecdc2e3bd5bed0c3ee69177a1@disroot.org>

Hi again,

I have a question:

Would it be possible to make the "memory management/buffering" methodes 
switchable through a conf file (obviously amdgpu.conf)?
So that I don't have to keep an old kernel version installed just to 
play my game.

Marion


Am 2025-06-17 11:42, schrieb machion@disroot.org:
> I feared that.
> 
> It seems a crazy problem, when many people are affected and in opposite 
> ways.
> This ReBAR/UEFI thing is also new to me, but I don't have this on my 
> system either (using BIOS/MBR).
> 
> I hope, it can be fixed for all scenarios.
> 
> Marion
> 
> Am 2025-06-16 15:29, schrieb Alex Deucher:
>> On Fri, Jun 13, 2025 at 3:38 PM <machion@disroot.org> wrote:
>>> 
>>> Hi,
>>> sorry for the delay.
>>> Besides less time, I had to make myself familiar with bisecting and
>>> again kernel compiling. Last time I compiled the kernel myself was
>>> around 2010 I think.
>>> 
>>> Anyway it seems I found the bad commit. The result after bisecting 10
>>> commits is:
>>> 
>>> a53d959fe660341788cb8dbc3ac3330d90a09ecf is the first bad commit
>>> commit a53d959fe660341788cb8dbc3ac3330d90a09ecf
>>> Author: Christian König <christian.koenig@amd.com>
>>> Date:   Thu Mar 20 14:46:18 2025 +0100
>>> 
>>>      drm/amdgpu: immediately use GTT for new allocations
>>> 
>>>      commit a755906fb2b8370c43e91ba437ae1b3e228e8b02 upstream.
>>> 
>>>      Only use GTT as a fallback if we already have a backing store. 
>>> This
>>>      prevents evictions when an application constantly allocates and
>>> frees new
>>>      memory.
>>> 
>>>      Partially fixes
>>>      
>>> https://gitlab.freedesktop.org/drm/amd/-/issues/3844#note_2833985.
>>> 
>>>      Signed-off-by: Christian König <christian.koenig@amd.com>
>>>      Fixes: 216c1282dde3 ("drm/amdgpu: use GTT only as fallback for
>>> VRAM|GTT")
>>>      Acked-by: Alex Deucher <alexander.deucher@amd.com>
>>>      Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>>>      Cc: stable@vger.kernel.org
>>>      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> 
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> Unfortunately reverting that commit will reintroduce a similar
>> performance issue for lots of other uses.  See:
>> https://gitlab.freedesktop.org/drm/amd/-/issues/3844#note_2827990
>> for a description of the fundemental problem.
>> 
>> Alex
>> 
>>> 
>>> Marion
>>> 
>>> 
>>> Am 2025-05-08 15:18, schrieb Alex Deucher:
>>> > On Thu, May 8, 2025 at 9:13 AM <machion@disroot.org> wrote:
>>> >>
>>> >> Hello kernel/driver developers,
>>> >>
>>> >> I hope, with my information it's possible to find a bug/problem in the
>>> >> kernel. Otherwise I am sorry, that I disturbed you.
>>> >> I only use LTS kernels, but I can narrow it down to a hand full of
>>> >> them,
>>> >> where it works.
>>> >>
>>> >> The PC: Manjaro Stable/Cinnamon/X11/AMD Ryzen 5 2600/Radeon HD
>>> >> 7790/8GB
>>> >> RAM
>>> >> I already asked the Manjaro community, but with no luck.
>>> >>
>>> >> The game: Hellpoint (GOG Linux latest version, Unity3D-Engine v2021),
>>> >> uses vulkan
>>> >>
>>> >> ---
>>> >>
>>> >> I came a long road of kernels. I had many versions of 5.4, 5.10, 5.15,
>>> >> 6.1 and 6.6 and and the game was always unplayable, because the frames
>>> >> where around 1fps (performance of PC is not the problem).
>>> >> I asked the mesa and cinnamon team for help in the past, but also with
>>> >> no luck.
>>> >> It never worked, till on 2025-03-29 when I installed 6.12.19 for the
>>> >> first time and it worked!
>>> >>
>>> >> But it only worked with 6.12.19, 6.12.20 and 6.12.21
>>> >> When I updated to 6.12.25, it was back to unplayable.
>>> >
>>> > Can you bisect to see what fixed it in 6.12.19 or what broke it in
>>> > 6.12.25?  For example if it was working in 6.12.21 and not working in
>>> > 6.12.25, you can bisect between 6.12.21 and .25.
>>> >
>>> > Alex
>>> >
>>> >>
>>> >> For testing I installed 6.14.4 with the same result. It doesn't work.
>>> >>
>>> >> I also compared file /proc/config.gz of both kernels (6.12.21 <>
>>> >> 6.14.4), but can't seem to see drastic changes to the graphical part.
>>> >>
>>> >> I presume it has something to do with amdgpu.
>>> >>
>>> >> If you need more information, I would be happy to help.
>>> >>
>>> >> Kind regards,
>>> >> Marion

  reply	other threads:[~2025-10-10 12:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07 13:10 Unplayable framerates in game but specific kernel versions work, maybe amdgpu problem machion
2025-05-08 13:18 ` Alex Deucher
2025-05-08 13:18   ` Alex Deucher
2025-06-13 19:38   ` machion
2025-06-13 19:38     ` machion
2025-06-16 13:29     ` Alex Deucher
2025-06-16 13:29       ` Alex Deucher
2025-06-17  9:42       ` machion
2025-06-17  9:42         ` machion
2025-10-10  9:06         ` machion [this message]
2025-10-10  9:06           ` machion
  -- strict thread matches above, loose matches on Subject: below --
2025-05-07 12:50 machion

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=748446b7fa6a53f31c69a4e40257adae@disroot.org \
    --to=machion@disroot.org \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=regressions@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.