Disclaimer: I have never once in my life even seen BeOS, or even talked to someone who had used it, much less used it myself. This message also represents personal opinions that should not be associated with the opinions of my employer.
I am extremely suspicious of the claims that the BeOS implementation of OpenGL is so miraculous. Most of the debate surrounding those claims has centered around the extremely false claim that Windows is somehow an inefficient platform to run OpenGL on.
In fact, the vast majority of OpenGL apps see little to no overhead from Windows itself.
The same goes for the claims of how “Linux OpenGL should be faster than Windows OpenGL because Windows is so slow!” Nope, they should run at the same speed; to claim anything else is just moronic anti-MS propaganda.
Now, our OpenGL driver is an ICD. We run the same ICD on Win9x, WinNT, and Linux. As such, if we were to port it to a new OS and run on the same system architecture, well, the performance would have to be… the same! (modulo a few minor issues, but the basic performance should be identical)
All of our competitors also use an ICD driver model on Windows. Interestingly, many have chosen to not use an ICD driver model on various other OS’s (be it Linux, Mac, BeOS, whatever).
An ICD is a full implementation. Therefore, an ICD is always capable of being faster than an MCD-like driver model.
So when someone comes along and says that an MCD-like driver model (like the one on BeOS) is outperforming Windows drivers, this means one of two things:
- Gross incompetence in writing the Windows driver
- False performance claims about the MCD driver
In the case of BeOS, I am strongly leaning towards (2). Simply put, a well-engineered ICD will always be faster than an MCD.
The BeOS runtime has all these wonderfully magical SSE optimizations? No matter, an ICD could have the same ones, in fact, even better – because they’d be tuned to fit the HW in question.
MCDs also make it much harder to put extensions in the driver, especially when the runtime is supplied by another company.
As for BeOS support itself, well, I have not really seen much clamoring for it. Remember that supporting a new OS would take away resources from other areas. I know I’m already overworked; I really have no desire to see yet another responsibility piled on the backs of our SW team unless it will open up big doors for our company. Linux has the opportunity of doing that – it’s got the whole IRIX to Linux transition for workstation folks behind it, as well as the geek factor. BeOS, as far as I can tell, falls short on that standard. Remember my disclaimer? For me, BeOS is pretty much off the radar; I hear a tiny bit of news about it every few months on the Internet. (I’m not much of an alternative-OS person, if you can’t tell. I hate all forms of Unix with a passion. I only use Win2K, and I love it. Works perfectly for all my needs.)
As a small addendum: Yes, there is some overhead in running OpenGL on Windows. There are two aspects of this overhead: TLS overhead and opengl32.dll overhead. Fortunately, TLS overhead is nonexistent on WinNT and Win2K. And opengl32.dll overhead is unmeasurable except for immediate-mode applications. The opengl32.dll overhead could have been avoided by MS, I believe, but it’s hardly significant.
Another addendum: Direct3D has an MCD-like driver model. Many of the problems of D3D are problems in the MS runtime, not in vendor-supplied drivers themselves. The MCD driver model diffuses responsibility among more vendors, reducing quality. It is tempting to blame MS, but I think the problems would have happened no matter who had maintained the runtime.