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
I would like to switch away from the Windows (I already am not touching Macs unless forced to), and this nice improvement in graphical performance might just be a step in the right direction for me to do the full switch at some point. Unfortunately I still am pretty dependent on the Adobe package for graphic tools in my line of work, but I hope to see the alternatives get there fast now that Adobe has consistently been pissing on its own leg for a longer period of time. And then there are the games. Pray tell this situation will improve.
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
I hope that it doesn't stop at just Linux support. I'm actually OK with there being proprietary drivers as long as documentation is available so that we can build open drivers as well. In an ideal world all drivers are open.
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.
When I see a 2.6 MB kernel module (for fglrx; I recall Nvidia's being closer to 9 MB), my assumption is that it is mostly code that executes on the host. Code or data that gets loaded onto the peripheral can easily live in a file, or in a executable section that gets discarded after use. Given how specialized the devices are, how much translation and optimization is needed to convert application-level APIs to hardware operations, and the fact that the vendors have begged off on providing host-side source code because of NDAs with third parties, it will take a lot of evidence to convince me that the size of the binary blobs is due to peripheral code rather than (intentionally proprietary) host code.
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.
Go find a Linux driver. I think I prefer to stay Windows. Maybe you'll find someone else to help you. Maybe Mesa... THAT WAS A JOKE. Haha. FAT CHANCE. Anyway,Windows 7 is great. It's so delicious and moist.
At the level of a graphics driver, a driver for Android is pretty much necessarily a Linux driver. It is vanishingly unlikely to be an Xorg driver(which is presumably why so many of these 'run stock arm distribution on android device!' schemes end up doing something ghastly with VNC), but it will have to interact with a kernel that is largely-though-not-100% a Linux kernel.
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.
Mesa is an open-source implementation of the OpenGL specification - a system for rendering interactive 3D graphics.
The Mesa 3D Graphics Library
what the fuck is mesa?
http://en.wikipedia.org/wiki/Mesa_(computer_graphics)
why do i care?
I rather doubt you care at all.
why does this matter?
To you? I doubt it does.
oh right, this is slashdot.
apple rules!
microsoft drools!
samsung is evil!
foxconn!
obama!
timothy!
Seek help and get on medication. I am not saying this as a put down, this is advice from someone who has sought help. I now make pretty much double what I used to make before I sought help if that might help motivate you. You don't have to deal with your problems on your own, and the correct medication can make a world of difference.
Don't know something? Look it up. Still don't know? Then ask.
+1
"Good people drink good beer"
Totally "F* you" for providing a rock-stable and blazing-fast driver...
Stop trolling. NVidia was the first company to refuse to provide adequate documentation needed for developing those opensource drivers, and other companies followed. They're basically the reason why those opensource drivers are now 5 years behind the state of the art. So yeah, fuck 'em.
Oh, and their drivers are buggy as hell.
It is a software implementation of OpenGL, but it now also provides the libGL glue to various hardware acceleration drivers. So it does have a role on most Xorg systems. An exception is the Nvidia proprietary infrastructure (which replaces large portions of the normal 3D graphics stack).