Jump to content

Horrible framerates on Linux (Ubuntu), HORRIBLE!


Recommended Posts

The problems have been going around for a year or so. And haven't intensified though. I went over to Linux for various reasons, One pro for Linux players in KSP is that it crashes less often, or almost never. This is true. KSP crashed a horrible amount of times on my old Windows computer and have crashed maybe twice or 3 times on linux which crashes were actually explanatory due to excessive memory usages. Ah yeah, you can use many many more mods.

So I'm very happy about that.

What I'm furious about is the framerate. And I'm talking about my framerate opposed to others. And I'm not talking about the default framerate here. That means if I launch a 50-100 part ship the framerate is about as good on my previous windows build and it has very playable FPS.

Max physics Delta time per frame is already at 0.03.

Now I know many of the videos out there with 500-1000 part ships are recorded in slowmow and sped up with editing software, and these people get 1-2 frames per second in real life seconds maybe 5. Videos like these for example.

https://www.youtube.com/watch?v=mrjpELy1xzc

I get that framerate aswell, but I get it with 250-300 part ships. This forced me to play KSP in a kind of playstyle that is by launching low part count vessels, doing alot of docking for fuel transfers to get my duna, jool and other interplanetary missions working whereby I'd like to mine ore and actually build colonies and stuff. Which is hard because all my surface and orbit vessels should be spaced outside physics range for me to not get redheaded.

All my FPS issues are due to part count.

I love realism, I love RO/RSS, and I like mods using large large fuel tanks just so I need less of the same part to lower the count.

But I've reached a point right here and right now where I would not be ashamed to see a new option whereby you can test your vehicle for mission specific physic calculations like re-entry and stuff and if a mission specific maneouvre accomplishes all the physics challanges that I could turn of Physics calculations all together just so I can play this game for fun (whereas fun is the eventual goal of this game, right)

I spent the whole week trying to create a 4 seat Eve ascent vehicle that can operate from 1km surface elevation to orbit. It has 250 parts with ladders, parachutes etc incorporated. I got 5-10 fps in orbit. I thought, Oh no, It still needed airbrakes, heatshield, maneouvring rockets, fairing, and the actual rocket to launch it from the KSC. So I build my heatshielding, fairings, airbrakes and maneouvring rockets to test a design that would get it to aerobrake at eve. I used Physics time accelerating and on rails time accelerating as much as I could to take me through the painfully slow framerate situation and it took me a full day (with several re testing) just to manage a simple heatshield design where FPS dropped down to litteraly 2 FPS with the physics delta time frame per second to max while it aerobraked through the atmosphere. With heatshielding, fairings, maneouvring rockets that initial 250 part count went up to 300.

I think we can safely assume that with the necessary part count to lift that 200ton behemoth into orbit with conventional parts it's going to be atleast well over 500 parts. That ís absolutely unplayable. I already setup my mission profile to send the eve ascent vehicle to eve first and then get the kerbalnauts there. I would love to one day submit a Eve attempt in the challanges forum for example as for this case. But I always get to demotivated to attempt a video for it because it takes days with hyperedit to test simple aerobraking designs, ascent rocket designs all under 5 fps and I would have to slow down time so much for making a KSP video it would take atleast a day if not many days to capture anything and all without having fun in terms of gameplay.

For all these performance reasons I'm inclined against my own will to cheat the game engine and have occasionally posted threads on the forums here, one not so long ago as I recall to edit physics calculatable settings just to improve framerate, and I get the undertone in peoples replies that this would be a cheat and I should not come here to ask these things, which I don't even want to but my performance issues are so devestating to having fun in this game that I feel I'm forced to use these meassures. Things like tweakscale to reduce amount of engines and procedural fuel tanks are all meassures I'm forced to use to reduce part count and promote playability.

Which is not a playstyle I want perse but am forced to. And it's also the reason why I never posted a mission challenge in the challenges subforum as that's usually stock only and in order to compete to the top of the challenge tables you usually require the biggest of ships, which any part of my hardware of software doesn't allow.

