Slashdot Mirror

An anonymous reader writes: Mesa3D developers have announced the release of Mesa 12.0. Mesa 12 notably adds open-source OpenGL 4.3 drivers for Intel, Radeon, and NVIDIA on Linux, and it also integrates the previously open-sourced Intel Vulkan graphics API driver. From the Phoronix analysis, "Mesa 12.0 is easily one of the biggest updates to this important open-source user-space OpenGL driver stack in quite some time and will offer much better support and features especially for Intel, Radeon, and NVIDIA open-source Linux desktop users/gamers." You can download Mesa 3D Graphics Library 12.0.0 here.

Michael Larabel at Phoronix has been assiduously reporting on some of the small advancements in open source 3-D graphics; in aggregate, those small advancements make for big improvements in hardware (and platform) support, as well as higher performance. Phoronix published today a year-end wrap-up highlighting some of the ways that Mesa has developed; it's quite a list. An excerpt: This time last year core Mesa and the drivers were still limited to OpenGL 3.3 compliance while in 2015 we've seen core Mesa reach up to OpenGL 4.2 support. The AMD RadeonSI and R600g drivers have raised up through OpenGL 4.1 (though R600g is limited in what supports GL4) and the Nouveau NVC0 driver is at OpenGL 4.1 as well. The Intel Mesa driver is still at OpenGL 3.3, but they are extremely close to OpenGL 4.2 and should hit that milestone in early 2016 after having been recently focusing up on OpenGL ES 3.1 support, which they did achieve this year. Besides tackling more GL4 support, Mesa this year has seen the new VirtIO GPU driver for 3D support in guest VMs, continued work on the new Raspberry Pi 3D driver (VC4), video encode/decode improvements, and other Gallium3D state tracker highlights.

An anonymous reader writes: Intel is open-sourcing their work on creating a high-performance graphics software rasterizer that originally was developed for scientific visualizations. Intel is planning to integrate this new OpenSWR project with Mesa to deploy it on the Linux desktop as a faster software rasterizer than what's currently available (LLVMpipe). OpenSWR should be ideal for cases where there isn't a discrete GPU available or the drivers fail to function. This software rasterizer implements OpenGL 3.2 on Intel/AMD CPUs supporting AVX(2) (Sandy Bridge / Bulldozer and newer) while being 29~51x faster than LLVMpipe and the code is MIT licensed. The code prior to being integrated in Mesa is offered on GitHub.

jj110888 writes: Mesa, the open source implementation of OpenGL, has just announced version 11.0. This adds support for the amdgpu driver, fixes for non-Windows platforms, new OpenGL ES extensions supported, and more. Most notable is the support for all extensions in OpenGL 4.1 by the radeonsi and nvc0 drivers, and support for extensions added in OpenGL 4.2 by the i965 driver. This brings the OpenGL version supported by core Mesa from 3.3 to 4.2, five and a half years after OpenGL 4 was released. Mesamatrix gives the status of which OpenGL extensions are supported by which open source driver. Vulkan, on the otherhand, will have an open source driver once the spec is released.

An anonymous reader writes: The Mesa 3D project that is the basis of the open-source Linux/BSD graphics drivers now supports OpenGL 4.0 and most of OpenGL 4.1~4.2. The OpenGL 4.0 enablement code landed in Mesa Git yesterday/today and more GL 4.1/4.2 patches are currently being reviewed for the Intel, Radeon, and Nouveau open-source GPU drivers.

Via Phoronix comes news that Mesa 10.2 will be released in a few days with several interesting new features. Highlights include OpenGL 2.1 support for Freedreno (the driver for the Qualcomm graphics chips), video encoding and decoding on GCN Radeons using the new OpenMAX state tracker, and initial support for Intel's upcoming Cherryview Atom SoC. Progress is being made toward OpenGL 4 support, and the llvmpipe software rasterizer finally supports OpenGL 3.2. The release won't feature a few things: the Intel Sandybridge driver still does not support OpenGL 3.3, the R9 290 Radeons are still not working (despite claims by AMD a couple of years ago that cards starting with the Radeon 8000 series would be supported by the Free Software driver at hardware release time), and OpenCL support is still experimental.

An anonymous reader writes "Mesa and its open-source Intel graphics driver now are in compliance with the OpenGL 3.2 specification (PDF). It took four years for Mesa to get up to GL 3.2 / GLSL 1.50 compliance, and support for the other Mesa drivers isn't too far behind, but they're still years behind in supporting OpenGL 4. Supporting a major new OpenGL API has resulted in Mesa 10.0 being called the next release. It has many other features, like performance improvements and new Gallium3D features. OpenGL 3.3 support might also be completed prior to the Mesa 10.0 release in November."

