## OGRE 1.11.5 Working on ‘Phosphene’

One of the open-source software projects which has often fascinated me, is called OGRE, which stands for Open-Source Graphics Rendering Engine. It’s a very powerful set of libraries, that allows good coders to design 3D graphics applications, which take full advantage of hardware-accelerated – i.e., GPU-based – rendering, of virtual 3D scenes designed by such users, into simulated 2D camera views, within the same scene. This is one of the most common modes in which 3D Graphics is operated.

One of the things that OGRE is not, is a full-fledged game engine unto itself. This is due to:

• Lack of sound implementation (Additionally linking applications to the SDL Library may solve that),
• Lack of scripting support, without some sort of add-on. I think I compiled it with Python support, which would supply scripting, if my coding was good enough.

Modern builds of OGRE break with the past, in that they no longer use ‘OIS’ as their input system. Instead, at least their Sample Browser uses the ‘SDL library’ to do the same.

One of the feats which I have now accomplished on the computer named ‘Phosphene’, which is a Debian / Stretch, Debian 9 system, was to compile version 1.11.5 of this engine because I’m curious about Game Design, which I have been for a long time. And one of the reasons I feel that this software is stable on Phosphene, is due to the information which I already provided in This past posting. The past posting announced observations which I made, when this same hardware was called the computer ‘Plato’, but already running Debian Stretch.

What my observation essentially suggests is, that running 3D, OpenGL applications can in fact break the compositor because they suspend it, but that there is a work-around.

(Updated 2/20/2019, 19h00 … )

## (Solved) How the Latest Wine-Staging Release, for Debian, Introduces a Packaging Problem: Unresolved Dependencies.

One piece of software which many Linux users benefit from is called “Wine”, which is an acronym that stands for ‘Wine Is Not an Emulator’ . This software allows some Windows programs to run under Linux, but has recently been made more powerful, to allow graphics-intensive games to run as well. The version of wine which I’ve been subscribing to is called ‘wine-staging’ , and contains the latest, bleeding-edge features that Wine is to contain, at any later point down the road.

But as I’ve been receiving updates to wine-staging, the latest update would have taken all my computers from version 4.0-rc2, to version 4.0-rc4, which means, ‘…Release Candidate 4′ . At that point, some of my computers could not install the update, because of unresolved package dependencies.

Apparently what’s been happening with Wine-Staging is twofold:

1. The original maintainers are no longer running the project, which also means that Wine is in the midst of a Code Freeze, and that present updates may offer fewer or no new features, from what Linux users are used to, and
2. In the interest of allowing the Windows games with the highest graphics requirements to run (potentially), the devs have nevertheless created a dependency of the latest Wine packages, on the OpenCL packages that install OpenCL natively under Linux.

‘OpenCL’ is a user-side API, which also requires system-side drivers for the specific graphics hardware, and which allows greatly parallel computations to be carried out on the GPU, instead of on the CPU. Apparently, some games use either ‘OpenCL’ or ‘CUDA’ these days, in order to incorporate complex Physics simulations into the game.

(I will assume that the version of CUDA which Wine emulates, requires OpenCL to be installed on the side of Linux.)

The problem under Debian which I’ve detected is, that the newly-introduced dependency of ‘wine-staging-amd64′ (as an example) is simply mainly:

‘ocl-icd-libopencl1′

Which means, that Wine will now insist on using the generic OpenCL drivers, that were developed for and by the Linux community, while not allowing the use of proprietary OpenCL drivers, that are closed-source, and that were developed by the manufacturers of each graphics card.

The problem with this is, that as users, we may only have one or the other OpenCL driver-set installed. We cannot install both the generic and the proprietary drivers. When we try to update Wine-Staging now, doing so will try to install the package above, which will also try to ‘kick out’ , any proprietary packages we may have installed, that provide OpenCL.

## xscreensaver Bug With Latest Proprietary nVidia Graphics Drivers

As described in this posting, I have just applied a major software-update to the computer I name ‘Plato’, in which I replaced its open-source graphics drivers, with the proprietary nVidia drivers, suitable for its graphics card, and for its Linux-build.

That would be drivers version ‘375.82-1~deb9u1′ , from the package manager, for a ‘Debian 9.4′ system.

I have just noticed a major bug, which other people should know about, before they also decide to go with the proprietary drivers. They tend to cause some malfunction with OpenGL-based ‘xscreensaver’ screen-savers, version ‘5.36-1′ .

The bug seems to be, that if I use the graphical configuration tool to preview several screen-savers, when I switch from one screen-saver to another, the previous GL-screen-saver being previewed fails to terminate, which in turn causes the configuration window to freeze, so that the next-chosen screen-saver cannot be previewed. A small blank rectangle takes its place, in the configuration window. When this happens, I actually need to ‘kill -9′ the screen-saver-process – belonging to the screen-saver in question and not ‘/usr/bin/xscreensaver’ – the former of which is taking up 100% of 1 CPU core with nice-time, before I can continue previewing screen-savers.

The problem with this as I see it is, it could also happen after the screen-saver has locked the screen, and when I have entered my password to unlock it. The mere fact that I was always able to unlock one GL-based screen-saver in the past was good in itself, but may only have been luck! The strangeness with which my bug seems to differ from other users’ bug-reports, is that when my OpenGL-based screen-saver was rendering to the root window – i.e., to the whole screen – it did exit properly when unlocked by me.

So as it currently stands, I have set my screen-saver on the computer ‘Plato’, to just a blank screen…

At the same time, OpenGL applications seem to run just fine, like this example, just tested:

However, since the description of the screen-saver packages in the package manager states “GL(Mesa)” screen-savers, it may be better just to ‘remove’ the ‘xscreensaver-gl’ and ‘xscreensaver-gl-extra’ packages.

I found out, that this bug also affects ‘rss-glx 0.9.1-6.1′ .

(Updated 04/30/2018, 19h25 … )

## I’ve finally installed the proprietary nVidia graphics drivers.

In this earlier posting, I had written about the fact that the project was risky, to switch from the open-source ‘Nouveau’ graphics drivers, which are provided by a set of packages under Debian / Linux that contain the word ‘Mesa’, to the proprietary ‘nVidia’ drivers. So risky, that for a long time I faltered at doing this.

Well just this evening I made the switch. Under Debian / Stretch – aka Debian 9, this switch is relatively straightforward to accomplish. What we do is to switch to a text-session, using <Ctrl>+<Alt>+F1, and then kill the X-server. From there, we essentially just need to give the command (as root):

apt-get install nvidia-driver nvidia-settings nvidia-xconfig

Giving this command essentially allows the Debian package-managers to perform all the post-install steps, such as black-listing the Nouveau drivers. One should expect that this command has much work as its side-effects, as it pulls in quite a few dependencies.

(Edit 04/30/2018 :

In addition, the user must have up-to-date kernel / Linux -headers installed, because to install the graphics driver, also requires to build DKMS kernel modules. But, it’s always my assumption that I’d have kernel headers installed myself. )

When I gave this command the first time, apt-get suggested additional packages to me, which I wrote down on a sheet of paper. And then I answered ‘No’ to the question of whether or not to proceed (without those), so that I could add all the suggested packages onto a new command-line.

(Update 05/05/2018 :

The additional, suggested packages which I mentioned above, offer the ‘GLVND’ version of GLX. With nVidia, there are actually two ways to deliver GLX, one of which is an nVidia-centered way, and the other of which is a generic way. ‘GLVND’ provides the generic way. It’s also potentially more-useful, if later-on, we might  want to install the 32-bit versions as well.

However, if we fail to add any other packages to the command-line, then, the graphics-driver will load, but we won’t have any OpenGL capabilities at all. Some version of GLX must also be installed, and my package manager just happened to suggest the ‘GLVND’ packages.

Without OpenGL at all, the reader will be very disappointed, especially since even his desktop-compositing will not be running – at first.

The all-nVidia packages, which are not the ‘GLVND’ packages, offer certain primitive inputs from user-space applications, which ‘GLVND’ does not implement, because those instructions are not generically a part of OpenGL. Yet, certain applications do exist, which require the non-‘GLVND’ versions of GLX to be installed, and I leave it up to the reader to find out which packages do that – if the reader needs them – and to write their names on a sheet of paper, prior to switching drivers.

It should be noted, that once we’ve decided to switch to either ‘GLVND’- or the other- version of GLX, trying to change our minds, and to switch to the other version, is yet another nightmare, which I have not even contemplated so far. I’m content with the ‘GLVND’- GLX version. )

(Edited 04/30/2018 :

There is one aspect to installing up-to-date nVidia drivers which I should mention. The GeForce GTX460 graphics card does not support 3rd-party frame-buffers. These 3rd-party frame-buffer drivers would normally allow, <Ctrl>+<Alt>+F1, to show us not only a text-session, but one with decent resolution. Well, with the older, legacy graphics-chips, what I’d normally do is to use the ‘uvesafb’ frame-buffer drivers, just to obtain that. With modern nVidia hardware and drivers, this frame-buffer driver is incompatible. It even causes crashes, because with it, essentially, two drivers are trying to control the same hardware.

Just this evening, I tried to get ‘uvesafb’ working one more time, to no avail, just as it does work on the computer I name ‘Phoenix’. )

So the way it looks now for me, the text-sessions are available, but only in very low resolution. They only exist for emergencies now.

But this is the net result I obtained, after I had disabled the ‘uvesafb’ kernel module again:


dirk@Plato:~$infobash -v Host/Kernel/OS "Plato" running Linux 4.9.0-6-amd64 x86_64 [ Kanotix steelfire-nightly Steelfire64 171013a LXDE ] CPU Info 8x Intel Core i7 950 @ clocked at Min:1600.000Mhz Max:2667.000Mhz Videocard NVIDIA GF104 [GeForce GTX 460] X.Org 1.19.2 [ 1920x1080 ] Processes 262 | Uptime 1:16 | Memory 3003.9/12009.6MB | HDD Size 2000GB (6%used) | GLX Renderer GeForce GTX 460/PCIe/SSE2 | GLX Version 4.5.0 NVIDIA 375.82 | Client Shell | Infobash v2.67.2 dirk@Plato:~$

dirk@Plato:~$clinfo | grep units Max compute units 7 dirk@Plato:~$ clinfo | grep multiple
Preferred work group size multiple              32
dirk@Plato:~$clinfo | grep Warp Warp size (NV) 32 dirk@Plato:~$




So what this means in practice, is that I have OpenGL 4.5 on the computer named ‘Plato’ now, as well as having a fully-functional install of ‘OpenCL‘ and ‘CUDA‘, contrarily to what I had according to this earlier posting.

Therefore, GPU-computing will not just exist in theory for me now, but also in practice.

And this displays, that the graphics card on that machine ‘only’ possesses 224 cores after all, not the 7×48 which I had expected earlier, according to a Windows-based tool – no longer installed.

(Updated 04/29/2018 … )