That's the last bit I want to add to this, physics calculations for earodynamics. It's fun with a 50-100 part rocket/spaceplane, but beyond that it's hell.

I'd say, thanks for all the attempts at realism, which it isn't because you would need FAR for that (ironic) and alot less thanks for ruining playrate and chance of having fun with neccesarily big ships for a planet one whishes to takeoff from that you have put into your own game. Even for people with more regular performance digits on the FPS gauge getting a Eve return vehicle especially for multiple kerbals on and off the service is not so much a design challenge but a testing your nerve kinda thing in how much frames one is willing to allow to process through time.

Sounds like a RANT to squad!? Never!

I'm just blowing off steam and I'm the one that fails, and I know that. I love squad, and this is the best game I ever played, and that can only be developed by the best of producers and clearly this framerate issue is more of a personal problem then it may be for everybody else.

I tried all the different settings combinations for graphics in the KSP settings menu.

I've used like all the available working propriatary drivers for my ATI HD 7850 videocard.
I've read ATI videocards and linux in general thus Ubuntu do not work well together. And one should buy a Nvidia card.

Maybe that's the short reply I'll get, get a new videocard!!

I don't get that! I've read a reply of someone some time ago as I was in the hunt to solve my problem on this very forum who used a 3th generation ATI HD grapics card, one from the  low budget segment.

Are ATI linux drivers for my specific graphics card so badly supported (or not at all) that a videocard 4 ATI HD generations ago from a low budget range (whereas mine is a medium/high budget range) and 3 years newer outperforms it?

Or are there more forces at work here.

What I also don't get is that my framerate drops with part count and more so when it has to deal with physics calculations, thus Delta changes, aerodynamics and just alot of parts here and there.

Thats the business of the CPU, not the graphics card. I'm not a IT man but that's basically how it has sinked in to me over the year when it comes down to KSP.

The videocard doesn't do physics calculations.

But if it does, please inform me about it.
But if it's the CPU thats at fault then I'm still scratching my forehead. Its a 3570K 3,4 ghz intel ivybridge that I even overclocked to 3.9 ghz.
On Ubuntus system monitor while KSP is running none of the CPU cores ever get close to 100%

Hell, I can't even tell which of the CPU cores KSP is using. Mabe there lies the problem! Shouldn't KSP completely utilize the processing power of 1 CPU core to 100%

If that's the case then one of my CPU cores should read 100% while ksp is running. It doesn't.

I just checked this and the highest one of the cores jumped at is 58% and the other cores are processing at 21 through 58% at the time of monitoring.

By this time you might wonder, how about other games?

Well, I don't play many games anymore these days, my real and only occasional hookup is KSP. But I did played some battlefield alot on the same computer when it had windows on it and it runs fine.

Because I'm a only 1 year linux user I don't yet know all the ins and outs which are near infinite when it comes down to linux. But I never gotten the information about my framerate issues.

I read tons of usefull information on the Ubuntu One forums and even open a few questions there myself in hopes for a solution to this specific KSP problem.

Where they bash ATI and Ubuntu combinations and recommend a Nvidia card, which reminds me of what I said earlier in this thread, KSP is not graphics card intensive. I mean, the ATI HD7xxx proprietary drivers for Ubuntu must be really really crappy if they're causing these excessive framerate issues.

I'm willing to believe that it's the fault of my graphics card, but how do I know for sure. Are there other linux or preferably ubuntu users out there that have experienced similar bad results with ATI drivers?

And did you move over from one Linux distro to another and got better results??

 

I hope I made my point clear, and that some of you have experience with similar issues and what could be done to solve it.

 

Thanks.

 

 

Edited by Vaporized Steel
Link to comment
Share on other sites

