Linux distro testing issues

[holocronweaver]

////////////////////////////////
(Split out from OpenGL 3 testing topic in developers forum: http://www.ogre3d.org/forums/viewtopic. ... 34#p485934 )
////////////////////////////////

I have been resisting the urge to test out Lubuntu for some time now. Perhaps I should give in to the cravings...to help my fellow man of course.

Are you able to run Steam on Lubuntu 12.10? How about 3D games or 3D applications? If so, which?

[jacmoe]

/* off-topic: why anyone would run anything ending with 'buntu' is totally beyond me. Programmers ought to use Debian Sid: the rock solid and cutting edge stable OS.
And, yes: Steam is running happily here. */

[bvanevery]

Are you able to run Steam on Lubuntu 12.10?

Good question. I do have it installed, and I've browsed through available titles, but I don't believe I've downloaded or run any.

Jacmoe, as for your squeamishness about *buntus, the reality is that's where Steam runs now. It's the epicenter of the 1st wave of Linux trying to be something as a gaming platform. Canonical has ideological reasons for not being Debian, not the least of which is making proprietary NVIDIA drivers easily available to the end user. From a testing standpoint, it wouldn't shock me if something has gone wrong in my choice of somewhat fringe Lubuntu vs. a mainstream Ubuntu Unity desktop. But my Lubuntu desktop performs so much better, it's what I've done, and hardcore 3d performance head gamers might do similarly. So, I'll be adding Ubuntu vs. Lubuntu as a test permutation. As soon as I understand how it's all supposed to really be configured. If I'm really supposed to run "sudo Xorg -configure" from a tty, that's a consumer software disaster. Might not be hard to write scripts that detect such problems, so maybe such a wart is curable. This could very well be the real world of Linux platform fragmentation in action though.

[jacmoe]

What the fuck are you talking about?

This Debian box is running Steam.

Sudo xorg what?

The installation of Debian is every bit as smooth and polished as Ubuntu. Without the quirks and odd choices.
And since it is Sid, I don't have to build and install stuff to get the newest libraries/tools. I use the package manager.
This box is perfect for testing, IMO.

[holocronweaver]

/* off-topic: why anyone would run anything ending with 'buntu' is totally beyond me. Programmers ought to use Debian Sid: the rock solid and cutting edge stable OS.
And, yes: Steam is running happily here. */

Couldn't help yourself, could you? Well, neither can I.

I run Ubuntu mostly because I love Unity. Of all the Linux desktops I have tried, it is my favorite because it stays out of my way, has all the features I want built in, and is stable while still being aesthetically pleasing. It is like the Zenburn coding theme made into a desktop platform. It started out in a terrible state, but has matured quite nicely.

Beside Ubuntu I have been using Fedora for past two years, but about three years ago I went through almost everything I could find in the Linux top twenty. At the time nothing compared to the ease of use of Ubuntu, especially when installing across multiple machines from netbook to desktop to media PC. Everything mostly just worked with minimal finagling.

I admit I am concerned about the 'benevolent' dictatorship of Ubuntu by Canonical, which is why I make sure to occasionally try other distros from time to time. Perhaps I should give Arch and Debian a go as well as Lubuntu...

I think that coders ought to test their software on the major platforms first and foremost. Since Ubuntu is the #1 Linux distro (despite claims of distro watch), I think developing on it is a reasonable choice.

[holocronweaver]

@jacmoe: Since you are a moderator, please move this Linux distro discussion to the off-topic forum (or whatever is most appropriate) so we don't clog up the GL3+ thread. Er...assuming that is possible on phpBB from 2007.

[jacmoe]

Sorry for not helping myself.

I think Valve made the right decision to start with Ubuntu, simply because it's the most hyped Linux distribution.
But it is indeed possible to run Steam on Debian (the mother of Ubuntu).

Arch is probably a great distribution - and I did use it for almost a year.
It wasn't without frustration, though. So I dumped it for Debian Sid.
Simply because I don't have the time, nor the patience, to tinker - it should just work.
Ubuntu never gave me that either, because there are so many things you need to tweak (as a power user) - and then it breaks frequently. Of course, the dist upgrades breaks, but not only that: the maintenance updates also breaks from time to time..
With Debian Sid I dist-upgrade once or twice a week. Rolling release is great.

Sorry for the hi-jacking.

I will shut up and figure out what OpenGL I have installed now and help testing OpenGL 3+ instead of ranting about Linux distros. :p

[jacmoe]

@holocronweaver:
Great idea.

[jacmoe]

@jacmoe: Since you are a moderator, please move this Linux distro discussion to the off-topic forum (or whatever is most appropriate) so we don't clog up the GL3+ thread. Er...assuming that is possible on phpBB from 2007.

Hehe - no: we're not running phpBB from 2007 - that would be worse than a sitting duck! Don't worry.

[bvanevery]

Hrm, the thread title poses a false choice. I realize you may not have put much thought into the title when splitting this out. Testing of Linux distros should in no way be constrained. Rather, it's probably worth becoming aware of the fragmentary nature of the Linux landscape, and things to seek out when Ogre-specific testing and logs don't seem to be resolving a problem.

[jacmoe]

You are right Bvanevery - I think I confused testing with developing-on.
I deliberately use stock and vanilla Ubuntu (of all things ;p) as the first distribution I test on, using a virtual machine. Mainly to see if it installs and runs.
As one of a few reference distributions.
Fedora would be another, maybe?
OpenSuse?
Yup. you're right.
If you have a suggestion for a better title..

<edit> Done: topic title changed. </edit>

[bvanevery]

"Linux distro testing issues"

[Jabberwocky]

Whatever linux distros you decide to test on, make sure you include both 32-bit and 64-bit versions, especially if this is a closed-source pre-compiled binary. A 32-bit exe can't use 64-bit libs, and vice versa. So all the system libs your exe depends on probably won't exist in a mismatched exe / system scenario.

Ideally, you'll have both a 32-bit and 64-bit installer. For my game, this wasn't possible since I use at least one closed-source 32-bit lib (PhysX) which is not available as a 64-bit lib. So I could only make a 32-bit installer/exe.

If you have a 32-bit exe on a 64-bit system, installing the ia32-libs package will solve a number of the problems, but not all of them. Still, requiring that your users install additional packages may be beyond their tech savvy or patience limit, so you may want to include all the needed libraries along with your installation.

Apologies if this is sorta off-topic, but I've recently been porting my game to linux, and this stuff was a major headache, so I thought I might share some of the things I learned.

[bvanevery]

Whatever linux distros you decide to test on, make sure you include both 32-bit and 64-bit versions,

Why support 32-bit, now? What's the compelling case for that? Why not just force your game customers to use 64-bit Linux? I'm using a 6 year old laptop and it's 64-bit capable. I'm planning to force OpenGL 3.x as well.

Ideally, you'll have both a 32-bit and 64-bit installer. For my game, this wasn't possible since I use at least one closed-source 32-bit lib (PhysX) which is not available as a 64-bit lib. So I could only make a 32-bit installer/exe.

I wouldn't make that kind of proprietary lock-in choice. Generally the only proprietary code I'm interested in is my own.

Apologies if this is sorta off-topic, but I've recently been porting my game to linux, and this stuff was a major headache, so I thought I might share some of the things I learned.

Seems perfectly topical to me. And the thread is under off-topic, so who can complain?

[TheSHEEEP]

I agree that enforcing 64-bit is a non-problem nowadays. I haven't seen a 32-bit machine in years. We really need to get rid of that 32-bit stuff as soon as we can.
And with GCC on Linux, that is rather easy (-m64, if I'm not mistaken).

Wish it was that easy with GCC on Windows. Yeah, there is mingw-w64 or stuff like tdm-gcc, but both are for some reason painfully slow when compiling and even crash due to being out of memory. Normal (32-bit) MinGW has neither of these problems, heck it's even faster than MSVC.

I never tried any other Linux than Ubuntu. Will an application compiled on Ubuntu not run on Debian/Fedora (assuming all are 64-bit/32-bit)?

[bvanevery]

Wish it was that easy with GCC on Windows. Yeah, there is mingw-w64 or stuff like tdm-gcc, but both are for some reason painfully slow when compiling and even crash due to being out of memory. Normal (32-bit) MinGW has neither of these problems, heck it's even faster than MSVC.

I have an answer for that too. Don't ship on Windows. I figure I'll try to ride the leading edge of the uptick in Linux gaming. If I make money, then I'll consider porting.

I never tried any other Linux than Ubuntu. Will an application compiled on Ubuntu not run on Debian/Fedora (assuming all are 64-bit/32-bit)?

Linux itself has the Linux Standards Base, so I think things will run. I'm not up on those issues though. I do know that Debian distros don't follow the file system conventions that the standards tried to specify. Half the Linux universe thought the specification was dumb. This has been more of a build issue and library installation issue than an end user app issue for me though.

[TheSHEEEP]

Wish it was that easy with GCC on Windows. Yeah, there is mingw-w64 or stuff like tdm-gcc, but both are for some reason painfully slow when compiling and even crash due to being out of memory. Normal (32-bit) MinGW has neither of these problems, heck it's even faster than MSVC.

I have an answer for that too. Don't ship on Windows.

Yes, thanks, I will ponder that business strategy for a while

[Kojack]

Normal (32-bit) MinGW has neither of these problems, heck it's even faster than MSVC.

I assume I'm missing the "make it not suck" flag, because I'm doing a test build of ogre 1.8.1 (all deps, ogre stuff and samples) with mingw (32bit) and after 25min it's only 69% through, compared to under 2 min to finish in visual studio 2008.

Edit: Final time = 41min. Ouch. I assume something's wrong, it can't really be that bad.

[holocronweaver]

Normal (32-bit) MinGW has neither of these problems, heck it's even faster than MSVC.

I assume I'm missing the "make it not suck" flag, because I'm doing a test build of ogre 1.8.1 (all deps, ogre stuff and samples) with mingw (32bit) and after 25min it's only 69% through, compared to under 2 min to finish in visual studio 2008.

Edit: Final time = 41min. Ouch. I assume something's wrong, it can't really be that bad.

Are you compiling using multiple threads via the flag -j <# of processor cores>?

BTW, I usually use unity builds for MinGW on Windows. Speeds up compile time to just under a minute on my Intel i5-2500k. Oddly I have lots of compilation errors with unity builds on Linux using gcc.

[TheSHEEEP]

Normal (32-bit) MinGW has neither of these problems, heck it's even faster than MSVC.

Edit: Final time = 41min. Ouch. I assume something's wrong, it can't really be that bad.

No, it can't
No idea what you are doing wrong, though. Both take around the same time on my machine, using unity builds.

I also wasn't talking about Ogre here, but the applications I develop at work or at home. There, I noticed some real difference in compile speed.
Probably has to do with compile flags or something *shrug*

[Kojack]

Hmm, that's a bit better. Got it down to 4:08 using unity build and 12 jobs (I've got a hex core hyperthreaded cpu).

Actual execution performance: new instancing sample with no instancing (so it's just brute force), 2500 animated moving entities with shadows: 69fps with gcc, 82fps with visual studio.

Speeds up compile time to just under a minute on my Intel i5-2500k

What exactly were you compiling? I'm doing all dependencies (zzip, freeimage, freetype, ois, etc), all ogre plugins, all samples (total of around 56 projects). Freeimage alone takes 1:10 and ogre can't start until after that is done.

[bvanevery]

Actual execution performance: new instancing sample with no instancing (so it's just brute force), 2500 animated moving entities with shadows: 69fps with gcc, 82fps with visual studio.

With which renderers? Isn't that implicitly an OpenGL vs. DirectX benchmark? I didn't think MinGW was capable of linking correctly with DX11 redistributables. At least, maybe a year ago, I'm pretty sure it couldn't.

[holocronweaver]

Hmm, that's a bit better. Got it down to 4:08 using unity build and 12 jobs (I've got a hex core hyperthreaded cpu).

Actual execution performance: new instancing sample with no instancing (so it's just brute force), 2500 animated moving entities with shadows: 69fps with gcc, 82fps with visual studio.

There are many compile time optimizations you can do with gcc via flags that are probably automatically being applied with VS. Check what CXX_FLAGS are being applied in the makefiles (see flags here; the -O# optimizations are easiest). Also, make sure you are comparing the same builds and not mixing debug/release or OpenGL/DirectX.

What exactly were you compiling? I'm doing all dependencies (zzip, freeimage, freetype, ois, etc), all ogre plugins, all samples (total of around 56 projects). Freeimage alone takes 1:10 and ogre can't start until after that is done.

The build time I stated is just for building Ogre using unity builds in MinGW. I pre-compile the dependencies ahead of time and skip building the samples to save time.

[Kojack]

Also, make sure you are comparing the same builds and not mixing debug/release or OpenGL/DirectX.

Release builds of ogre 1.8.1 in directx 9, using the exact same settings since the sample browsers for both use the same config file from the my docs directory.

But this is getting a bit off topic. (But at least less hostile than linux distro fights)

[bvanevery]

From a game developer standpoint I really don't see what there is to fight about regarding Linux distros. You have to go where the customers actually are, and presently that's Ubuntu. I don't know that it'll remain so, but the consumer ecology is what it is. Over time, a game developer's disto reach with a mature engine like Ogre might expand to encompass several distros, but it'll never cover them all. Linuxers who insist on wonky distros, and ideological zealots who don't want proprietary 3d drivers, are going to have to do their own system maintenance. Only a very rich developer would be able to support the majority of Linux distros without batting an eyelash, and nobody's gotten "Minecraft rich" off a Linux only title yet.