PDA

View Full Version : Gentoo, gcc 3.1, qt 3.0.4, and seq



Dedpoet
06-13-2002, 07:10 AM
Hey all. I just wanted to share my experience with setting up seq with the configuration in the title. I don't want to call this a "guide" since it's not step-by-step and seq is not supported under qt 3.x right now, which is why this is not in the help section. I just wanted to play because I'm a geek and that is what we do.

I set up Gentoo and did my entire stage 1 build with gcc 3.1 using the standard setup guide (www.gentoo.org) and this guide (http://forums.gentoo.org/viewtopic.php?t=3685). For those who have never done this, note that it takes several hours, even on a fast system. I am doing all of this on a 1.13 GHz P3 laptop with 256 meg RAM. The next step was building X, which also takes several hours. The consensus on the Gentoo forums is that compiles take longer with gcc 3.1, but performance is better in the end.

Once I had a working X (a couple more hours) I emerged qt 3.0.4. I didn't do it all at once, because I wanted to apply the patch that Zaphod mentioned here (http://seq.sourceforge.net/showthread.php?s=&threadid=1334). I just did the unpack first, applied the patch, then did the compile, install, and qmerge. 3.0.4 took significanly longer to compile than 2.3.2 under gcc 3.0 - I was at lunch when it finished, but I'm guessing a little under 2 hours.

I retrieved and built seq in the normal way. The only thing different is at the end of the configure, it reports, "Workable {???} Seq is not supported under qt 3.0" or something similar. The build went fine though, but took about 7 minutes as opposed to the 4 minutes it would take before.

I ran seq first under twm, and I got the following warnings when starting it up, but they did not seem to cause any serious problems:



QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> MapMenu::toggle_spawnPoints(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::set_interface_Font(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::set_interface_statusbar_Font(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::toggle_interface_SavePosition(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::toggle_interface_UseWindowPos(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::toggle_interface_UseStdout(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::toggle_interface_NoBank(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::select_interface_FormatFile(int)


Performance was "quirky" under twm, but I haven't eliminated bad ATi Radeon drivers as a possible cause yet. Processor usage was all over the chart and seemed to be very dependant upon size of the main window. It ran great in small windows, but as I increased the size, X started taking as much as 90% of the processor. I am going to play with the gatos drivers this weekend, which makes me nervous because I hosed my install with them once.

To eliminate the window manager variable, I installed fluxbox and had the same issues. I haven't tried kde yet because I haven't had the 4 hours to build it.

I'm going to start eliminating variables this weekend - first try kde, then gatos drivers. My suspicion is that the drivers will help the performance issue and kde won't make a difference. If both of those fail to help, I will build against qt 2.3.2 and try that.

I hope this helps someone in some way. Doing something like this is a great way to learn vast amounts about Linux, and it has been fun for me. I'll update this post after I try a few more things over the next few days.

-Dedpoet

[edited for a typo]

Ratt
06-13-2002, 08:56 AM
Nice post... please keep us updated on what happens when switching out different variables.

I'm about to reload 3 of my work machines with Gentoo (slowly converting over all of my groups Linux machines to Gentoo as they get refreshed) ... and some of the info here and elsewhere is proving to be valuable as a time saver ;)

fryfrog
06-13-2002, 11:16 AM
speaking of gentoo...

i've run into a couple of un-fun oddities so far.

1.) i can't get any kernel besides the 2.4.18-r1 to actually boot on my abit bp6 (dual celeron cpu's). they all get a "interrupt timed out on hda" or something like that. is it okay to copy a .config file from one kernel to another? i swear i'm picking things right but thats the only thing i can think of.
2.) emerge screen results in a "chmod /dev/pts/s0" error. it was compiled, and i was able to just copy the screen executable to /usr/bin from the /tmp/portage/blah blah/ dir, but it won't merge.

Dedpoet
06-13-2002, 11:26 AM
I merged KDE this morning and the performance is much better than twm or fluxbox. After launching it the first time, I couldn't see my menu bar, so I deleted my showeq.xml and re-launched and that fixed it. It must not have liked the font I had on there. I can't actually play EQ at work (wouldn't that be nice...) so I will test extensively tonight, but I'm very happy with the way it looks so far. Processor usage still goes through the roof for X when I resize the window and it redraws, but that is looking more and more like a video driver issue. I'd like to see someone try this who has an nVidia card, which is known to have better drivers. I will still try gatos when I get a chance, but just typing that word makes me cringe.

fryfrog, I can't help you with those errors, but try the Gentoo forums. Those guys are great, and pretty quick if your question isn't already answered. They're pretty new, so they don't have extensive knowledge archived yet, but the regulars are very friendly. You may run accross a few posts from a dedpoet in your browsing. :)

Edit: The menu bar issue is definitely a font issue. If I change the interface style to CDE, CDE Polished, of Motif, I lose it. I'm just running kdebase so far, so I don't have many fonts installed. I'll keep posting as I find more stuff to add.

Edit 2: Last edit for now. Those error messages I get when I launch seq are important afterall. I cannot change the menu options for the items that are listed from their defaults. i.e. I can't turn off nobank, can't turn on Use Stdout, can't pick a messages file, etc. Just an observation, but all the ones that have problems seem to be the onces that were recently added in the last few cvs updates.

genius
06-13-2002, 02:09 PM
Performance was "quirky" under twm, but I haven't eliminated bad ATi Radeon drivers as a possible cause yet.

Just a thought but Radeon has deep issues with using up a lot of your processor power. I have an 8500 and it thrashes my CPU whenever I play EQ this may be a driver issue I have yet to try the card in a Linux setup and see if that is what it is.

Gen|us

Dedpoet
06-13-2002, 02:22 PM
ATi is famous for being behind with their drivers in Windows, and even worse in Linux. In fact, ATi doesn't even make drivers for Linux, they are all 3rd party. There is a company called Xi Graphics (http://www.xig.com/) that makes bad-ass accelerated drivers for Radeons and lots of other cards, but they are expensive, and I'm not going to buy them. They don't list Gentoo on their list of supported distros, but judging by the compleatness of the list I'm sure they would work.

I got the Radeon 7500 in the laptop because it was the best mobile chipset out there for Windows, and since it's my travel machine for work, I use it for presentations (love that s-video out) and even games when bored at hotels. It's excellent for that, but Linux suffers. Maybe I could build one of those tiny Shuttle boxes for seq. Maybe someone will write a quality open source Radeon driver for Linux. Maybe monkeys will fly out of my butt...

Edit: Ratt, speaking of time savers - I have noticed "emerge rsync" can be buggy and crash out at times. If you have multiple machines to update, this could really suck. I recommend pulling down one of the portage snapshots from ibibilio.com and putting it on a cd-rw or a common network location. Then just untar it into /usr to create the new tree. The snapshots get updated every day and have saved me time.

Dedpoet
06-14-2002, 06:29 AM
I played for a few hours last night, and seq was working well. I only have 2 issues: terrible graphics performance, and the menu options listed above being inaccessible because of what I'm assuming are qt 3.0.4 incombatibilities.

I'm really going to work on the graphics issue this weekend. It acts almost like I have map line depth filtering on even though I do not - as I move the map lines disappear and reappear even if I'm not changing positions on the Z axis. I have to set the FOV circle to no background, otherwise it turns solid black and covers other map lines and spawns.

I'm sure the menu thing will get fixed sooner or later, I may even try to take a look at it this weekend. I'm not a C++ guy, but I have some C experience. Since the menu picks having the problems are the newest ones added, there may be a quick fix that will make them work like the others.

The graphics issue will take some doing. There are very few people it seems, who actually have the gatos Radeon drivers working on Gentoo but I did find one post on the forums that looks promising. I'd really like to see someone try this who has nVidia or other graphics to try to eliminate this video card variable. I'd be glad to help if anyone is ambitious...

On the positive side, overall system performance is spectacular. Boot time is about 1/2 of Redhat's, KDE 3.0.1 is extremely fast, seq is decoding almost instantly in zones that I had some troubles with in the past. You pay a price in compile time with gcc 3.1, but the performance gains are significant. I am a happy Gentoo convert.

-Ded

Zaphod
06-14-2002, 08:21 AM
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> MapMenu::toggle_spawnPoints(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::set_interface_Font(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::set_interface_statusbar_Font(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::toggle_interface_SavePosition(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::toggle_interface_UseWindowPos(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::toggle_interface_UseStdout(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::toggle_interface_NoBank(int)
QObject::connect: Incompatible sender/receiver arguments
QSignal::signal(const QVariant&&) --> EQInterface::select_interface_FormatFile


These warnings are important and all effected menu items will not work. From these warning it looks like you somehow didn't apply the patch I put up to your Qt 3.0.4 sources since that is exactly the problem it fixes. Make sure you did and rebuild.

Under Qt 3.0.x I wouldn't recommend using the original SpawnList but would recommend you use SpawnList 2 due to performance issues in the Qt 3.0.x QListView implementation.

I haven't seen the particular performance issues that you mentioned on my ATI All-in-Wonder Radeon that I'm running on my linux box (XFree86 4.1.0 using the accel ATI|Radeon driver, the default setup RedHat 7.2 gave me) with ShowEQ 4.2.x using Qt 3.0.4 and both compiled with Gcc 3.1. I'm running a full install of KDE 2.2 as my desktop. With the map zoomed out to around 1024x768 on a 1280x1024 screen I rarely see the CPU of my AMD Athlon XP 1800+ (running at 1.533GHz) go above 1.9% and is typically under 0.2% CPU (using SpawnList 2). If I use the old SpawnList in an active zone my CPU will frequently go up to 4-6%, however, due to the QListView issues.

What version of X are you currently running? Are you sure your actually using the accelerated driver? Also, did you make sure to compile DRI support into your kernel?

Enjoy,
Zaphod (dohpaZ)

Dedpoet
06-14-2002, 09:16 AM
Hmmm, I could have sworn I applied that patch. I know because I did it manually since it was just adding a 'p' to one line of code. Maybe I fat fingered and didn't save the changes or something. I will patch it and rebuild as soon as I can.

I am using X 4.2.0, Qt 3.0.4, and the Seq cvs from yesterday (not the newest one today) all built on gcc 3.1. I agree with you that it may be a DRI issue from the reading I have done this morning. I do have DRI compiled in, and have read confliciting reports about some people having it built in and others as a module. I don't recall which way I did it, but will check later today. There are a few more things to try that I gleaned from the Gentoo forums:

~ Pass "agp_try_unsupported=1" to the agpgart module
~ Run "opengl-update xfree" (Gentoo specific)
~ emerge svgalib (Gentoo specific)
~ emerge glut (Gentoo specific)
~ Uncomment the AGPMode option in XF86Config and set to 4
~ Add "DefaultDepth 16" to the Screen section in XF86Config

If these don't do the trick, there are always the gatos drivers, and the dri Sourceforge project to play with.

This is what I get for supporting the under-dog and not getting a GeForce2 Go in my laptop :) Thanks for the suggestions, Zaphod. I will bang my head against this tonight and tomorrow.

Dedpoet
06-15-2002, 10:15 PM
This will be my last update to this thread, as I seem to have come to a dead end...

Seq compiled against Qt 3.0.4 with Gcc 3.1 on Gentoo does, in fact, work very well. Once I applied Zaphod's patch to Qt and rebuilt, the startup errors went away and all menu options worked. Zaphod mentioned below that Qt 3.0.x may have issues with the original spawnlist, but I ran for several hours and didn't see any problems (I prefer the original spawnlist to the new one).

The Mobile Radeon 7500 in my Dell laptop does not work very well with Gentoo, however. I spent quite a bit of time on this, and couldn't get it working well. I am using the accelerated driver; I have DRI, radeon, and apggart compiled into the kernel; and 'glxinfo' reports DRI enabled. 'Glxgears' even reports > 2500 fps, which is very good - but I can't see the graphics in its window unless I move it around, then it crashes my window manager.

This graphics problem is causing map lines in Seq to "blink" in and out as I move through zones, especially when zoom is not set to 1x. Its useable but pretty annoying. I read quite a bit of information on getting Radeon cards working under various flavors of Linux, and it seems like each person who has pulled it off did it differently than everyone else. I'm sure Xig's drivers would work (they list my laptop model specifically), but I'm not going to pay $99 for them.

I'm going to be out of town all next week, but when I get back I will try this again on a desktop system that does not have an ATi card in it. nVidia has downloadable acclerated drivers for Linux and I expect to have better luck with that setup.

If anyone gets motivated to try this on non-ATi video before I get back, I would be very interested to see results. I hope my frustration helps someone else out. :rolleyes:

-Ded

fryfrog
06-16-2002, 06:30 PM
i run gentoo on 2 systems, 1 duel celron 366 and 1 p2 233. both have tnt2 cards and both work just fine.

Zaphod
06-18-2002, 09:11 AM
ok, an interim solution for those experiencing problems with ATI Radeon cards under XFree86 4.2.0 (and possibly 4.1.0).

In your XF86Config-4 in the "Device" section for "ATI|Radeon" insert the line:
Option "NoAccel"

which should end up looking sorta like:

Section "Device"
Identifier "ATI|Radeon"
Driver "radeon"
BoardName "Unknown"
Option "NoAccel"
EndSection


This should radically reduce your CPU usage. On an AMD Athlon XP 1800+ I saw CPU usage of the X process drop from 55% to less than 4% with a small map window. Yes, that is right, turning off acceleration improves the performance. Why, because both the DRI and MMIO acceleration code is screwed up in a way that happens to hit SHowEQ's map (even if we literally aren't drawing anything). I'm currently delving into the details.

Enjoy,
Zaphod (dohpaZ)

Dedpoet
06-18-2002, 09:54 AM
/cheer Zaphod!

I'm currently out of town, so unable to test with a running EQ session, but this did resolve my issue of disapperaing lines on maps when not at 1x zoom. I won't be able to really test until next week, but it looks like this is a winner.

Of course, glxgears now runs at 1/10 the speed that it was with acceleration on (200 fps rather than 2000), but I don't use this machine for Linux gaming or any other intense 3D application.

Thanks for your diligence, Zaphod. It really is appreciated.

-Dedpoet