Yes, ATI cards do have a really excrementsty drivers. Even windows ones are not exactly great, so this is not really surprising. Supposedly there are some hw/drivers combinations that work well, or can be kicked to shape if you know your way around X. Many don't. I can only advise you to google around your card model and drivers version and see what comes up. I'm sorry I cant help you more but this is sole reason why I stay away from ATI/AMD ever since I moved to linux.

Other then hassling with drivers, few more things can be done. First, disable window manager eye candy. Google found this for me: http://itsfoss.com/speed-up-ubuntu-unity-on-low-end-system/

You can top that with avoiding unity altogether and using some simpler window manager like twm or maybe xfce. With proper kernel, drivers  and X stack this wont be of much help, but if windows manager is behind this, it will show. Thing here is, if you run simple (or as they say, "unaccelerated") window manager like twm, game can draw directly to hardware (or window, which should go to hardware shortest way possible). Fancy window managers like unity have to grab window content, turn it into texture and apply their own fancy stuff (transparency, shadows or other eyecandy) which should not take much "if drivers can do such operations properly"... If you want to try it, have some experienced penguin herder at hand or PM me.

Other thing worth a try would be using builtin intel GPU. Like you said, KSP is not very graphics intensive :-) It will run just fine and intel have about best linux drivers of them all, with kernel modeswitching, proper xrandr and all that. Like previous, this is not a solution but could help you isolate the problem.

Also, you will need a way to measure you success. For that, fire up terminal and run glxgears, it will show simple animation and measure FPS. Note it is very simple test, not true benchmark. More FPS in glxgears does not translate to that many more FPS in game, but it tells you progress. Other program that might come handy is glxinfo. It should print several pages describing your GPU capabilities. That, or just a few lines including dreaded "direct rendering: no" which means you screwed up and your driver (or more precisely, X server) is not using your dear GPU at all.

As for CPU labor, no, you hardly ever  see single core actually go to 100% with KSP. CPU Core load is measured during time interval and in that time kernel can and will move tasks between cores as it sees fit. for example, say you have 1 second measurements, kernel will put process at one core and after 500ms push it to other core, ergo you will see two cores having 50% load. But top will show that process ran at 100% alloted cpu time, which is correct. (This gets more complicated with threads, but in KSP other threads are negligible compared to physics computing, essentialy making it behave like singlethread). Moral of this to use top (or htop or whatever that measures processes and not cores). 
 

Link to comment
Share on other sites

2 hours ago, radonek said:

Also, you will need a way to measure you success. For that, fire up terminal and run glxgears, it will show simple animation and measure FPS. Note it is very simple test, not true benchmark. More FPS in glxgears does not translate to that many more FPS in game, but it tells you progress.

All I get from glxgears is a frame rate that is the same as my monitor refresh rate.

You need something that can get data from the osd layer directly for proper in game rates.

Link to comment
Share on other sites

31 minutes ago, v8Dave said:

All I get from glxgears is a frame rate that is the same as my monitor refresh rate.

You need something that can get data from the osd layer directly for proper in game rates.

Mea Culpa. It even prints message to that effect. But google says it can be avoided: "__GL_SYNC_TO_VBLANK=0 glxgears" for nvidia blob and "vblank_mode=0 glxgears" on intel and ati.

 

Link to comment
Share on other sites

Holy wall of text.

Anyway, I think the problem is KSP version 1.0 was a big step backwards in terms of game performance. The combination of the (reasonable) new aerodynamics, the (overengineered) thermal system, and the extended physics range all mean that KSP now lags worse at lower part counts than it did back in 0.90. Even 0.90 with FAR and DRE ran better than 1.0.5 does now. Things like that Mars Ultra Direct video were done on previous KSP versions that ran less badly.

That said you *should* do better than you are. I run a Core i3 6100, GTX 750 Ti, Debian Linux, and I can maintain 10 fps on a 600 part ship. You have a similar CPU as far as running KSP goes. Two factors could explain the discrepancy:

