ISO
ISO copied to clipboard
helloSystem
AMD Renoir/Cezanne GPU: Sluggish and laggy desktop
Good day,
This is a Ryzen 5700G box running HelloSystem 0.7.0 off an external SSD USB with 32 GB of RAM. Assigend 2 GB to VRAM in BIOS.
The system behaves quite poorly, anything that is drawn on the screen takes even seconds to appear.
- Even typing letters have to wait for a second from hitting the key to the actual letter to appear on screen.
- Mouse cursor jumps from location to location making it hard to click on any menu/icon
Querying the About System reports the system has 32GB of RAM, instead of 30 GB, leaving the 2 GB of RAM used theoretically by the iGPU. I presume HelloSystem is bypassing BIOS settings and finds no memory assigned to the GPU thus its performance is a PITA?
I would appreciate any help on how to solve this issue, and let me know if I can provide more info to identify why this happens.
Regards, RR
Hello @roired, thanks for reporting this.
Please run:
sysctl dev.vgapci | grep pnpinfo
and post the result here. Thanks!
And please upload a Hardware Proble using 0G155 or later (this has the Hardware Probe URL bug fixed) and share the URL. Thanks!
Good day @probonopd ,
here is the outcome of that terminal command:
dev.vgapci.0.%pnpinfo: vendor=0x1002 device=0x1638 subvendor=0x1458 subdevice=0xd000 class=0x030000
by 0G155 you mean a new release of HelloSystem?, I'll have to download a new ISO and reinstall the whole thing?
By the way, maybe related, or maybe the cause, not sure, but in order to boot the USB with HelloSystem I need to manually select it in the BIOS boot menu, it does not boot automatically as the other USB SSDs with other oses [Kinoite, Haiku, Windows]. Maybe something in the boot process is not behaving as expected?
Regards, RR
by 0G155 you mean a new release of HelloSystem?, I'll have to download a new ISO and reinstall the whole thing?
Yes, I mean the latest pre-release build in the 0G... series that will become 0.7.0 in due time. You do not need to install it in order to submit a Hardware Probe, just write it to a USB stick and boot from it, e.g., using the Create Live Media utility.
dev.vgapci.0.%pnpinfo: vendor=0x1002 device=0x1638 subvendor=0x1458 subdevice=0xd000 class=0x030000
So this is the GPU in question:
https://bsd-hardware.info/?d=helloSystem&id=pci:1002-1638-1458-d000
This AMD chipset is called "Renoir/Cezanne".
Apparently hardware support in FreeBSD is possible with version 5.5 of drm-kmod but it looks like we are still on 5.4:
https://hauweele.net/~gawen/blog/?p=2607
Maybe @gawen947 can send us a pkg for version 5.5 of drm-kmod for FreeBSD 13.0-RELEASE?
@evadot may know whether the symptoms you are describing would be addressed by 5.5.
So it looks like the Hardware Probe finally got uploaded?
Then I presume I'll have to wait to see the desktop behave :]
Thanks @probonopd , Regards, RR
Also,
Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so
gets loaded by Xorg rather than the Radeon module. So possibly the PCI IDs of Renoir/Cezanne devices need to be added to https://github.com/nomadbsd/NomadBSD/blob/master/config/etc/initgfx_device.db as well once Renoir/Cezanne support has landed in drm-kmod.
I suppose that adding the ID before we get the new drm-kmod will not improve things, but if you would like to try it out, it might be worth a try. Add your Device ID 0x1638 to radeon_ids() to /etc/initgfx_device.db, delete /var/initgfx_config.id, and reboot. Worst thing that could happen is that Xorg won't start anymore, so better enable SSH access to your machine beforehand should you need it to revert the changes.
cc @mrclksr
So it looks like the Hardware Probe finally got uploaded?
They always got uploaded, but there was a stupid bug crashing the GUI before it was showing the Probe URL. FIxed.
5.5 cannot work with 13.0-RELEASE, it needs new linuxkpi addition. It works with 13-STABLE tough.
This was a quick and dirty backport from 13-STABLE to 13-RELEASE. It's a mix between patching the driver, patching /usr/src and ditching things that would just not work on RELEASE. It works enough that I can use my laptop for work but this is clearly not in state of providing a pkg.
I intentionally didn't publish a working tarball for 13-RELEASE along the post because I didn't want people to use this in the wild without understanding the consequences. Backtraces and panic can/do occur.
OK, so we will hopefully see it in a future helloSystem that will be based on 13.1-RELEASE. Thanks a lot @evadot @gawen94.
Good day @probonopd ,
I'll try to do that test you pointed out in the next days, though not sure yet when. Worst thing that may happen is that I have to reinstall. Not such a big deal. Thanks for the tip @probonopd
@evadot @gawen947 , thanks for the explanation. Willing to test it out once is merged into release and forwarded to HelloSystem.
Regards, RR
… a future helloSystem that will be based on 13.1-RELEASE. …
https://github.com/helloSystem/ISO/releases
graphics/drm-510-kmod
- http://beefy16.nyi.freebsd.org/build.html?mastername=131amd64-default&build=cfc19930a459 built for latest
- http://beefy14.nyi.freebsd.org/build.html?mastername=131amd64-quarterly&build=8327a5f1bca6 queued for quarterly.
https://github.com/helloSystem/drm-510-kmod.pkg
Maybe archive this repository, if the availability of FreeBSD-provided packages will be satisfactory.
Maybe archive this repository, if the availability of FreeBSD-provided packages will be satisfactory.
How can whe know when this time will be there? (Probably when 13.0 is no longer supported + 1 quarter = when 13.1 came out + 3 quarters?)
… (Probably when 13.0 is no longer supported + 1 quarter = when 13.1 came out + 3 quarters?)
If the packages will be in quarterly and latest within the next few days, why assume so much longer?
I think they start building against the latest released minor version of FreeBSD once the previous one is eol, a quarter after the new minor version came out. And then we have to wait (in the worst case) one quarter for it to appear in quarterly. Or am I wrong? (is this documented somewhere clearly?)