An anonymous reader writes "Modern Linux desktops like Ubuntu's Unity and the GNOME Shell have placed a requirement on OpenGL 2.0+ support for handling their compositing window managers and desktop effects. Wayland's Weston also needs OpenGL ES 2.0 support. Now with modern Linux distributions like Ubuntu 12.10, rather than falling back to a 2D unaccelerated desktop if you don't have a sufficient GPU or graphics driver, users are being forced to run LLVMpipe as a CPU-based software rasterizer. LLVMpipe works fine if you are on a new PC with a fast x86-64 CPU, but the OpenGL-based Linux desktops are causing growing pains for ARM hardware, virtual machines, servers, multi-seat computers, and of course all older hardware. LLVMpipe is a Mesa Gallium3D driver that uses LLVM for run-time code generation as an attempt at accelerating graphics faster on the CPU. So much for Linux being good for old computers?" The KMS based graphics stack is already effectively unusable on AGP systems (if you have SMP + AGP, there are race conditions somewhere leading to really hard crashes that appeared a couple of years ago and dozens of years old open bugs with no resolution other than "use PCI mode" which cuts bus bandwidth by 4 or 8 times, and still doesn't work with SMP), but for those with older PCIe/IGP systems you could always runs Window Maker, Sawfish, Enlightenment, Open Box, or one of many other window managers without a compositor. Of course then you lose compositing, and there aren't any usable external compositors for some reason. The flipside to this is that moving to OpenGL as the primary interface to the GPU means one fewer driver that has to be written, and will probably lead to an overall improved experience for those with supported hardware given the limited resources Free Software drivers authors have.

Mesa 3D has famously always not been technically OpenGL (lacking certification), but times are changing: "This is a great day for Mesa and open-source graphics drivers. Just a tad over a month ago, I submitted OpenGL ES 2.0 conformance test results to Khronos for Intel Sandy Bridge and Ivy Bridge GPUs with Mesa 8.0.4. There were no objections during the 30 day review period, so we are now officially conformant! Finally being on that list is pretty cool. Not only is this great news for my team at Intel, but it's terrific news for Mesa. Mesa has had a long history with OpenGL, the ARB, and Khronos. This is, however, the first time that Mesa has ever, in any way, been listed as a conformant implementation. This is a big boost to Mesa's credibility."

An anonymous reader writes "The developers behind the Mesa 3D graphics library, which provides the default graphics driver support for most hardware on Linux (and BSD/Solaris), has ended their support for older hardware. Being removed from Mesa (and therefore versions of Linux distributions) is support for hardware like the 3Dfx Voodoo, Intel i810, ATI Rage, and S3 Savage graphics processors. Also drivers being dropped were for Matrox and VIA graphics. Mesa developers also decided it's time to end support for the BeOS operating system. Dropping this code lowered the developers' responsibility by some 100k L.O.C., so maybe we will see GL3 support and OpenCL in Linux a bit sooner."

j7953 writes: "Brian Paul, the author of Mesa, was laid off by VA Linux. Here's his mail to the mesa3d-dev list." Other places are reporting that Keith Whitwell of the DRI project was also laid off. Presumably just two of many major contributors to open source, but honestly I don't really know who got the axe. So far Slashdot has been unaffected by the layoffs (VA owns Slashdot too in case you live in a box).

Long-suffering Slashdot reader WrinkledShirt contributes this review of John Hall's Programming Linux Games, and lays out the good and the bad in a book that's one of the few of its kind. More games are always good -- hopefully books like this one will spark some inspiration.

Programming Linux Games author John Hall pages 415 publisher No Starch Press rating 7.5 reviewer WrinkledShirt ISBN 1-886411-49-2 summary Well-written guide to a wide range of game-writing tools for Linux, but not a definitive reference work for any single task.

Introduction

The potential for linux gaming has really exploded in the last couple of years. In many cases, the potential has been realized -- Unreal Tournament, SimCity 3000, Tribes 2, Quake 3, Alpha Centauri, and many other successful Windows titles, have all been brought to Linux, with Loki leading the charge. Judging by the bottom line, there's a definite shortage of true cash-cow success stories in this enigmatic part of the industry, and hence, a shortage of good reference material for naive people hoping to produce that next cash cow.

However, we've reached such a point of critical mass of knowledge and technology that books had to start appearing sometime. So, despite the fact that there's no overwhelming market demand for Linux games and a high ratio of hobbyists to dedicated game developers for the OS, here we have a book aiming at taking amateur Linux game development to the next level.

However, much of the technology out there for game programming in Linux is still heavily in development, with many of the APIs and libraries still a long way away from a 1.0 release. Allegro and Clanlib are a couple of exceptions to this trend -- both are popular APIs that sadly don't get much more than a passing mention in the book. Their sexier counterpart, Sam Lantinga's SDL, gets a fair amount of treatment (no surprise there, considering John Hall was the lead author for a team based within Loki) -- but even this fairly feature-complete library, which Loki uses to port its games over from Windows, isn't explored in its entirety.

Instead, there are also crash courses in BSD sockets, package management, TCL, the framebuffer and various sound APIs, and what we end up with here is the consummate cookbook, a jack-of-all-trades-and-master-of-none tome that introduces us to a wide variety of Linux gaming topics while stopping short of being a definitive reference for any of them. Such is John Hall's work, an interesting, wide-ranging introduction to game programming for an operating system that few believed was capable of it not too long ago.

John Hall, an experienced game developer, participated in Loki's Civilization, Call to Power game hack, and is currently working for Treyarch developing that company's Spider-Man title for the PS2.

The Good

As far as cookbooks go, this is a good one, and there isn't much concerning Linux game API programming that isn't touched on. There's an ongoing case study (Penguin Warrior) that is developed over the course of the book. Each chapter introduces a fairly deep concept, gives a decent function reference related to the concept, then incorporates the knowledge into proof-of-concept code, and then uses the new-found knowledge to enrich the case study. The tone is straightforward and the execution is solid. The final game works well enough to give confidence that the reader could take the knowledge in this book and apply it to his or her own project, either to add new features or re-think old ones.

The book is also well-written -- the sample code is extremely well-commented and good error-handling is in place. He makes no assumptions about the knowledge of the reader, dealing with such introductory topics in Linux programming as vi vs Emacs, the FSH and make, although he never gets annoying or patronizing. *cough cough* LaMothe *cough*

Individual chapters stand out as being great introductory resources for material that doesn't have much in the way of documentation. The important aspects of SDL get good treatment in one complete and comprehensive unit. There's also a thorough chapter on audio programming, comparing and contrasting OpenAL, OSS, ALSA, Ogg Vorbis, and ESD (among others), and all this after showing off SDL's sound capabilities one chapter earlier. Many of the pitfalls associated with each of the different technologies, as well as the pitfalls of sound programming in general, are covered here. It's a great jumping-off point for those who don't know much about the audio end of things.

There's even a really neat chapter on incorporating TCL script interpretation within a program written in C. For anyone who's had trouble throwing together their own text parser for initialization scripts, or who's fed up with the constant recompiles needed when tweaking for the most arbitrary of changes of the game's AI, the information in this chapter is a godsend. In the Penguin Warrior case study, it's almost spooky how effective TCL turns out to be in making the computer ship chase and evade the human player.

Finally, I want to reiterate the effective use of the case study, Penguin Warrior. Having seen the way other game programming texts handle using samples to illustrate game programming concepts -- which is often a mish-mash, to say the least -- the way this book approached the issue is refreshing: there's one major project, and each chapter brings us closer to that project's completion. The code works as intended and goes a long way to convince the reader that the libraries and techniques explored in this book are near-commercial-level quality. (Networked games turned out to be choppy on my machine, but that was the only real black mark I could find in the program's execution.) If nothing else, John Hall deserves a good deal of thanks for proving that game development on Linux is a realistic and rewarding endeavor.

The Not So Good

At times, the generalist nature of the book left me wondering if Hall couldn't have gone just a little bit further in some of the topics. There's a decent enough synopsis about deployment using Loki's install tool, as well as packaging in general, although nothing related to the Penguin Warrior game itself, so we don't get to see the theory in practice as much as it could have been. Also, he teases us by early on by starting with the compiler, moving to the make utility, talking a bit about package management, and then mentions automake, but he stops short of really explaining how to bring that into an existing project. Considering all the fun little dependencies needed for multimedia programming in Linux, this would have been a valuable bit of information for anyone not used to deploying on the platform.

Another instance of this so-close-yet-so-far approach occurs when he talks about incorporating Mesa into an SDL program. He tantalizes us with a code sample illustrating how to use the SDL as a replacement for glut, but that's all -- the material doesn't really get deep enough to convince readers that a 3D neophyte really can abandon glut for the SDL, particularly when many OpenGL reference materials out there rely heavily on glut as a teaching aid for windowing and other utility functions. Loki primarily used SDL to handle its 3D utility programming, so at least we know it's possible, but given the exploding popularity of 3D games it's too bad this wasn't covered more.

It's sometimes hard to tell exactly who the book is intended for. The introductory chapters include discussions on topics such as the different gaming genres out there, despite the fact that game programming hopefuls who don't know that Quake is a first-person shooter must make up a really narrow audience. Also, it's almost enough to give one whiplash to see how quickly he dives into using ioctl() when only a couple of chapters earlier he was explaining the basics of using gcc. Next up soon after that? Strap yourself in, we'll be writing straight to /dev/fb0! It's almost comical to think about how much dangerous knowledge a newbie's been given over the course of the book. Still, like I said earlier, he never talks down to the reader, who because of this might feel compelled against better judgement to be whisked along into subject matter that really needs other support material to be of any real use.

Hall's a humble enough guy, which is great insofar as writing style is concerned, but in one of the last chapters, he starts questioning some of the choices he made while coding Penguin Warrior throughout the book. Specifically, he says he probably should have used C++ instead of C, Scheme instead of TCL, and UDP instead of TCP for the networking, and this is cold comfort for people who would have hoped that the author would have picked the best plan of attack from the beginning. That said, C, TCL, and TCP are appropriate choices due to the simplicity of execution and the fact that they introduce useful techniques from a design point of view. Still, there's no point giving readers a sense of wistful "What if?" if you don't have to. It also highlights that this book is more a beginner's API reference than a game programming book per se.

To take that point further, there also really isn't much in the way of abstract game programming theory. This book could have really distinguished itself as special if some content related strictly to game development was here. There's a mention of Gamasutra here, a method of quick division there, the equation of a distance from a point to a line thrown into the mix, and that's pretty much all there is. Topics not really covered include optimization, pathfinding, and cracker-proofing your code, and what is talked about on the subjects of artificial intelligence design, collision detection, and physics is all rudimentary ... For coverage on these sorts of topics, you'll have to look elsewhere.

Finally, and this is really not the fault of the author or the book, but one wonders if the time was right for much of this material -- or, at the very least, its highly generalist approach. DRI is making its presence felt, the various audio APIs out there are improving all the time, and the LSB is coming along nicely, but until there's a proven and stable multimedia base to work from, no definitive guide can be written, and this sort of organized dogpile is really the best we can hope for with so much stuff to cover. The SDL is a top-notch library for graphics programming, and it's likely an entire book could have been spent strictly on graphics programming using it, and the depth that such a book could have attained far surpasses what we're given here. Plus, in a year from now, who knows where any of these sound APIs will be? Of course, these might prove to be just esoteric issues in the grand scheme of this book.

Conclusion

Despite the criticisms I have of this book, I really don't want the message that is conveyed here to be anything but positive. There's a lot working for this book -- the chapters on SDL, sound programming and incorporating TCL and C are excellent, and will be especially helpful for people who are novices in these areas. Considering the alternatives (hitting dryly-written online docs or constantly shaking your Google to see what falls out), this book is a very attractive option. Programming a fully-functional multiplayer game would probably require more effort than might be suggested by the brevity of the chapter on socket programming, but that chapter is a solid introduction as well. The book as a whole is well-written and succeeds for the most part in its endeavor to make the best of a chaotic situation. I'd recommend this book to anybody who appreciates the messy-kitchen style of learning, or to anyone with decent hacking skills who just needs to break the ice when it comes to the Linux game APIs. And even though it gets slightly schizophrenic in its attempt to be both an introductory text and a definitive reference, this is the sort of book that could kickstart a new movement in Linux game development.

Table of Contents (exploded version here)

1. The Anatomy of a Game
2. Linux Development Tools
3. Linux Gaming APIs
4. Mastering SDL
5. Linux Audio Programming
6. Game Scripting Under Linux
7. Networked Gaming with Linux
8. Gaming with the Linux Console
9. Finishing Penguin Warrior
10. To Every Man a Linux Distribution

• Glossary of Terms
• Bibliography

Related Links

Sample Code
No Starch Press
Loki
SDL (List of SDL games)
OpenAL
DRI
Mesa
libsndfile
Gamasutra

You can purchase this book from Fatbrain.

Sam "Criswell" Hart writes "Just checked out the Indrema Developer's Network website and saw they have a lot of new content. You can now get the IESDK here (which is of course a bunch of things already available like OpenAL and Mesa3D, and includes the Linux kernel 2.4-pre10). You can check out what's "Under The Hood" of the L600 (which is really just information that's been available for a little while now). While it does look very kewl, and I am stoked to try my hand at coding for the thing, I am wondering why the IESDK doesn't include any 2D graphic libraries (such as SDL)... since not all games are 3D ;)"

Okay, here they are: Brian Paul's answers to your questions. Even if you've never heard of Brian or Mesa, his comments give insight into how an "essential but unsung" Open Source project runs, and why Brian has devoted endless time to Mesa. (More below.)

Roadmap?
by ink
Could you please explain how all this fits together?

• Precision Insight
• XFree86 4.0
• Mesa
• Glide/3dfx acceleration
• Other accelerations
• GLX
• DGA
• SVGAlib/GGI/KGI and 3D acceleration

Many are confused. ;)

Brian:

Precision Insight, Inc. is the company I work for. We're an open-source development company focusing on 3D graphics drivers for XFree86 on Linux. We're funded by 3D hardware vendors and others (such as Red Hat and SGI) to implement the infrastructure and drivers for specific hardware. Go to www.precisioninsight.com for more information.

XFree86 4.0 will be the basis for our 3D hardware acceleration work. It will include the DRI/DRM technology we've developed.

Mesa is my OpenGL work-alike library. It provides the top- level interface between applications and graphics hardware.

Glide is a thin, low-level interface to the 3dfx Voodoo hardware. Recently, Glide was open-sourced by 3dfx. The first popular graphics hardware to be supported by Mesa was the Voodoo hardware. The existance of Glide on Windows and Linux made that possible. Otherwise, we would have needed register-level hardware documentation.

GLX is actually three things: an extension to the X server which integrates OpenGL with X, it's a wire protocol for remote rendering, and it's an API for X-based OpenGL programs.

DGA is XFree86's Direct Graphics Architecture. It's a method for direct access to your graphics hardware, bypassing Xlib. It also lets you switch display resolutions and depths on the fly. At this time, DGA is not part of our DRI-based driver work.

SVGAlib/GGI/KGI are non-X-centric approaches to graphics on Linux (and other OSes, I believe). They're not components in our DRI system.

One important component you missed is the DRI (Direct Rendering Infrastructure). This is a component developed by PI to solve the problems of resource management, coordination, and secure hardware access. In some ways you can think of this as the glue holding all the other components together.

The way that XFree86, the DRI, GLX, Mesa and the hardware drivers fit together is pretty complicated. In fact, that's a big reason why it's taken so long for 3D accelleration to happen on Linux. It's a big, complicated problem.

What's Missing?
by handorf

We've seen Mesa and X come pretty far in the last year or so. We've got nVidia, SGI, Precision Insight, 3dfx and others kicking in support for the efforts. Willing developers aren't too difficult to come by either.

So what are we missing? Will X 4.0 solve our issues with 3d lagging behind MS? What do we need to go to get 3d chip makers bundling Linux drivers with their cards?

Basically, where do you see the Linux/3d systems' weaknesses? We're moving ahead, but are we going to catch up or are we always going to be playing "Johhny-come-lately"?

Brian:

In the past, the weaknesses were lack of hardware specifications and lack of manpower/expertise.

The hardware vendors now recognize the value of the Linux market and want to satisfy it. So now they're funding us to develop the needed drivers and infrastructure. When you send in the product registration card for your new 3D hardware, be sure you indicate that your OS of choice is Linux. That'll help affirm the presence of the Linux market.

As I said before, implementing 3D hardware acceleration is a really big and complicated problem. You need skilled engineers to work on a bunch of components including the kernel, the X server, the GLX interface, 3D software (Mesa) and the hardware drivers. In the past it was almost impossible to find the manpower to do all this. The people with the know-how were already employed full-time with other jobs. Thanks to IHV funding and the creation of Precision Insight, we've now got a strong group of skilled engineers working full-time on the project.

I don't think we're missing anything now. It's just a matter of time before 3D hardware is well-supported on Linux. As for weaknesses, I don't see any obvious ones. We have the know-how to produce high quality, high performace 3D solutions on Linux.

I could ask you...
by aheitner

...about dry performance tradeoffs and clever ways of making GL blazing fast. But I've got a better question.

A long time ago, you said you didn't want to be paid for your efforts on Mesa. Rather than sending you checks, you requested that people show their appreciation by sending you a six-pack of an interesting local beer.

I imagine all these years later you had the opportunity to sample quite a few brews. Which have been your favorites, and why? Have you received beer from any interesting people?

Brian:

I think I've had 8-10 people send me beer. Unfortunately, I didn't keep a list of them and don't remember specific ones. I've enjoyed them all though! Probably the most "interesting" experience was when someone from Finland (I think) sent me a case of beer. I figured I just had to go down to the shipper's office in Boston to pick it up. Wrong! I had to go to 3 different agencies scattered around town: first the shipping agent, then the US customs office and finally to the British Airways warehouse. It took the whole afternoon to track down that one case of beer and I must have signed my name to a dozen forms along the way! It was worth it though!

Distributed Mesa?
by Lord Kano

Are there any plans to develop a "professional" tool based on Mesa for "professional quality" 3d rendering?

In a nut shell I'm thinking of an app designed to run on a cluster of machines to decreas rendering time for movies.

Brian:

I think most of the commercial 3D vendors provide render farm support. SoftImage, for example, uses Mental Ray as its (distributed) renderer. However, these renderers are not based on OpenGL/Mesa. They're typically scan-line renderers which don't need or use graphics hardware. All you need is a lot of memory, disk, bandwidth and CPU power.

A few people have experimented with parallelizing Mesa either on multi-cpu systems or on network clusters. I used to have the URL for one such project but have misplaced it. I'm sure that if you do a web search for "Mesa" and "parallel" you'll find something. I don't have plans to personally work on that sort of thing- I've got too many other things to do.

3D Engine Design Question
by Effugas

I've been banging around a theory for a while, one that (in my mind) explains why Direct3D drivers end up being ubiquitous(I mean beyond the fact that *MS* is behind it).

Would it be fair to say that OpenGL Driver Development is much more difficult than Direct3D Driver Development because Direct3D is a much, much simpler 3D description language?

In other words, game/app programmers can expect much richer functionality out of the OpenGL API, but at the expense of the chipset designer needing to implement that same extremely rich functionality? In other words, do game programmers have to reinvent a wheel that perfectly suits their needs in Direct3D, whereas chipset designers have to reinvent a wheel that perfectly suits their hardware for OpenGL?

Brian:

I'm not 100% clear on your question but I'll take a stab at it.

I'm not an expert on Direct3D but I'd expect that writing a high-quality driver for Direct3D takes about as much time as for OpenGL.

For 3D game developers, I think the hardware really determines which features are going to be used, regardless of the API. Only those features which the hardware accelerates will be used and I'd expect the same hardware features to be exposed by both the Direct3D and OpenGL drivers (with some assorted exceptions, of course).

For general 3D applications performance might not always be the top concern. Portability, uniform, rich feature set and good documentation can make the API decision (hopefully OpenGL).

In the early generations of PC 3D hardware, the chip makers only implemented the features which were essential to satisfying the needs of gamers. The competitive nature of the business has forced the IHVs to increase performance, increase image quality and/or expand the feature set. I don't think targetting a particular API is their top priority. It's industry competion which drives their designs.

However, I do think the hardware designers have found the OpenGL specification to be pretty useful. It defines a pretty comprehensive set of features and a concrete order of operations. If if didn't exist I bet there'd be a lot of painful inconsistencies across the available hardware.

A quick question
by jd

What do you see as the advantage of Mesa over other GL implementations, or even other 3D approaches?

In other words, what does Mesa/GL have, that makes it a system you want to develop?

Brian:

Mesa's open source. Because of that, Mesa has been ported to dozens of operating systems. Now, there's hardly an OS in existance that doesn't have an OpenGL-compatible library. That's great for application developers. Otherwise, you'd be forced to use proprietary graphics libraries on different systems. And some systems wouldn't have a 3D graphics library at all.

Modesty aside, I have to wonder how popular OpenGL might be if it weren't for Mesa. A lot of people have learned 3D graphics programming with Mesa who otherwise wouldn't have had access to the technology. And Mesa has allowed application developers to deploy OpenGL applications on platforms they might have had to omit otherwise.

Personally, I _really_ like the clean design of the OpenGL API and pipeline. It's been fun to implement it. Which leads to...

Implementing existing standards
by shawnhargreaves

All these years you've been doing such great work on MESA, youve been concentrating on implementing the existing OpenGL API. Does it ever get frustrating having to stick to that standard, and do you ever wish you were able to do things a bit differently? If you could, what things about OpenGL would you most like to change?

Brian:

Some little corners of the OpenGL spec have been a pain to implement. At times it was tempting to take short cuts and leave things out that I didn't like but I realized pretty early on that that would be a very bad move. If I didn't follow the spec, lots of users would eventually find the inconsistencies and report bugs and maybe even abandon Mesa. It could have also made a bad impression of OpenGL on people.

I also realize that OpenGL was designed from the beginning for hardware implementation. That makes a software implementation a bit clumsy sometimes.

If I could change the spec though, there's a few things I'd change:

• omit texture borders
• omit glEdgeFlag
• omit glPolygonMode
• omit glColorMaterial
• require homogeneous use of glVertex, glColor, etc calls between glBegin/glEnd.
• overhaul glRasterPos semantics, add glWindowPos.
• minor changes to glDrawPixels

These would simplify my life as an OpenGL API implementor but probably not dramatically. The fact that I don't have any big complaints with the API goes to show how good I think it is.

Legal Hassles?
by Effugas

You've been the implementor of quite the massive reverse engineering project -- something rather similar to what we might have expected out of the Qt-clone Harmony project had the tea leaves turned out differently.

Have you had any legal hassles from SGI, before they turned so powerfully towards the Open Source ethic? Similarly, how do you see your relationship with SGI now that they're no longer incompatible with their culture?

Brian:

I might have had legal problems with SGI if I wouldn't have been so careful. Before releasing Mesa I asked SGI for their position on an open source implementation of the spec. I worked with them to define the disclaimer and legal terms of the library. I think they appreciated that. If I'd have just sprung Mesa on the world without checking with them first I might have upset them.

Next, I think that they appreciate the fact that I try to be fully compliant with the spec. If I'd have written an incomplete or buggy library they might not be too happy. Users would be unhappy and confused too -- witness the MiniGL drivers of recent years.

Finally, as I said before, Mesa has allowed a lot of people to learn and use OpenGL who otherwise wouldn't have access to an official implementation. I think that Mesa's helped to promote OpenGL, not threaten it.

Question about OpenGL licensing...
by Rexifer

Is there any chance that Mesa3D will eventually become an OpenGL licensee? At work, the higher-ups have officially discounted Linux as a viable option for developing some of our visualization tools because Mesa isn't officially OpenGL, despite the many protests of the developers... :(

With Microsoft backing off Open GL, how badly does this affect game developers developing for different OS's out there?

Brian:

There's a chance that Mesa could become an official OpenGL. Really all that's required is a license. However, there's issues about conformance testing the many Mesa drivers on the many Mesa platforms that makes this complicated. I can't give any firm predictions on what might happen or when.

Despite Mesa not being an official OpenGL I am able to run the conformance tests on it (provided by SGI under strict terms). I'm currently only testing with software Xlib rendering and some tests don't pass yet. But from my personal experience with many other OpenGL implementations I can say that Mesa is at least as good as the average OpenGL from other vendors.

Finally, Microsoft isn't backing away from OpenGL. The Windows 2000 / OpenGL story wasn't factual and misled many people. You can find clarifications from Microsoft in several forums.

SGI involvement
by shawnhargreaves

Now that SGI are getting involved with Linux, have you had much to do with their original OpenGL developers? Do you think they will be contributing code to MESA, or are they more likely to come up with their own alternative implementations? I would imagine it feels quite strange to be suddenly getting so much interest from the "big official company" that started the whole thing in the first place!

On a related note, now that SGI are making noises about Linux support, is there any chance of MESA becoming officialificated so that we can actually call it OpenGL? Not that this makes any practical difference, but it would be nice if we could finally stop having to call it "something that works exactly like OpenGL, but isn't OpenGL for legal reasons" :-)