Game settings. The aerodynamic effects tank framerate for me so I usually put them on minimum. If you're actually GPU-limited then obviously sending the detail right down will help. Even if you're "CPU-limited" like most people playing KSP, graphics settings still impose some CPU load.

Mods can sometimes seriously hammer your fps, I've seen an 80% drop from a buggy mod before now - that means that what should be 25 fps will be running at 5 fps just because you installed or even just updated one of your mods. I've also seen a serious hit from Smokescreen, which is a part of Realism Overhaul. On the other hand I've not seen more than about a 5-10% hit from FAR, but of course if several mods each cost you 5% of your framerate it starts to add up to big damage.

 

Link to comment
Share on other sites

4 hours ago, cantab said:

Mods can sometimes seriously hammer your fps, I've seen an 80% drop from a buggy mod before now - that means that what should be 25 fps will be running at 5 fps just because you installed or even just updated one of your mods.

Good point... Try using Exception Detector to see if there is anything throwing errors...

Link to comment
Share on other sites

9 hours ago, radonek said:

Yes, ATI cards do have a really excrementsty drivers. Even windows ones are not exactly great, so this is not really surprising. Supposedly there are some hw/drivers combinations that work well, or can be kicked to shape if you know your way around X. Many don't. I can only advise you to google around your card model and drivers version and see what comes up. I'm sorry I cant help you more but this is sole reason why I stay away from ATI/AMD ever since I moved to linux.

Other then hassling with drivers, few more things can be done. First, disable window manager eye candy. Google found this for me: http://itsfoss.com/speed-up-ubuntu-unity-on-low-end-system/

You can top that with avoiding unity altogether and using some simpler window manager like twm or maybe xfce. With proper kernel, drivers  and X stack this wont be of much help, but if windows manager is behind this, it will show. Thing here is, if you run simple (or as they say, "unaccelerated") window manager like twm, game can draw directly to hardware (or window, which should go to hardware shortest way possible). Fancy window managers like unity have to grab window content, turn it into texture and apply their own fancy stuff (transparency, shadows or other eyecandy) which should not take much "if drivers can do such operations properly"... If you want to try it, have some experienced penguin herder at hand or PM me.

Other thing worth a try would be using builtin intel GPU. Like you said, KSP is not very graphics intensive :-) It will run just fine and intel have about best linux drivers of them all, with kernel modeswitching, proper xrandr and all that. Like previous, this is not a solution but could help you isolate the problem.

Also, you will need a way to measure you success. For that, fire up terminal and run glxgears, it will show simple animation and measure FPS. Note it is very simple test, not true benchmark. More FPS in glxgears does not translate to that many more FPS in game, but it tells you progress. Other program that might come handy is glxinfo. It should print several pages describing your GPU capabilities. That, or just a few lines including dreaded "direct rendering: no" which means you screwed up and your driver (or more precisely, X server) is not using your dear GPU at all.

As for CPU labor, no, you hardly ever  see single core actually go to 100% with KSP. CPU Core load is measured during time interval and in that time kernel can and will move tasks between cores as it sees fit. for example, say you have 1 second measurements, kernel will put process at one core and after 500ms push it to other core, ergo you will see two cores having 50% load. But top will show that process ran at 100% alloted cpu time, which is correct. (This gets more complicated with threads, but in KSP other threads are negligible compared to physics computing, essentialy making it behave like singlethread). Moral of this to use top (or htop or whatever that measures processes and not cores). 
 

 

Yeah, I read this about the ATI cards. Tried many driver versions, even ones that send me straight to the Grub boot loader to reload the open source drivers just to test each of them. In the end only a few of these drivers actually work and the performance is all similar. I don't know how to go beyond the X as I used official drivers by AMD but if you have supply of info to get me in a general direction I would really appreciate that.

Thanks for the link. What about window manager eye candy? I never used window manager and I use a default theme. As for other window managers, You suggest 2 options. Which one would you think is better in user friendlyness. I heard some of the window managers are different, perhaps more difficult to navigate with then others. Anyhow it has always been on my list to test different ones but never got around to know which one would be best suited.

 

