Mesa 10.2 Improves Linux's Open-Source Graphics Drivers
An anonymous reader writes "Mesa 10.2 was introduced this week as the new shining example of what open source graphics (and open source projects in general) are capable of achieving. The latest release of this often underrepresented open source graphics driver project has many new OpenGL and driver features including a number of new OpenGL 4 extensions. The reverse-engineered Freedreno driver now poses serious competition to Qualcomm's Adreno driver, an OpenMAX implementation was added for Radeon video encoding support, Intel Broadwell support now works better, the software rasterizer supports OpenGL 3.3, and many other changes are present."
While I'm pleased to see a longstanding opensource project is alive & well, I'm not sure if it's really relevant anymore.
Slashdotter, what say you?
Pain is merely failure leaving the body
One day we'll be able to alt-tab in and out of over ten-year-old games!
That's fine, they don't really sell new games anymore. They sell subscriptions to services that resemble games.
When you aren't running the one antique kernel reluctantly supported by the vendor, that starts to look like progress...
The price paid for going FOSS is more obvious on the desktop, at least if you need more punch than Intel is going to provide, since Nvidia and AMD both offer something resembling real support to proprietary customers; but once you go mobile, the state of binary drivers goes downhill fast. X drivers are more the exception than the rule, and Android drivers might go from being frozen in the 12th century to being frozen in the 15th century at some point in the product's life, if luck is on your side.
I've been following Mesa's development for some time while working on some cross-platform 3D graphics stuff.
Right now Mesa's OpenGL implementation for Intel HD Graphics 4000+ is probably more complete than the Windows driver's. This isn't exactly a trivial accomplishment. A working OpenGL 3.3 implementation is more than what Apple offered for a long time.
Some GL features are obviously not as well optimized in Mesa, but many of them are so bad they're at least "considered harmful" anyway. And with 10.2 we got gems like ARB_buffer_storage, which basically removes the API overhead from accessing the GPU's memory. No more unpredictable stalls while writing data!
Oh man. That's so damn true if I had mod points I'd have to +1 ya even if you are anon.
Unless your graphics driver provides a full 3D stack (userspace GL libraries down to kernel drivers) you will be using Mesa on Linux. You are probably thinking of Mesa as purely a software renderer whereas it is also used as a frontend to open source 3D drivers and uses DRI to provide access to the hardware's acceleration.
I've yet to see binary any drivers use Mesa.
Then why post on slashdot? Perhaps neowin is better for you?
But MESA isn't OpenGL 4.0 compliant yet and that "ARB_buffer_storage" extension is from OpenGL 4.4.. How is it likely that somehow will write an hybrid application that supports OpenGL 3.3 (or 3.1) plus that one mismatched extension?
Then, maybe Ivy Bridge and some cards are supported under OpenGL 3.3 but you need to upgrade to a very recent linux distro (unless you like manual installations or unoffical sources) and then crucially, Sandy Bridge only supports OpenGL 3.1. So your application or game will target OpenGL 3.1 unless you can afford to exclude millions potential users.
tl;dr you are optimistic, and some real progress is made, but these things will still take monthes/years to get usable and/or working.
But MESA isn't OpenGL 4.0 compliant yet and that "ARB_buffer_storage" extension is from OpenGL 4.4.. How is it likely that somehow will write an hybrid application that supports OpenGL 3.3 (or 3.1) plus that one mismatched extension?
Quite likely, because that's the way the extension system works.
Fuck off Michael Larabel
Development takes time, and GPUs are still advancing pretty fast. Targeting fresh features isn't a bad idea.
That specific feature isn't very fresh, anyways. It lets the application, or "client" keep memory mapped while GL is using it. Almost all maintained drivers implemented it pretty fast since hardware support has existed for a long time. It's more or less how the drivers were working internally; there simply was no client API for it.
The extension works with 10.2.0-rc4 from Debian experimental, by the way. Beautifully. I guess the Mesa developers actually mean it when they say they've implemented something.