Brian:

I've known several of the SGI OpenGL engineers for years now. We get along great. Some former SGI people have contributed features to Mesa over the years.

I've said all I can about Mesa becoming an official OpenGL in the preceeding answer.

Where do you go now?
by asparagus

Back a few years ago, Mesa was the only choice for 3d (OpenGL-esque, at least...don't get me started on QD3D) on the macintosh platform. It worked great! [When apple finally released their version, it took 10 minutes for me to relink libaries and recompile my code. Nice work.]

However, now that Apple's released/purchased OpenGL for their platform, development for mesa has lagged. (Can't compete, unfortunately.) I'm certain that this has happened on more than one of the Mesa3D platforms. And so, my question:

Where do you see development of Mesa going once a particular platform has licensed opengl?

Brian:

On some platforms, like Windows, there isn't a really big need for Mesa. There's lots of other (hardware accelerated) OpenGL drivers available. By that reasoning, there may certainly be a number of platforms on which Mesa isn't relevant.

However, the fact that Mesa is open source and that IHVs are releasing their technical specs changes this a bit. The open source community has proven its ability to produce large scale, efficient, high quality products. In many cases an open source project can produce better results than a closed, commercial development team.

In the way that Linux is outpacing commercial Unix products, so might Mesa outpace commercial OpenGL drivers. Mesa's got enough momentum behind it now that this could happen. I'm not betting on it but I won't be surprised if it happens on a few platforms.