Furthermore my motherboard is GPUless. So taking the ATI card out is not really a option. I wished I had a spare motherboard around. And now that I think about it I might buy one from a mate that fits on my hardware. But then I could just aswell buy a secondary Nvidia card.

GLXgears shows (v)

12205 frames in 5.0 seconds = 2440.918 FPS
11842 frames in 5.0 seconds = 2368.322 FPS
11883 frames in 5.0 seconds = 2376.436 FPS

I Think it only wants to monitor the Desktop framerate, I opened the terminal when in the active KSP process which I would think to force it to monitor the in game fps. It doesn't. How do I make it monitor in game framerate?

glxinfo loads alot of pages of text so no driver failure.

Thanks for explaining how the cpu cores utilizes each other in ubuntu. I didn't know that but I had monitored this behavior on many occassions but now I understand how that works.

I will give Htop a shot and expect a complete load  on the KSP process. If there is magic at work here and it doesn't I´ll report it.

 

5 hours ago, cantab said:

Holy wall of text.

Anyway, I think the problem is KSP version 1.0 was a big step backwards in terms of game performance. The combination of the (reasonable) new aerodynamics, the (overengineered) thermal system, and the extended physics range all mean that KSP now lags worse at lower part counts than it did back in 0.90. Even 0.90 with FAR and DRE ran better than 1.0.5 does now. Things like that Mars Ultra Direct video were done on previous KSP versions that ran less badly.

That said you *should* do better than you are. I run a Core i3 6100, GTX 750 Ti, Debian Linux, and I can maintain 10 fps on a 600 part ship. You have a similar CPU as far as running KSP goes. Two factors could explain the discrepancy:

Game settings. The aerodynamic effects tank framerate for me so I usually put them on minimum. If you're actually GPU-limited then obviously sending the detail right down will help. Even if you're "CPU-limited" like most people playing KSP, graphics settings still impose some CPU load.

Mods can sometimes seriously hammer your fps, I've seen an 80% drop from a buggy mod before now - that means that what should be 25 fps will be running at 5 fps just because you installed or even just updated one of your mods. I've also seen a serious hit from Smokescreen, which is a part of Realism Overhaul. On the other hand I've not seen more than about a 5-10% hit from FAR, but of course if several mods each cost you 5% of your framerate it starts to add up to big damage.

 

 

I have to admit, I could have made it shorter and clearer.

The thing about the heavier load on physics in 1.0 is basically why I've come to realize I have to adjust my performance somehow. Especially for some reason because of 1.05.

I still have a 0.90 and 1.0 install that perform very very bad aswell but somewhat better then the latest version. So I get similar results like you but with horrible average framerate on both versions 0.90 and 1+. One slightly worse then the other.

The wall of text made you miss HD7850. I don't think it's limited.

Like I said in the OP I read someone with a 3th generation ati HD of the low budget segment outperform my mid/highend Hd x7000 series so the amount of Flops produced is clearly no indicator to which card is better or which one is floppier :confused:

This is only with KSP though, as far as my experience with games go.
Stock ksp, modded KSP, it's all the same experience wise.

And I will use Radoneks suggestion to use htop and report its results but when I say 2 FPS its no overexaggeration.

Visual enhancements mods without necessary physics calculations is 60fps. The higher the part count the less fps. I get 5-10 fps with 200-250 part ships and up to 1-2 fps (continuously) in high physics stress situations (re-entry), whether I got stock installed or with 10 or 20 other mods.

Edited by Vaporized Steel
Link to comment
Share on other sites

41 minutes ago, Vaporized Steel said:

1-2 fps (continuously) in high physics stress situations (re-entry)

In my experience the problem in re-entry is down to the flashy flame effects, they're actually quite demanding on both GPU and CPU. (It's actually a fur shader making the effects, and hair and fur are well known as very demanding to render, so it's no great surprise considering).

17 minutes ago, Vaporized Steel said:

Htop occassionaly reports 115% CPU usage for ksp.x86_64. How can it be over 100 :0.0:
I thought there was no multithreading support as of yet.

On the contrary, KSP has had multithreading for a long time. It's just that most of the work, including all the physics calculations, is done by a single thread. And top uses a scale where "100%" means 100% of one core, or the equivalent of that.

Link to comment
Share on other sites

Right, I get it now. I had on previous versions and on windows alot of spikes and overal lower fps during re-entry even before aerodynamics/heating was introduced. Still theres not alot of re-entry fire added i.e. my eve ship thats encapsulated in a fairing and the only re-entry fire animation displayed is that of the heatshield.

Isn't it fair that if a ship thats encapsulated in a fairing ignores some parts of the physics calculations. The fairing is the aerodynamic surface. And it hosts around 85% of the parts during my re-entry test. It still calculates G forces ofcourse. And the FPS is painfully slow when it only does that, but there are definetely more calculations going on during re-entry. But if it does so for encapsulated parts aerodynamics I think that is stupid.  

I probably test that tommorow with the aerodynamics overlay but ill probs get a yes/no answer before then.

gtg to bed now.

Link to comment
Share on other sites

Anyway, just in case I might think about buying a nvidia graphics card. Which one would you recommend for Ubuntu and KSP combinations. Usually I don't have to ask that particular question as I'm very well knowledged on what card is better which usually ties to price. But since with linux it's more or less about drivers and compatibility. Anyway, my budget is about 150EUR (165USD)

Maybe theres a specific card that yields very good results on your end, I'll be happy to hear your recommendation.

Link to comment
Share on other sites

13 hours ago, Vaporized Steel said:

I never used window manager
...
Which one would you think is better in user friendlyness. I heard some of the window managers are different, perhaps more difficult to navigate with then others.

If you have windows you can move about the screen, you're running a Window Manager - I assume the one that comes with whatever Desktop Environment you're using. (Which is?)
Most of the time (again dependent on what DE  you're running), installing a new WM will give you the option to use it at the login screen. I'm tempted to suggest trying openbox, it's not to weird, but there are far too many options to cover them all.
That said, I see absolutely no performance difference running in KDE/KWin with full shiny vs. bare X with nothing but an xterm.
 

13 hours ago, Vaporized Steel said:

GLXgears shows (v)

...
How do I make it monitor in game framerate?

glxinfo loads alot of pages of text so no driver failure.

PSA: glxgears is not a benchmark. It's an old GLX demo, and it'll give you some indication that GL is working, nothing more. That it is a benchmark is a persistent myth.
It doesn't monitor desktop framerate, and you can't get it to monitor ingame framerate either - the only thing it "monitors" is itself.

To see KSP framerates:
Ingame: GCMonitor, ksp-devtools or the built-in debug menu.
Overlay: voglperf or GLXOSD.

If you want some kind of general GPU benchmark using modern features, you could try one of the Unigine demos.

'glxinfo' will always dump a huge wall of text, even if you're stuck with software rendering. Filter it to the relevant bits with grep:

glxinfo | egrep 'direct | vendor'

If you get "direct rendering: Yes" and the vendor strings all match, you've got GPU GL acceleration.

For GPU recommendations, I haven't bought a new card in some time but my GTX680 still handles KSP without issue. In fact I'm pretty sure it's overkill. I haven't had any problems with Nvidias Linux driver in some time (years).
AFAICT, my performance issues (it runs ok, but it could be far better) are all CPU/physics engine. And barring any huge flaws in AMDs driver (not at all unheard of mid you) I suspect yours are too.

 

Edited by steve_v
Better bench than glxgears.
Link to comment
Share on other sites

With grep it says "yes" and the vendor strings match to ATI. So that seems ok.
The GTX680 is definetely within that budget, so it's on my current buy list. But I'll await other peoples experiences with their graphics cards if they're willing to post it.

I think I must suspect it's very likely that the AMD drivers are atleast part of a problem here if not the one and only problem. Hopefully I don't miss judge the problem and the performance problems are due to anything else.

I'm out to go celebrate the revolution of earth around the sun today and I wish everyone the best for tonight and thereafter. BB!

Link to comment
Share on other sites

11 hours ago, Vaporized Steel said:

I never used window manager…

You sure did, all the time in linux :-) It's program responsible (among other things) for moving windows around and drawing window decorations (border, titlebar with buttons).
 

