OGRE 1.10 Compiled On Laptop ‘Klystron’

One of the projects which I had been working on, while my Hewlett-Packard laptop was running Windows 8.1 and named ‘Maverick’, was to compile “OGRE 1.10″ on it to the best of my ability. And one mistake which I was adhering to, was to insist on using the ‘MinGW’ compiler suite. OGRE developers had already tried to convince me to use the MS compiler, since that was a Windows computer, but I did not comply. This was particularly pedantic of me, since by now a free version of Visual Studio is available, that can compile OGRE.

So now that the H/W has Linux installed on it, I recommenced compiling OGRE, with native compilers and tools. But the results were not exactly spectacular.

One reason for the lackluster results is, the fact that ‘Klystron’ currently has ‘Mesa’ drivers loaded for its Radeon graphics card, instead of having the proprietary, binary ‘fglrx’ driver. Mesa will give it OpenGL 3.3 tops, while ‘fglrx’ would have given it OpenGL 4.5. And the latest OGRE samples include samples with Geometry Shaders, other OpenGL 3 features, and even some Tessellators, which would be OpenGL 4 features.

Apparently, when one pushes any Mesa Drivers to their limits, these will bug out and even cause the X-server to freeze. Thus, when I switched from testing the OGRE OpenGL 2 rendering engine, to its OpenGL 3+ rendering engine, I ran in to an X-server freeze.

This did not force me to hard boot, because often, during an X-server lockup, I can <Ctrl>+<Alt>+F1 to a console window, from there do a user and a root login, and then issue an ‘init 6‘ command, which will usually do a controlled reboot, in which all file systems are unmounted correctly before the restart.

There is one detail to what the Mesa Driver does, which I like a whole lot.They allow for shader code written in the language Cg to run, even though Cg is a legacy toolkit developed by nVidia, for use on nVidia graphics cards and not on Radeon.

The fact that the Mesa Drivers allow me to do that, differently from the limitations which were only imposed on me under Windows 8.1, means that with OGRE 1.10, the Terrain System finally works 100%. OGRE 1.10 uses GPU-generated terrain, whereas most graphics engines rely entirely on their CPU, to create terrain. The earlier inability to get terrain to work with this system, was more crippling than anything else.

But as long as I am not using the ‘fglrx’ drivers, all attempts to get OpenGL 3 features to work with OGRE utterly fail, including any hope of ISO surfaces, which rely on Geometry Shaders, and any hope of GS-based particles. My particles will be limited to Point Sprites then.

What one does in a situation such as this, is not just to throw out OGRE 1.10, but rather, to disable modules. And so I disabled the GL3+ rendering engine, as well as one ‘HLMS Sample’, and am now able to get many of the samples to run, including, importantly, the Terrain Samples.

 


 

Also, there remains an advantage to using Mesa Drivers, which was pointed out to me already on the Kanotix site. The Mesa Drivers allow hardware-acceleration of high-bandwidth, 2D video streams, via ‘vdpau’, while if I was to use ‘fglrx’, the decoding of MP4 Videos would be limited to CPU decoding, which is in itself lame, if we ever wanted to watch serious video streams. And since that laptop has a screen resolution of 1600×900, wanting to watch videos on it eventually, remains a very realistic prospect.

Dirk

 

(Edit : ) I suppose that one question which I should be asking myself, about why perhaps, the OGRE 1.10 GL3+ Rendering Engine does not work, would be whether this could be due to some incompatibility with the GL3.1 Desktop Compositing which I am already running on the same machine. There have been past cases, where OpenGL 2 from an application did not agree with OpenGL 2 Desktop Compositing, but those cases have generally been solved by the developers of the desktop managers.

On ‘Klystron’, I have rich desktop effects running, that use GL 3.1. So it does not seem obvious, that the Mesa Drivers as such, have problems implementing GL 3.

Also, there is a follow-up thought, as to why maybe, Cg was not working before. Whether or not our graphics cards support Cg, it is a necessary component of OGRE, to build their Cg Program Manager. Under Windows 8.1, I was always unsure of how to provide the OGRE Dependencies when building OGRE. But among those dependencies I always linked in a file named ‘Cg.dll‘, the origin of which was unknown to me.

It is exactly the sort of goofy mistake I would make, perhaps to have taken this DLL File from the install folders of Cg on ‘Maverick’, but for some reason simply to have taken a 64-bit DLL, into my 32-bit OGRE build, or to have taken a DLL from somewhere, which may not have been compatible for some other reason.

