You are not logged in.

#1 Re: Pacman / Pacman Upgrades » libreoffice libicuuc.so.63 no such file » 2019-08-19 14:52:03

It seems I can install "icu" but it installs v.64 instead of v.63 that is needed here and there seems to be no depencency for it neither because I hand-installed it. After install it still not work, so I tried symbolic linking the v.64 version's binary to masquerade as the old v.63 one to see there are issues in that too:

[prenex@prenex-laptop Whatsapp]$ libreoffice 
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
/usr/lib/libreoffice/program/soffice.bin: symbol lookup error: /usr/lib/libreoffice/program/libi18nlangtag.so: undefined symbol: _ZN6icu_636Locale14createFromNameEPKc

I do not know about the javaldx error message, but the latter seems to tell me that just masquerading the v.64 binaries as the v.63 ones in ICU does not help the package. Maybe the package is broken then if this is the case.

#2 Pacman / Pacman Upgrades » libreoffice libicuuc.so.63 no such file » 2019-08-19 14:29:50

prenex
Replies: 7

After a full update I get the following when trying to start libreoffice:

[prenex@prenex-laptop Whatsapp]$ sudo pacman -Syyu
[sudo] prenex jelszava: 
:: A csomagadatbázisok szinkronizálása...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  160k  100  160k    0     0   106k      0  0:00:01  0:00:01 --:--:--  106k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 2199k  100 2199k    0     0   135k      0  0:00:16  0:00:16 --:--:--  163k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5811k  100 5811k    0     0   201k      0  0:00:28  0:00:28 --:--:--  369k
:: Teljes rendszerfrissítés indítása...
figyelmeztetés: libjpeg-turbo: a helyi (2.0.2-1.1) újabb, mint a(z) extra (2.0.2-1.0)
 nincs teendő
[prenex@prenex-laptop Whatsapp]$ libreoffice 
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: libicuuc.so.63: cannot open shared object file: No such file or directory

Everything seems to be completely updated, but I wonder if I have a bad system or others have this issue too. I have no idea how I have the later than the extra libjpeg-turbo though.

This is in my mirrorlist file:

...
# Belorus
Server = [url]http://mirror.datacenter.by/pub/archlinux32/$arch/$repo[/url]
...

#3 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-06-14 21:00:23

andreas_baumann wrote:

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.

Maybe I can look up other issues despite they are of smaller performance upgrades or specific issues for games I like but have glitches.
At least now I have working hacks to enable HyperZ on my machine too (that is a new thing and an other bug report)... it was not working before neither and it gives a small boost. Currently my quickfix likely only fixes things on my very own machine, but at least I see the direction of the problem maybe.

Proper solution is still far away and stock mesa works for many others with HyperZ and r300:

https://bbs.archlinux32.org/post.php?ac … t&tid=2739

andreas_baumann wrote:

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..

Nvidia only gives closed drivers now and still no docs and stuff? I understand they did so in the past, but I have no idea what they do today. If they only give the closed ones and not open specs that is really bad, because even if they ship good and working drivers to linux there will be a time when they just stop working and no one will have any idea whatsoever what to do - except bloody reversing sessions :-(

It would be amazing if there would be some law that any person who shares a source code or docs for any IT system not updated and supported in the last two years - let it be from any source they get their hands on it - should do that freely for the happiness of humanity. There is no real reason to not share unsupported products sources and specs - except capitalist business bigotry...

andreas_baumann wrote:

Really nice blog BTW. :-)

Thanks ;-)

#5 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-06-03 10:18:07

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 :-(

#6 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-06-03 09:11:26

PS3.: The suspicious commit is still "good" so it was a false quess. I better just find the issue properly and tell that next...

#7 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-06-03 09:00:43

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: aff1ad0798

and 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 :-)

#8 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-27 21:36:54

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...

#9 Re: Pacman / Pacman Upgrades » arch32 archive packages: xproto signature is invalid » 2019-05-25 15:35:32

I guess many packages did not have an md5sum and now it seems that it is necessary. I succesfully installed the packages after downgrading pacman itself to the version in the repository archives.