Unfortunately, Mesa has lagged on Windows and MacOS in comparison to Linux and similar OSes. It's really a supply/demand thing. If there's a big enough demand for Mesa support on a particular platform, eventually some of those interested will step up to the plate and put in the work needed to make it useful.

[I'll also answer a few more questions which I thought were interesting:]

Mesa on MacOS, MacOS X Server
by Anonymous Coward

I do most of my computer graphics work on SGI IRIX/OpenGL, and sometimes I try to recompile some code, just for fun, on my Mac, using Apple's OpenGL SDK.

Mesa does exist for the Mac, but it's not distributed as part of the main Mesa distribution. I would like to see that change. So here is my question: why are MacOS and MacOS X Server versions of Mesa not part of the main Mesa distribution? Is this ever going to happen?

Thanks - and thanks for Mesa! Besides everything else, it's a GREAT educational tool having the source code available - I can show it to my comp.graphics students and say: see how it's implemented? See what it means?

Brian:

Mesa 3.1 (to be really very soon) will include the latest Mac code. I haven't used it so I can't say how well it works.

Motivation and Mark Kilgard
by Midnight Warrior

Brian,
Let me start off by saying I have followed you since before v1.2.8 and you have saved my company large sums of money by making us not port OpenGL to X ourselves (when IrisGL died). My question is this: When Mark Kilgard (of GLUT and the GLX green book fame) left SGI, he seems to have completely left the OpenGL scene. Or at least publicly. Do you envy his newfound privacy? If not, what keeps you going through all the "when are you going to support the xxxx card?" questions? Especially since you yourself have stated that the easy stuff is done. It's all optimization now - paths I'm sure you've already completely explored. That and 3d support is something you've almost always allowed others to build from the ground up (ie glide support). Thanks. Sorry I never sent you any beer from Ohio.

Brian:

I think Mark's just busy working really hard on NVIDIA's OpenGL drivers. He's contributed to several conferences lately so he hasn't left the OpenGL scene. GLUT could be called "done". There's not a whole lot needed there.

Somedays I get tired of dealing with Mesa bugs and random newbie questions but I'm still having fun working on the project so I put up with it. I somtimes wonder how much longer I'll have to energy to keep it going. Putting Mesa into CVS and getting more developers on board has helped me a lot.

What parts of OpenGL were fun to implement?
by foolishj

What were your favorite parts of OpenGL to implement, and which ones were your least favorite? Were there any areas with bugs that seemed to take forever to stomp out? Any new features you're looking forward to trying out?

Brian:

Favorite parts: designing the overall architecture. I also get some enjoyment from occasionally tearing up existing parts of the code, rewriting it to be more efficient, do new things, and making it easier to understand.

Least favorite: fixing nasty bugs. Occasionally I'll get a bug report that takes several days to track down and fix. Those aren't fun but you do feel good when you finally solve them.

Looking forward to: improving Mesa's device driver interface to better support 3D hardware.

In terms of the big picture, I'm looking forward to the day when I can go down to the local computer store, buy one or more of the latest graphics cards, find Linux drivers in the box, plug them all into my Linux box and seeing fast, full-featured, multi-head applications (games, VR sims, etc). And knowing that I had a hand in making it happen.

Response to John Carmack's call
by _jthm

What are your feelings, and responses, to John Carmack's recent comments in his .plan requesting an "Independant OpenGL conformance nazi" - "I think there is a strong need for a proactive, vendor-neutral OpenGL watchdog, or even a small group, especially in the linux space."

Brian:

I replied to this on the glx-dev mailing list. I agree with him. We need to strive for quality.

Engineering Applications
by EXTomar

I know that most people are interested in MesaGL for their gaming needs, but I want you to know that there are some of us who use your team's work for engineering applications and I might say, it works rather well. :-) How do you feel about any company who uses your team's work for these engineering applications, especially since they are often close source and usually have a high price tag?

ps. If Mr. Paul or any other MesaGL team members are interesting in seeing some of this work, please let me know. I would be more than happy to show you some examples. :-)