13 hours ago, Vaporized Steel said:

As for other window managers, You suggest 2 options. Which one would you think is better in user friendlyness. I heard some of the window managers are different, perhaps more difficult to navigate with then others. Anyhow it has always been on my list to test different ones but never got around to know which one would be best suited.

XFCE looks a lot like good'ol Windows 95 - simple, but usable. twm is pure window manager - no icons, no panels, no desktop, no dependencies, no excrements… it is about as small and simple as wm can get. making it reliable fallback. Also, you will not like it :-p If you want to try different desktop environments, you are looking for KDE and Gnome projects. But these are big, fullblown desktops. But for merely testing composition-less desktop, twm is best option (I just learned that XFCE recently got its own composition which you would need to disable). Just fire  up xterm, run glxgears or KSP to see if it helps and get out.

14 hours ago, Vaporized Steel said:

I Think it only wants to monitor the Desktop framerate, I opened the terminal when in the active KSP process which I would think to force it to monitor the in game fps. It doesn't. How do I make it monitor in game framerate?

glxgears measures how fast it can render rotating gears in its own small window. Like I said, its not benchmark, value itself is kinda nonsensical. KSP ingame FPS meter is somewhere in cheat menu.


 

14 hours ago, Vaporized Steel said:

Htop occassionaly reports 115% CPU usage for ksp.x86_64. How can it be over 100

Like I said above, it gets more complicated with threading :-) You have one core computing physics all the time and some other threads (i.e. sound emitting) running parallel on other cores.  It really depends on what you want 100% to be - single core at full steam or all cores utilised? top & co. takes former approach (because it makes more sense with singlethread processes, which are still most common).


 

Link to comment
Share on other sites

Thanks for explaining it all. And yes the over 100% usage is what you explained and which makes sense after cantab confirmed that there is multithreading. I was wrongly informed that there wasn't.

So the readouts are completely normal and that seems to really rule out the CPU. I am interested in tweaking ubuntu with different window managers and I'm going to look between xfce and twm to see if I can save system resources that way. It may have no noticeable effect in the end but I could always try it. And if TWM can draw the game unaccelerated as you say to hardware and that is a problem solution I would really prefer it over buying a new GPU. By a quik look of mine I would consider to try TWM first, I'm gonna give it some work after the holidays and if I stumble across any problems in the process in terms of drivers and dependencies or install in general I will PM you for assistance.

If that does not improve performance I will buy a Nvidia card,
currently I play only KSP, that might change, and I read the performance issues with AMD cards are devestating with any graphics rendering within unity. So eventually I might have to buy a nvidia card anyway.

 

Link to comment
Share on other sites

You are making it sound like brain surgery :-) I proposed it because its fast and easy way to test possible (but not most likely) cause. You "apt-get install twm", logout, log into twm, fire up KSP and see result. Five minutes, tops. If it wont help, you'll know soon.  If it helps, you will go back to unity anway, and look for knobs to turn (this is where glxgears comes handy - push button, see if there is noticeable effect in five seconds, fire up KSP only if it looks promising). You  really don't want to use twm long-term. I know that firsthand, did it once (to run Doom3 on heavily underspecced machine). My best guess is it will give you some fps, but main problem is with driver.
 

Link to comment
Share on other sites

I already tried Xfce, I'll do that for twm aswell.

in Xfce ksp runs still as bad.

Iĺl try TWM this time and see if that does better.