This latter is a dangerous thing, because it can lead to a state where your downgraded pacman does not work anymore so you brick your system... It have happened to me as old packman wanted libcrypto 1.0 and the new one only had 1.1 so it became unusable. Luckily i could just link 1.1 to act like 1.0 so neither the system is bricked (yet?) and old mesa, x and stuff i want to test got installed... I will test them now, this problem is solved and i only document it here.

Despite it worked for me i understand that normally i shouldnt really do pacman -Syy without the "u" flag and would not advise downgrading packman while keeping other packages the latest.

#10 Re: Pacman / Pacman Upgrades » arch32 archive packages: xproto signature is invalid » 2019-05-25 13:36:54

Every package checksum is bad which is highly unlikely... Can i ignore the checksums?

#11 Re: Pacman / Pacman Upgrades » arch32 archive packages: xproto signature is invalid » 2019-05-25 13:21:25

Maybe it is just the server erring.. Will try the original arch archive too because these are really old repos anyways from times they still had support for 32 bits... Will tell the results...

#12 Re: Pacman / Pacman Upgrades » arch32 archive packages: xproto signature is invalid » 2019-05-25 12:58:32

Ah.. Murphy's law... SigLevel = Never seems to be the solution...but now it has checksum problems for some reasons. I must tell i did a pacman -Syy without "u" ás i just wanted the database, but not to downgrade all the system... Only mesa and related stuff i am debugging...

#13 Pacman / Pacman Upgrades » arch32 archive packages: xproto signature is invalid » 2019-05-25 12:38:20

prenex
Replies: 5

Dear Arch32 community!

I cannot copy-paste errors, because i am experimenting with installing a mesa package from 2017 archives.

After fixing some 404 and timeout errors now i have all the old packages, but i get a signature is invalid error.

I am new to arch and pacman btw. The system was the latest before i tried this installation from the archives.

I had to try an old mesa only for debugging a slowdown in 3D performance. I have a good cause to try this :-)

Van i force pacman to ignore (maybe too old) signatures? I Know they are from a good source and i only need the packages for debugging...

The way i am doing this is that i have added old 2017 mirrors from arch32 archives and hunted down further 3 packages with proper versions from the original arch linux archive. Before this i have removed mesa with everything that depends on mesa so that everything is clean. This latter was done with pacman -Rc mesa >> orig.txt.

I have tried to install first one of the three packages i have downloaded manually, with: pacman -U libxfont-1.5.2-1-i686.pkg.tar.xz and it depends on fontsproto, xproto, etc that exist in the arch32 archive mirror i set. It downloads it and tells "signature from Andreas Radke <emailaddr> is invalid.

I have tried pacman-key --init and --populate, but i am not sure what to do or how to ignore signedness. System time is todays time. Should i force it to 2017? :-)

Ps.: Sorry, i was writing from a tiny mobile phone...

#14 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-24 22:49:28

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).

#15 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-24 12:35:36

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 libglvnd

I 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.

#16 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-24 11:16:12

Oh... for some reason I had to change /etc/pacman.conf to use Architecture = i686 instead of "auto"

#17 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-24 11:04:05

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álva

In 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?

#18 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-23 23:49:54

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!

#19 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-21 10:04:56

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.

#20 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-18 11:10:14

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 

#21 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-18 10:46:27

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.

#22 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-18 09:39:06

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"
EndSection

Also I can squeeze around further 1-5% improvement by an:

echo "high" > /sys/class/drm/card0/device/power_profile

After 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).

#23 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-17 19:18:52

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?

#24 Re: Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-17 15:53:23

I must confess that surely it is accelerated because I have tried:

export LIBGL_ALWAYS_SOFTWARE=1; glxgears; etr

And 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 ;-)

#25 Kernel & Hardware » RC410M [Mobility Radeon Xpress 200M] » 2019-05-17 10:12:38

prenex
Replies: 26

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 bits

One more thing is this:

      [root@prenex-laptop work]# DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
      OpenGL renderer string: ATI RC410

I 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).

Board footer

Powered by FluxBB