Brian:

Personally, I'm more interested in 3D applications like visualization, CAD, visual sim, etc. than games. My first real job was in scientific visualization at the U. of Wisconsin. It was really rewarding to work on software used by scientists trying to better understand the world. I think games are great but I get a lot more satisfaction from hearing about scientists and professionals using Mesa to do their work than people using Mesa to play games.

And I do appreciate the game industry for pushing the 3D technology. If it weren't for huge gaming market we wouldn't have the amazingly fast and cheap hardware we have now.

I'd also like to point out that if games were the only real use of 3D we might all be happy with simple full-screen hardware drivers. It's the non-game applications which demand 3D in an X window.

The Next Step in 3D Building Blocks
by StormCaller

A little while back, John Carmack made a comment in Next Generation about future 3D technologies, discussing alternates to NURBS such as displacement mapping and subdivision surfaces. Basically a polygons vs NURBS vs voxels etc sort of thing and which technology would be the next big thing. What's your take on that, specifically, are NURBS the future, or are there other technologies that would be just as viable?

Brian:

NURBS? Yawn. I think image-based rendering is where it's at. If you've been following developments in the graphics field for the past few years you'll be familiar with this.

Basically, image-based rendering takes images captured from the real world and processes them so they may be resynthesized into virtual environments. Paul Debevec, for example has shown some really amazing results at recent SIGGRAPHs.