I tried out the window manager of TWM. Very minimal interface I must say. When I run KSP on TWM however, the framerate is actually alot worse. Now I get 2 FPS on the launchpad. This can be due to settings possibly but on Xfce it ran about as bad as it did on unity.

I ran Glxgears in TWM and it shows about on average 7200 fps, and about 6800 fps when Ksp and the big rocket is loaded.

Thus far my eyes are on the Geforce GT 740, maybe 750. But I think the GT 740 is more then enough. Anyway, they seem well supported by the looks of it.

Edited by Vaporized Steel
Link to comment
Share on other sites

The big issue from what I've read in the past few months in my KSP career is that physics in Unity4 is single threaded, and more parts = more calculations. The 1.1 version using Unity5 which has multithreaded physics theoretically should help this issue out. There are threads here where people using nicer rigs with Windows are getting low framerates with only 100 parts, I'd say you are doing pretty good. The 2 solutions: get an insanely fast processor, or wait until 1.1 comes out and hope that this issue gets remedied. Actually there is a third: use less parts :D

Link to comment
Share on other sites

I wonder if wayland and compton will help make KSP smoother, or even if KSP will run at all ...

Actually, as you're using ATI graphics how about trying that new radeon driver that has the powerplay patches, it can dynamically reclock ATI cards, which wasn't possible before.

Link to comment
Share on other sites

Well Sal, I came here to say that I had ordered a new graphics card (Nvidia Gtx 750 TI) which I got installed at the moment and have just tried out playing ksp for a couple of minutes. Maybe if I got time and the enthusiasm I will still stick in the AMD card and test that new driver you mention.

Anyway...

The performance rise is phenomenal. KSP can run my 300 part vessel with only slightly reduced physic time frame with a average 10 fps during re-entry phases etcetera. Versus the 1-2 fps with heavily reduced physics time on the AMD card.

This is with a propriatary Nvidia driver and I am yet to test results between driver versions and I might still overclock the CPU a bit, so I'm very happy with the recent developments. The game runs about as good as on my old windows build where the old AMD card was used.

And while I still think AMD creates good graphic cards I will advice every linux user to sell theirs and buy a Nvidia.

 

Link to comment
Share on other sites

19 hours ago, Vaporized Steel said:

And while I still think AMD creates good graphic cards I will advice every linux user to sell theirs and buy a Nvidia.

Yeah, AMDs Linux driver is a turd, it has been for as long as I can remember.

Link to comment
Share on other sites

Well, nvidia proprietary blob is pretty ugly digestive product too - kernel module was repeatedly called out by Linus as crappy, reinventing pieces of X protocol does not inspire much confidence, nor does internal openGL library… However, nvidia got one key thing right - maintenance. They follow kernel and X development and work to have a well working turd. And this will IMO decide fate of AMD's great new opensource driver.

Link to comment
Share on other sites

13 minutes ago, radonek said:

Well, nvidia proprietary blob is pretty ugly digestive product too...

True enough, but, as you say - at least it works properly. Ugly, working code is infinitely better than any kind of not-working code.
Nvidias driver used to be pretty bad too, but at least they always have a release that actually works. AMDs track record on the other hand... summarily dropping support for older cards, with no 'legacy' driver available, failing to update their code for months and putting people in the position of 'downgrade the entire X.org stack or have no OpenGL' etc.
This lack of commitment to keeping up with the times, combined with the complete lack of drivers (not counting FOSS drivers, as not AMDs work) for other Unixes (e.g. FreeBSD) makes AMD graphics products a solid no-buy for me.

Link to comment
Share on other sites

@Majorjim Physics is computed on cpu, OPs problem is with GPU. 

@steve_v exactly. I believe one could find well working combination of ATI card and drivers, but I still stick with nvidia&intel because I am confident it will work with newer kernel or upgraded X for years. And my cynic self can see sudden driver opensourcing by AMD as an attempt to throw long-term support responsibility at some vague "community" and legalize their lack of commitment.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...