You are not logged in.
Hello everyone!
Warning: An arch newbie here! I have decided to finally move to a lightweight, pro distro after long using various -buntus in ways they were completely stripped for a low-end laptop so I thought why not start being stripped and build upwards instead of the other direction :-)
I am not really happy with the GPU performance now. I have xf86-video-radeon and I have mesa, but I get nearly as bad performance as if I would use LLVMpipe. The system is bleeding fast and memory usage is much less than before in the other systems so I think there is some configuation problem that makes it slow when running 3D applications.
This is my hardware:
*-display
description: VGA compatible controller
product: RC410M [Mobility Radeon Xpress 200M]
vendor: Advanced Micro Devices, Inc. [AMD/ATI]
physical id: 5
bus info: pci@0000:01:05.0
version: 00
width: 32 bits
clock: 66MHz
capabilities: pm msi vga_controller bus_master cap_list rom
configuration: driver=radeon latency=64 mingnt=8
resources: irq:17 memory:c0000000-cfffffff ioport:9800(size=256) memory:fe1f0000-fe1fffff memory:c0000-dffff
...
...
*-cpu
description: CPU
product: Intel(R) Celeron(R) M CPU 420 @ 1.60GHz
vendor: Intel Corp.
physical id: 4
bus info: cpu@0
version: 6.14.8
serial: 0000-06E8-0000-0000-0000-0000
slot: CPU 1
size: 1600MHz
width: 32 bits
clock: 133MHz
capabilities: boot fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx constant_tsc
arch_perfmon bts cpuid aperfmperf pni monitor tm2 xtpr pdcm dtherm
*-cache:0
description: L1 cache
physical id: 5
slot: L1-Cache
size: 32KiB
capacity: 32KiB
capabilities: internal write-back data
configuration: level=1
*-cache:1
description: L2 cache
physical id: 6
slot: L2-Cache
size: 1MiB
capacity: 1MiB
capabilities: internal write-back instruction
configuration: level=2
*-memory
description: System Memory
physical id: 1b
slot: System board or motherboard
size: 1536MiB
*-bank:0
description: DIMM DDR Synchronous
product: PartNum0
vendor: Manufacturer0
physical id: 0
serial: SerNum0
slot: DIMM0
size: 1GiB
width: 64 bits
*-bank:1
description: DIMM DDR Synchronous
product: PartNum1
vendor: Manufacturer1
physical id: 1
serial: SerNum1
slot: DIMM1
size: 512MiB
width: 64 bitsOne more thing is this:
[root@prenex-laptop work]# DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
OpenGL renderer string: ATI RC410I am bugged if this is hardware accelerated, but at first sight it seems so, however much slower than what I used to have earlier and despite I messed around in XOrg.conf on other systems earlier I remember the default setting was still blazing fast compared to what I see now.
The card itself is an r300-era mobile card from ati so I was not trying amdgpu.
What is weird to me is that usually the renderer string used to say "Gallium 0.4 on ATI RC410" while now it is not saying the gallium part! Is this the issue? Do I run some non-gallium drivers or why performance degraded much? glxgears barely run at 40-50 FPS with this now...
Please help! In the meantime I will continue to set up my system and regular stuff like that...
PS.: I was always using open source drivers and they are pretty much usable. They are actually pretty good for this GPU with good performance as far as I used them so it is not the case that I secretly used fglrx before (my card is not even supported there anymore).
Offline
Well, you have at least a card which a) still works with X b) is even accelerated. :-)
I have some machines, where the best I can do is a VESA mode..
Offline
I must confess that surely it is accelerated because I have tried:
export LIBGL_ALWAYS_SOFTWARE=1; glxgears; etrAnd that is much-much more worse. Yes I am pretty happy with my machine despite it is a mid-range laptop from 2007, but that is irrelevant here. What is weird is that the same seemed to have better performance on a non-arch linux and the GL renderer reported thee was said to be gallium 0.4 over this and that in glxinfo where here it does not say so.
It basically boils down to: "How can I know if this driver is gallium or just plain mesa and is there any packages I should know about?" - I am wondering on this...
PS.: Btw I have working internet, dwm, pale moon browser with alsa sound and youtube working (despite slowly - might be browser issue too) and I have managed to get the whole system up and running quite well. So far it is mostly a positive experience, but naturally one wants his original performance back after changing systems. In some ways I have visibly more performance actually, but the GPU bugs me a bit ;-)
Last edited by prenex (2019-05-17 16:57:58)
Offline
You could also check out the pentium4 with SSE2 optimization
(see https://bbs.archlinux32.org/viewtopic.php?id=2738) to get
more general perfomance (especially if all of the pentium4 packages
have once been rebuilt with march=pentium4).
I have to confess, that my newest ATI card is a ATI Radeon X1600, but there I'm running Archlinux 64-bit,
see http://www.andreasbaumann.cc/blog/archl … ook-a1211/
so I'm really not an expert in all this new mesa, gallium whatever stuff. :-)
Offline
Nice blog ;-)
I already have Architecture=auto but I was not the man who changed it, it was already like this. I saw the packages are many (most of the) times installed with march=pentium4 so I kind of suspected it works. I have installed arch32 from a Belorussian mirror btw as that was closest. I am happy there is a seperate architecture for SSE2 as it can lead to over a 2x / 4x speedup (not generally, but for good use cases).
As far as I understand gallium is not new. Maybe gallium9 (directx for linux) is new, but I intend to play with that only later. As far as I understand gallium is like a well-defined interface of the gpu driver that opengl or vdpau and stuff like that can call. Someone made "gallium9" which is directx 9 implemented over this gallium layer and it saves some clocks for wine gaming as there is no need to first translate to opengl. I only know about this because I intend to try it in the future for testing some games better compatibility maybe.
It seems to me that a driver can be either a gallium supporting one or just a plain mesa, but both can still have hardware acceleration, but most seemed to be gallium 0.4 ones nevertheless. I just know about that there were (are?) non-gallium drivers so it came to my mind that maybe that is the case.
The other thing that came to my mind is that maybe the opengl renderer string just does not say "Gallium on ...." but it is still doing that and the string got changed, but for llvmpipe I think it still says it like that. So I only hoped maybe there are people who know if this is just a string change or indeed I am running a different driver than what my earlier system was running with. The latter would explain perfomance differences just I have no idea how to get to know what is going on in this case :-)
TL;DR: If anyone knows a way to tell "is this driver a gallium driver or not" that would be nice. I think the original driver was "r300g" (g means gallium) but I am just trying to find out how the things are.
https://www.phoronix.com/scan.php?page= … &px=OTcxNw
^^I have no idea how to check which I am having, but reading from this it would be weird if somehow the old driver is in use on my new install now....
PS.: Thank you for the fast answer btw! I am happy there is a community ;-)
EDIT: What version of the radeon and mesa driver is this? Can I tell it somehow from the packages?
Last edited by prenex (2019-05-17 20:49:49)
Offline
Okay I have added my xorg.conf changes for enabling higher AGP speeds and some tricky options disabled otherwise and have gained 290-300 FPS in glxgears when vblank is off.
Section "Device"
Identifier "Configured Video Device"
Option "AGPMode" "16"
Option "AGPFastWrite" "True"
Option "EnablePageFlip" "True"
Option "SwapbuffersWait" "False"
Option "DRI" "2"
Option "ColorTiling" "on"
EndSection
Section "Monitor"
Identifier "Configured Monitor"
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1024x768"
EndSubSection
EndSection
Section "Extensions"
Option "Composite" "Disable"
EndSectionAlso I can squeeze around further 1-5% improvement by an:
echo "high" > /sys/class/drm/card0/device/power_profileAfter this I started to play some games that I was happily running before, both wine and non-wine ones. 2D games still work as they should, but 3D still has a very visible performance drop. When I say very visible I would say at least 50 to 100% worse performance than what I was used to on a 16.04 buntu.
There is a hint that the driver is a gallium driver as I see the stat bars after writing in this:
export GALLIUM_HUD="cpu,fps;primitives-generated"However I would prefer if the driver says it is gallium in its opengl string as an env var can get into other things via copy-paste anyways...
I have tried gallium nine too, but that says my GPU is not good-enough. I do not know about any "sample code" that is testing gallium by itself directly but would be nice to know about some.
It is also possible that xorg became radically slower or the radeon driver became radically slower or the kernel itself became radically slower or whatever like that :-(. But still I would love to have some explanation. Weirdly enough running with a 1-2 years ago kernel (and maybe X?) was letting me having a nearly as fast open driver as fglrx was originally but now it is like 10-20 years in the past according to its speed.
The only big thing I know about that might affect me is meltdown and spectre mitigations as this is a single core machine. I will try my best to turn them off as I just don't really care for them. Also I have personally tested with code that most of those just don't affect my CPU anyways.
Btw.: glxgears uses 20% of my cpu time, with occasionally xorg also using up to 20% while running it and moving windows around. Can someone check how much CPU is used in their cases? Sadly I cannot compare the system to my earlier one as I removed that, so I can just suspect that there should not be big cpu usage when just doing simple 3d with no interaction...
PS.: This slowdown is enourmous and before I could play Urban Terror, or Nexus: The jupiter incident without any kind of slowdown(!). Literally it went smooth like raindrops falling from the air. Now they are unplayable slideshows (I named a non-wine and a wine game too here).
Last edited by prenex (2019-05-18 10:42:07)
Offline
Removing spectre and meltdown mitigations gained me some 3-10% performance upgrade too, but still the performance dropoff is really visible. Just for comparison, earlier I could play UrT (Urban Terror) fluidly without frame drops and through wine Mount&Blade: Warband was also going without any lagging which was quite awsome from a machine that came much earlier than the game itself ;-)
Now both of those are unplayable. I also used godot 3.1 and blender on my earlier setup for development and I guess they might be slow too (I haven't installed them yet as there are still a lot of things to do). This is just sad a bit as I didn't expect a performance drop after having 3D acceleration up and running. I thought the hard part is to have it up and running and that's all.
Offline
Just for those interested, the extra kernel parameters I have added are these:
noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier agp=try_unsupported Offline
Still things are very slow compared to what was before even after I have built a custom kernel and made a lot of other effort :-(
Further info here:
https://www.phoronix.com/forums/forum/l … ith-radeon
I just wanted to share that forum as a cross-reference here as on both places there are helpful advises for people with performance problems. I am happy that I went through all the customization so far and yes I can see a very minor gain from them, but I think there must be some bigger issue I am overlooking completely in the graphics pipeline.
Offline
Is there any way to quickly test various kernel versions between 4.4.0-21 and 4.15.0-45?
Is there any way to quickly downgrade to various mesa between 11.2.0 and the current one?
Hopefully there is some kind of archive for the packages and some description about how to use it so that I can locate the problem. I have a version which is fast and a version which has slow 3D. I have found an ubuntu 16.04 that also has the problem and one later 16.04 that does not. The kernel version numbers are taken from them.
The distribution does not count here! Not an arch bug, but I hope to analyse on arch. It is either some configuration change, kernel source tree change or mesa/xorg change or something similar. CPU usage is high when performance is bad (despite acceleartion). Memory movements in the driver are happening over 50-70% of the cpu time leading to 100% usage!
Last edited by prenex (2019-05-24 00:50:47)
Offline
I can't help with getting hold of old packages for things, but once you have them you can relatively quickly install them from disc using pacman -U. You'll still need to reboot to actually test anything, so I wouldn't describe it as a quick process, mind you.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
I have tried this after finding that arch32 has a package archive:
sudo pacman -U https://archive.archlinux32.org/packages/l/linux-lts/linux-lts-4.4.39-1-i686.pkg.tar.xz https://archive.archlinux32.org/packages/l/linux-lts-headers/linux-lts-headers-4.4.39-1-i686.pkg.tar.xz
linux-lts-4.4.39-1-i686 56,1 MiB 210K/s 04:33 [############################################################] 100%
linux-lts-4.4.39-1-i686.sig 310,0 B 303K/s 00:00 [############################################################] 100%
linux-lts-headers-4.4.39-1-i686 6,6 MiB 185K/s 00:37 [############################################################] 100%
linux-lts-headers-4.4.39-1-i686.sig 310,0 B 0,00B/s 00:00 [############################################################] 100%
csomagok betöltése...
figyelmeztetés: visszatérés egy régebbi linux-lts verzióhoz (4.19.38-1.0 => 4.4.39-1)
hiba: nem sikerült előkészíteni a tranzakciót (érvénytelen csomagarchitektúra)
:: a(z) linux-lts-4.4.39-1-i686 csomaghoz nincs érvényes architektúra definiálva
:: a(z) linux-lts-headers-4.4.39-1-i686 csomaghoz nincs érvényes architektúra definiálvaIn Hungarian it says the architecture is invalid for the packages. I am on a 32 bit machine of course and I saw both "pentium4" (for the SSE2 support) and "i686" packages got installed from the normal package mirrors earlier when using pacman. How is this possible?
PS.: These packages are from 2017 and the archive says the 2017 packages were scrapped from the official Arch linux package archives because they still supported 32 bit back then I guess. Is this the cause why there is a problem?
Last edited by prenex (2019-05-24 12:04:43)
Offline
Oh... for some reason I had to change /etc/pacman.conf to use Architecture = i686 instead of "auto"
Offline
Tryng with the old kernel the performance is still bad so I wanted to downgade mesa to some much earlier version.
This latter is harder than downgrading the kernel, because in the new setup with mesa 19.x I see there is some other package called "glvnd" and that is the one who provides "libgl". I cannot remove or downgrade mesa, because:
installing mesa (17.0.0-1) breaks dependency 'opengl-driver' required by libglvndI think an extra layer was added at a random time and mesa seems to support that after a while but not in old versions. This way I can only do a downgrade if I downgrade all my system to years ago - which takes forever and sounds risky - or first maybe install something that provides libgl directly and only remove the current package afterwards. It is messy like hell :-(.
PS.: I was trying to search if libgl was maybe provided by a seperate package earlier or not but arch32 archives became offline now. Is that a planned maintenance or I should notify someone?
EDIT: archive is up and running once again. never mind.
Last edited by prenex (2019-05-24 13:38:19)
Offline
Older packages have dependencies to other older packages, so the only supported downgrade
is to go back to a certain point in time. But this is a little bit counterintuitive for using Arch, as
Arch always has the newest and shiniest software - whether it's fast, supports feature X or even
sometimes - aeh works.
You could try to recompile only the older versions of some critical packages like mesa, but you
risk to hit API incompatibilities, as Xorg, mesa, kernel usually also move together.
Offline
You are right...
I have managed to change towards an old mesa 13.x (19.x currently - just for comparison how big is the change) and I was lucky that I still got some basic apps working but not only things were at completely different places, but a lot of API incompatibilities have happened between all the layers and it took me considerable time to just bring back the original setup.
I see that theoretically there is a way to just "downdate" / downgrade all my packages to lets say 2017 using the arch archive, but I think this functionality was planned for shorter term changes originally. I mean... for example the new mesa uses this libglvnd which is a package now but was nowhere a package back in 2017 maybe. Okay maybe it was there but differently and packages might have served different stuff all though with different dependencies on each other.
I have no idea what the hell would happen if I would issue a complete downgrade and switching the package mirrors to a years old archive so maybe manually trying to cherry pick might be still better.
The way I have tried it is to use pacman -Rdd on mesa and libglvnd and some relevant packages and try to build up only the 3d infrastructure to fit into this whole in the package dependency tree but nothing else. Even this failed somehow and I got a half-working system just as you warn me...
Maybe it is a much much better way to just use pacman -Rc and let it remove everything that relies on mesa and install everything from some kind of old archive package repo from some date and use the oldest possible kernel while doing so... I should have done this way originally... it seems to be more work, but much less error-prone than ignoring dependencies and doing manual fixup...
PS.: I am only doing this with the intention to find where is the original issue (in mesa or in what package) so this also made me go to the partial downgrade direction with hopes that maybe I can corner the source of the problem better. It seems it is not the radeon code in the kenel neither other kernel things (but I did not rule out configuration completely yet).
Last edited by prenex (2019-05-24 23:55:51)
Offline
Just for the information: I have managed to get the highest 3D speed so far on arch32 with a custom kernel and a lot of customization - but I had to downgrade mesa to 11.x version from 2016. I wanted to try cornering the problem more exactly but archives do not always work all the time.
Still I wanted to just clear it up even more surely that it is likely a problem with mesa or xorg that got slowed down for my card for some reason when updated to the latest ones. If I circumvent the problem I get lightning fast speeds (faster than before actually), just I cannot keep my system "partially downgraded". It is likely not the best practice anyways and a lot of apps like browsers stop working if I do this partial downgrade.
I will keep trying to find the issue in mesa/x source trees somehow. I am comfortable with Arch32 and its features, speed etc, just I am plagued by a bug/issue unrelated to the distro...
PS.: Okay... archives could work better haha. That is my only complaint - but maybe I should profile mesa or x sources directly somehow to spot the issues instead of cornering which release slowed my r300 kind of card down...
Last edited by prenex (2019-05-27 22:39:11)
Offline
For mesa 11.x and linux 4.4.x try Ubuntu 16.04. Alternatives with still active support would be CentOS 6.10 and Debian 8.
Offline
Certainly switching from arch to Debian 8 would feel like a backward step. Sure, you want mesa and dependencies rolled back, but you didn't ask for all of your user space applications to be from the past too.
But it's largely academic anyway. Prenex didn't ask for a supported system, he just wanted to know which old releases worked best so that he can compare and contrast sources.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Update:
Actually I know for sure that the problem is in the mesa source tree as I can easily go back in git and use a version that is fast - while I have kept my latest kernel, xorg, apps, everything. Of course this does not sound the safest and most sane thing to do, but I only do it to corner the source of the problem. Now bisecting with git and soon I will get a single revision that causes the biggest slowdown. Actually now only 8-9 revisions seem to be a candidate. Soon I will be there.
Actually in the bisecting procedure I have found that there are at least two "slowdown points": one makes a difference in the number of GEM_CREATE ioctl calls (not reusing objects, but always creating, using, closing strategy now when bad) and an other much smaller issue that just makes the number of ioctl calls grow - but generally. As I could only go one way when bisecting I choose to go towards the bigger issue.
After I get a single commit (or a few one?) that causes this I can just revert those changes manually hopefully in the very latest mesa codebase and run my system like that. Then I must discuss with some people at mesa how to approach fixing it "properly" in that sense that it might be a useful thing for other card owners, but a really bad thing to my card maybe if the issue is in shared code paths. Of course maybe it is just a bug, but I am not sure.
Currently at here in bisecting:
bad: b672c3833b7
good: aff1ad0798and being at this point it tells me:
Bisecting: 9 revisions left to test after this (roughly 3 steps)
[3efedf98e8272d1a32a3837b22161582d28c4487] i965: Always flush caches after blitting to a GL buffer object.Also now compiation is not even taking an hour like before where bisect was jumping big time periods as code now barely changes between checkouted versions after a bisect step I guess ;-)
PS.: Actually the very commit message at the current point seems to be suspicious for me actually because that is very much the change I see. I would be not surprised if this for some reason as a side effect would cause a slowdown for my case. Also the kernel drivers for r300 are the same when things are fast and when slow, but maybe more recent cards got a kernel-source-tree driver update where they handle the "not reuse bo strategy" much better and that hurts my card which didn't got that or anything like this.
PS2.: Actually the latest 16.04 updates also show a slowdown so it would be not a good thing for me to stick with those systems just to "survive a bit longer" with usable acceleration. Also we better just fix it if we can. I really have hopes now after all the suffering haha :-)
Last edited by prenex (2019-06-03 10:04:55)
Offline
PS3.: The suspicious commit is still "good" so it was a false quess. I better just find the issue properly and tell that next...
Offline
8b3a257851905ff444d981e52938cbf2b36ba830 is the first bad commit
commit 8b3a257851905ff444d981e52938cbf2b36ba830
Author: Marek Olšák <marek.olsak@amd.com>
Date: Tue Jul 18 16:08:44 2017 -0400
radeonsi: set a per-buffer flag that disables inter-process sharing (v4)
For lower overhead in the CS ioctl.
Winsys allocators are not used with interprocess-sharable resources.
v2: It shouldn't crash anymore, but the kernel will reject the new flag.
v3 (christian): Rename the flag, avoid sending those buffers in the BO list.
v4 (christian): Remove setting the kernel flag for now
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
-> I will look at the changeset
-> I'll try to make a temporal manual revert of this in latest mesa
-> I will try to ask people to discuss how to fix this "properly" so my fix does not slow down others in a similar way...
EDIT: Oh man... that commit is a huge changeset :-(
Last edited by prenex (2019-06-03 11:31:46)
Offline
Problem is solved and now the fix is also accepted in the mesa sources!
See here:
http://ballmerpeak.web.elte.hu/devblog/ … stack.html
and here:
https://www.phoronix.com/scan.php?page= … e-Fix-2019
;-)
Offline
This is amazing! Way to go. :-)
That's exactly how we can make use of old hardware when more people are willing
to get their hands dirty and start to fix problems.
It also shows another important thing: companies with open specs should be favoured
in OpenSource, as they can be made working even after the company is no longer maintaining
drivers. Companies like Nvidia are not really a good example..
Offline
Really nice blog BTW. :-)
Offline