I think hardware accelerated image-based rendering is in our future. I don't have time to elaborate but I've had a few ideas about what could be done. It should be really exciting.

This week's interview guest is Brian Paul. He's one of those quiet "background" Open Source deveoplers you hardly ever hear about. But if you're a gamer, game author or have had other reasons to deal with OpenGL in Linux or free software development, you've probably used Mesa, which has been Brian's "baby" since the project started in 1993. One question per post, please. We'll send the top 10 - 15 quetsions to Brian Tuesday and post his answers Friday.

This week's interview guest is Brian Paul. He's one of those quiet "background" Open Source deveoplers you hardly ever hear about. But if you're a gamer, game author or have had other reasons to deal with OpenGL in Linux or free software development, you've probably used Mesa, which has been Brian's "baby" since the project started in 1993. One question per post, please. We'll send the top 10 - 15 quetsions to Brian Tuesday and post his answers Friday.

physic writes "Brian Paul, the maintainer and original author of the free OpenGL library called Mesa. will be joining Precision Insight to work on Linux/Mesa fulltime. Mesa is best know to the linux gaming community as the library that allows Quake3 to run under linux on 3dfx, nVidia TNT2, and Matrox G200/400 video cards. "

An anonymous reader sent us Minutes from the OpenGL on Linux BOF from SIGGRAPH 99. Lots of interesting tidbits about the future of hardware and application support. Mentions Mesa, 3dfx, and more.

Emil writes wrote in to tell us that that John Carmack ^[?] has donated $10k to Mesa ^[?] to assist in the development of optimized 3d drivers for release with Mesa 3.1. Very cool. You can find out more about Id or check out The Mesa Website. Update: 05/13 04:24 by H :In somewhat related news, RealTime wrote to say "Precision Insight (the people funded partly by RedHat?) have made available their design documents for the 3D Direct Rendering Infrastructure for XFree86. The final package will be released under an XFree86 style license. "