OpenGL Programming on Linux
This article is not intended to be an OpenGL tutorial or introduction. There are people far more competent in this area than myself, and they have written a number of articles and even books about this subject. Also, even though the project discussed in this article was written and built mostly using Xinside's OpenGL, it is not my intention to discuss the superiority of any of the Linux OpenGL ports or implementations over another. This article tells a cool story about using Linux, and I thought it was worth contributing to the Linux community.
“And, thus,” the professor concluded, “Instead of working on perfecting our home-made ray-tracer—something we have been doing for years—this semester, we'll start something new. You will have to build a 3D, network-capable tank game using OpenGL. You'll be in teams of two or three students. For that, you'll use the RS/6000 workstations we have here, and we'll give you an introduction to OpenGL.”
My ears! They could not believe what I had just heard. As a student in Computer Engineering at the Polytechnical School of Montréal and a computer graphics fan with a good background in ray-tracing, I had been waiting for years to be advanced enough in my studies to be able to take that course in advanced computers graphics. That semester I had finally been able to take the difficult 4th year course, and I had just heard, to my immense disappointment, that instead of working with a ray-tracer and producing high-quality ray-traced pictures, I would have to work on OpenGL. My morale was not high, and fear was making its way along my stomach as I realized I knew a lot less about OpenGL than about ray-tracing. But as one LinuxDoom aficionado would put it: “Armed solely with my Linux Box and my OpenGL Beta product, I plunged into the hostile mass of GL intrinsics, prepared to fight with every last GLfloat variable I had.”
More seriously, OpenGL is a graphics library designed from the start as a hardware-independent interface to be implemented on many different platforms. It uses a client-server approach, similar to the X client-server approach, to provide display of graphics primitives on the chosen windowing system. The server sends commands to the client, and the client displays them.
On X-capable Unix workstations, OpenGL has an extension to the X server named GLX. You can run your OpenGL program on one computer and display it on another, but it requires that the server machine has the needed OpenGL libraries and that the client has the GLX extension. Since those two packages usually come together, this means that both the server and client must be “OpenGL-capable”.
In short, OpenGL is capable of displaying simple geometric objects, showing orthogonal and perspective projections, performing back face removal, doing shading and anti-aliasing, and applying textures to objects. If you want to do something complex—like display a car or a plane—you have to build those objects yourself, and use OpenGL to render them the way you like.
On Linux, to my knowledge, you have the choice of several commercial implementations and one free implementation:
Xinside's and Metrolink's OpenGL ports for Linux, each of which requires that you install its own X server to provide the GLX extension and generally higher performance.
Portable Graphics, whose product runs directly on XFree86.
Brian Paul's Mesa library, which is GPLed and available for free, but has no GLX extension. It's impressive and affordable.
My personal experience was that the product I was using (Xinside's OpenGL second beta, and later, the final product, which was even faster) was of very high quality. It was faster and more compatible than Mesa. Speaking about commercial applications running on a free operating system is a sensitive and slippery issue, especially when there are freely available equivalents (Mesa) and even more so when you happen to find yourself very (or at least more) satisfied by a commercial tool. I found Mesa to be an impressive piece of software, but Xinside's OpenGL beta was noticeably faster and more OpenGL-compatible, since it is a true OpenGL implementation.
So, here I was, a few days later, in front of an RS/6000 workstation, writing the first few lines of code of that soon-to-be tank game and wondering if it was going to run on my Linux box. You see, I had subscribed to Xinside's OpenGL beta program a few months before as a means to remotely run OpenInventor from my Linux box, and thus, I found myself with an OpenGL-capable Linux computer. Later that same day I went home—while my Linux box was retrieving the sample code by FTP—and got ready to compile it under Linux.
The project we were building was using a freely available auxiliary library named libaux. “Fine,” I thought, and I FTPed its source code from the RS/6000 lab and compiled it on my Linux box. It's also available from ftp.sgi.com under the OpenGL sub-directory, along with all the examples from the OpenGL programming guide. With a lot of hope and increasing excitment I got ready to start the sample code and...it crashed, generating a panic file and killing the X server.
The team later figured that this problem was caused by a small bug in the Beta OpenGL release I was using which caused it to misbehave when using a color-indexed color mode and single-buffering. The program, however, ran fine as soon as I switched to use RGBA (for Red, Green, Blue and Alpha) color mode—it even ran slightly faster than on the older RS/6000 workstations we were using!
Granted, those RS/6000 were basic entry-level workstations, and their age (about two years), combined with poor 3D hardware accelerated video cards, proved they were no real match for my P133 with its Matrox Millennium (although OpenGL on Linux only provided software 3D acceleration). For someone who has been used to “This hot stuff runs on workstations—W-o-r-k-S-t-a-t-i-o-n-s—don't even think about running it on your home PC!” this OpenGL on Linux experience was like a dream come true.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide