Slashdot Mirror
Mesa 9.0 Released With Open Source OpenGL 3.1 Drivers
An anonymous reader writes "The Mesa developers released Mesa 9.0 with open-source OpenGL 3.1 driver support. This de facto OpenGL Linux implementation now supports the several year old OpenGL 3.1 specification for Intel hardware while the other drivers are still at OpenGL 3.0 or worse. Other features to Mesa 9.0 include completing MPEG1/MPEG2 video acceleration, early OpenCL support, bug-fixes, and new hardware support."
OpenGL 3.1 support is limited to Intel hardware, but at least ATI/AMD hardware supports some of OpenGL 3.1. A few features from OpenGL 4 were also added.
Mesa same as me,
Slashdotty as I can be,
Loving software free,
Cleanshaven, save goatee.
Burma Shave
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
More and more as home computing becomes about appliances instead of about general purpose PCs and more and more, different detail markets are looking to Linux to make these things happen, video chip makers who have bet most of their business on Microsoft-only support will soon need to rethink that notion.
Long ago, no one thought IBM could be humbled. No one could have imagined Novell becoming a novelty. And no one in Windows-centric IT shops want to admit that the vast majority of internet and databases out there are running on Linux servers and services.
Things are shifting but some people aren't noticing or believing.
F* You NVidia... F* You.
I get the impression(whether this is better or worse is another question) that makers of video chipsets understand that Linux support is necessary to win certain markets(embedded Android stuff, *nix graphic workstations, compute clusters, etc.); but that "support" does not need to mean anything other than 'set of binary blobs that work with the one blessed kernel version and system configuration. If you are the purchaser of a consumer product, suck it up. If you have a suitably large enterprise support account, please contact our engineering/integration team.'
In the 'appliance' market, you aren't even supposed to touch the software, just twiddle the 'apps' on top of it, and much of the hardware(even when the components are well understood and fairly standard) is overtly hostile to tinkering. Yes, the chipset vendor had better have a Linux BSP if they want to make a sale; but(based on the state of 3rd-party Android ROMs), they definitely don't have to do it in a way that is overly helpful to 3rd parties.
In the expensive Workstation and Compute Stuff market, you have customers who will pay good money, sometimes excellent money, to Make It Work; but you also have customers used to the fact that 'Product X is only supported on RHEL Antiquated Edition with Nvidia Drivers v.Y'.
I'd like to know what the hell does matter to you if this isn't good enough nerd news.
which is totally what she said
You mean using the proprietary firmware?
(captcha: depress)
As much as I dislike binary blobs, the dirty little not-terribly-secret is that most 'peripherals' of any significant complexity have firmware, it's just a question of whether they store it onboard or have just enough in nonvolatile storage to have the blob transferred to them by their driver on power-up.
In the video case, Intel's "Video BIOS" shares flash space with the rest of the (proprietary and not very replaceable unless your board is one of the rare birds supported by coreboot) goo in your motherboard's BIOS flash chip. For whatever reason, presumably board cost, AMD's parts load firmware from their driver on power-up.
Honestly, there are really only two dividing lines that seem worth drawing: 1. If you are a true purist, you could insist 'no proprietary blobs, period.' I wish you luck; but it's a perfectly ethically cogent position. 2. If you are of a pragmatic bent, you should insist that binary blobs be redistributable with the drivers that they support. There've been some vendors, from time to time, who forbade 3rd parties(like, say, linux distributions) from redistributing unaltered copies of their device firmware in order to support the vendor's device when you first booted up. You would have to resort to ridiculous little runarounds "Download the Windows driver from foocorp.com/drivers/xyzPCI and run frmextrct.sh then copy firmware.bin..." that would eventually end up being scripted and done for you on request. That's just nonsense. There is no reason to put up with vendors who won't allow redistribution of firmware blobs to make the lives of people who own their hardware easier and more convenient...
Exactly. What good is a binary blob for a specific version of the Linux kernel, when you need to run this piece of hardware on another incompatible version, on another architecture, or, say, on another open sourced OS like, say, FreeBSD? We don't need vendor lock-in through binary blobs; Open Specs is what we need. Support can then be provided by volunteers.
cpghost at Cordula's Web.
More importantly... Nouveau is starting to become performance competitive with the Nvidia Binary Blob. As Mesa adds features and rapidly catches upto the closed drivers, it'll surpass them for performance if not features. The time is coming quickly when the drivers built into Linux will be better than the official ones.
I think that we are talking about two different things:
If you use the Free AMD/ATI graphics drivers, you get only the most basic functions unless you provide a proprietary firmware blob. (debian package containing those firmware blobs, among others).
For those device firmwares, the entire "RADEON" directory, covering all supported models(list is in the debian package, I won't clutter this post) is 260k across 41 different firmware files.
As you note, though, fglrx and Nvidia's equivalent modules(plus all the non-kernel stuff that goes into X or elsewhere) is a comparatively gigantic mass, much of which is running on the host CPU and in host memory.
I was referring only to the firmware required to make the free drivers work, which is a nasty surprise the first time you see the message on startup; but does not appear to do what the proprietary drivers do.
Both GIMP and Inkscape are far far away from Adobe products. It's worth to pay extra USD 1K for application that will save your time, brain and achieve perfect results.
Unfortunately
"It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
Mesa is an open-source implementation of the OpenGL specification - a system for rendering interactive 3D graphics.
The Mesa 3D Graphics Library
Um. What? Seriously, what?
.. the lack of usable, powerful equivalents [that don't require an engineering degree or at least mindset in order to learn how to use, like software such as Blender] to such applications as:
This
There are some shining examples [look for an audio NLE on linux and there are several very decent competitive options to programs like Vegas, Audition, Sound Forge, etc., or check out Inkscape for graphic design] as well of course, but there are various reasons why those may not be suitable solutions too [such as the multitude of choices on linux of who-knows-how-well-they're supported low-latency audio driver subsystems which may make required things like synchronous multitracking impossible with a given piece of equipment or even particular distro].
I occasionally teach uni [mostly arts] how to use graphic design / video / audio software; many can't afford Macs [where the Adobe applications and other stable equivalents already exist and credulous, uneducated users aren't even aware of or simply don't care about the walled-garden[s] that will affect what they can do with their own hardware] and among those who can't, the majority would like nothing more than to switch away from using Windows.
My observation of reasons for resistance to the adoption of linux by the sections of the populace that I deal with on a regular basis [musicians, videographers, video/audio editors, graphic artists, photographers, professional academics of many stripe[s], writers, etc.] are thus:
I have helped a number of people [including both children and seniors] switch to linux, but their usage profiles are pretty uniform: they're content consumers, not p
But as I said, there is no actual PUSH to provide alternatives to the Adobe software stack, and even many GIMP developers themselves don't view GIMP as an alternative to Photoshop so much as an entirely different thing altogether.
So what? That's the first common misconception about FLOSS and 'other' software in general. Linux does not try to be Windows replacement, GIMP does not try to be a Photoshop replacement, Evolution does not try to be an Outlook replacement and so on and on...if you stop seeing "replacements" and start seeing independent software projects instead, it will make your life easier. Sure, some or most of them have the same area of interest, but most FLOS software does not try to be a drop-in replacement, they try to make better, free software.