At least when we install dependencies under Linux from the package manager, such issues as linkage of code and location of folders, are also taken care of by the package manager. So I am sure that the Cg Program Manager belonging to OGRE, recognized the nVidia Cg packages when compiling now. It is just a bit odd that those were native Cg libraries with header files, while my graphics drivers remain the Mesa Drivers.

 

Samba absolutely needs to be user-configured.

On my Linux machines, I generally have the Samba server installed, to ease the simple transfer of data over my LAN. But it can happen that during an initial install, a computer of mine only has the Samba client installed, not the server. This initially results in a computer which remains invisible to LAN-browsing, but which can browse the Samba shares of other computers.

Recently, an upgrade to the Samba packages I had installed on the laptop I name ‘Klystron’, also pulled in as dependencies, the actual Samba server, which next made that laptop visible to the LAN-browsing of my other computers.

And so what I thought next, was that I would not have to set up this new Samba-installation, in that it should default to safe behavior when not configured. And it turns out I was wrong.

The behavior of the new Samba setup was such, that it did not allow unauthorized fetching of user shares, but also such, that that laptop would sometimes just seem to disconnect from the Samba servers on the other computers.

And so what I have learned, is that every time we install Samba, we must also customize ‘/etc/samba/smb.conf‘, so that this configuration is compatible with whatever we have set up on our LAN. I just did so, this afternoon. And ‘Klystron’ then reappeared in the LAN-browsing of my other computers, including to the Windows 7 machine I name ‘Mithral’, without requiring any reboots from me.

The fact remains that ‘Klystron’ has an empty ‘smbpasswd’ list, and that it does not share out any user data. But still, it needed to be configured.

Dirk

 

I have just had to get my hands dirty, with apt-listbugs.

According to This Posting, I have installed ‘unattended-upgrades‘ on the computer I name ‘Phoenix’, and I have also installed ‘apt-listbugs‘, as an insurance policy against ‘unattended-upgrades‘ auto-installing defective packages.

This has always posed the question of what will happen in practice, if ‘apt-listbugs‘ “pins” certain packages, thus having stopped them, but if the update-procedure needs to be reactivated later, manually. I have never had to act in this matter yet, while instead, there was one recorded occasion, on which upgrades did not take place on one day, but took place again a day later, automatically.

But just today I needed to override what ‘apt-listbugs‘ had done, manually. In particular, the question exists, of how one can get apt-listbugs to unpin an upgrade which was once scheduled, so that we can do the upgrade later, and so that we can see what apt-listbugs had to say about it.

By default, if we then simply type in ‘apt-get upgrade‘, nothing happens.

As it turns out, there is a single file named ‘/etc/apt/preferences.d/apt-listbugs‘, which we need to delete, before we can restart an upgrade process.

After I did this, my ‘apt-get upgrade‘ took place normally again, and I got to see what the error was, over which ‘apt-listbugs‘ had stopped the unattended upgrade today.

Dirk

 

The Newest Dropbox version seems to follow Linux Power-Saving Behavior.

As of an earlier posting, I had “Dropbox” v3.16.1 running on my KDE-4 Linux desktop. This version has updated itself to v3.18.1 . Additionally, I have this Dropbox client installed and idling, on the Linux laptop I name ‘Klystron’.

I see one significant new behavior. When I have left my laptop idle, with the screen turning off, the little Dropbox icon changes to show that it has dropped its connection to the Dropbox server. This is similar to behavior which my “Pidgin” IRC client has shown, and seems to suggest, that there are power-saving measures in place on up-to-date Linux desktop managers, which certain applications may opt to use.

The ‘KDE’ desktop manager has in common with ‘GNOME’, that both now use ‘DBUS’ as their inter-process communication system. So what works under GNOME, will frequently also work under KDE when properly set up.

But the fact that both Pidgin and Dropbox seem to do this on my laptop, means that I do not have to keep looking as hard as before, for causes within the kernel module of my laptop WiFi, for possible connection issues. In both cases, the software seems to reconnect to its server, as soon as I have unlocked my screensaver.

Unlocking the screensaver is an event, which a kernel module usually does not recognize.

(Edit 04/17/2016 : ) One way in which such a power-saving mode would make sense however, is that the Kernel can recognize it, and can give the software command to the Kernel Module, to turn off its antenna as well. However, according to This Posting, I have forbidden the KM from following such a command, such that the antenna does not switch off.

Depending on what software we have installed, simply having the WiFi turn off, can cause problems.

Dirk