Hello, In the Message; Subject : Re: bios -> uefi boot, because of: resizable bar need csm off Message-ID : <99c25487-cfd0-31f5-d0c5-123a06be970a@becherer.de> Date & Time: Mon, 3 Jun 2024 14:43:05 +0200 [SB] == Simon Becherer <simon@becherer.de> has written: SB> hi masaru, SB> Am 03.06.24 um 12:03 schrieb Masaru Nomiya: [...] MN> > BTW, did you read this curious articles about ATI? MN> > https://gitlab.freedesktop.org/drm/amd/-/issues/1864 SB> no, i do not think i know. SB> but link did not work, is it correct? i see gitlab did some updates SB> at the moment. SB> so if its correct, i have to wait for the page comming up again. Revived! Thanks, Tom & Dave. Anyway, doubtful is this part; This linked benchmark tests BAR clearing speeds while allocating up to 90% of VRAM (this is hardcoded to 16GB, so manually adjust line 31 to your VRAM size). On my setup, roughly half of the regions can be wiped quickly (~1.5ms), while the remaining shows a behavior that is excessively slow (~20ms). After a BIOS update, the slow regions improved to ~10ms, but this is still unacceptable performance. The issue reproduces when both Above 4G decoding and Resizable BAR is enabled in the BIOS. For me, it goes away when either Resizable BAR is disabled in the BIOS, or I manually patch the kernel to rebind the BAR memory to somewhere else (by patching out this check). Isn't your problem with Resizable BAR or Smart Aceess Memory? I hope it doesn't have deep roots. I seem have got a cold, so I'm going to bed now. This is why I don't want to get old...... Best Regards & Good Night. --- ┏━━┓彡 Masaru Nomiya mail-to: m.nomiya @ gmail.com ┃＼／彡 ┗━━┛ "A society bound by e-mail and mobile phones deprives us of the freedom to face ourselves and indulge our fantasies." -- Michael Crichton (Speech in Japan) --