Slashdot Mirror

The ATI drivers for Linux were never perfect, but they worked decently. But ATI/AMD would drop support for older chips that were still in use. The open source community never provided a shim to let these older drivers work with newer builds of X.

Does open sourcing the drivers really fix the compatibility problem? To me, not building a shim suggests a general lack of caring about ATI drivers. Do we really need the source to give a future to aging ATI/AMD chips?

As of January 19 phoronix, puts the average speed of the latest available open-source driver at roughly 70% the speed of the Catalyst driver before the pre-R600 support was discontinued in early 2009. This is using composite results from the ATI Radeon X1800XL, Radeon X1800XT, and X1950PRO graphics cards being benchmarked on Nexuiz, Warsow, OpenArena, World of Padman, and Urban Terror. These cards use the R300g driver. Newer cards using the R600g driver (cards with HD in the name) are not currently anywhere near these results.

A bit of history:

A long time ago, documents describing the specifications of graphics cards were generally available under NDA to XFree86 developers. Then Nvidia started releasing binary only drivers. ATI eventually followed suite. The last series with docs available from this era is ATI's R200. The R300 released in 2002 did not have docs released for it. Following the lack of docs, driver development stagnates.

April 6, 2004 XFree86/X.org fork.
After Keith Packard was kicked out of the XFree86 core group and XFree86 switched to non-gpl compatible license a fork ensues. Project Leadership of XFree86 had been basically hostile to developers and had retarded increases in the developer base and improvements in the graphics stack for literally years. Following the fork a renaissance in X Server development begins.

July 24, 2006 AMD acquires ATI.
Speculation about open drivers begin.

May 10, 2007 Red Hat Summit
AMD's Henri Richard says something about improving the open source drivers. Speculation becomes flood of rumors.

September 06, 2007 ATI/AMD's New Open-Source Strategy Explained
AMD announces plans to contribute specification documents and code to the open source drivers. By this time successive X.org releases have seen:

• Removal of XIE, PEX and libxml
• Window translucency, XDamage, Distributed Multihead X, XFixes, Composite
• EXA, major source code refactoring. Switch to autotools build system instead of Imake
• EXA enhancements, KDrive integrated, AIGLX
• Removal of LBX and the built-in keyboard driver, X-ACE, XCB, autoconfig improvements
• Input hotplug, output hotplug (RandR 1.2), DTrace probes, PCI domain support.

September 11, 2007 XDS2007 Program
The "softpipe" talk by Keith Whitwell of Tungsten Graphics is the earliest reference I can find to Gallium3D. References to Gallium3D show up on Tungsten Graphics website at approximately the same time according to internet archive. Apparently Tungsten Graphics released a softpipe driver (gallium driver for cpu) at this time, along with a "proof of concept" i915 driver.

September 12, 2007 AMD Releases 900+ Pages Of GPU Specs
RV630 Register Reference Guide and M56 Register Reference Guide.

January 04, 2008 AMD Releases Additional R600 GPU Programming Documentation
M76 and RS690 register guide weighing in at 458 and 422 pages respectavly. Contains LVTMA and i2c information not found in previous docs. LVTMA is the second digital output block on the ATI R500/

The ATI drivers for Linux were never perfect, but they worked decently. But ATI/AMD would drop support for older chips that were still in use. The open source community never provided a shim to let these older drivers work with newer builds of X.

Does open sourcing the drivers really fix the compatibility problem? To me, not building a shim suggests a general lack of caring about ATI drivers. Do we really need the source to give a future to aging ATI/AMD chips?

As of January 19 phoronix, puts the average speed of the latest available open-source driver at roughly 70% the speed of the Catalyst driver before the pre-R600 support was discontinued in early 2009. This is using composite results from the ATI Radeon X1800XL, Radeon X1800XT, and X1950PRO graphics cards being benchmarked on Nexuiz, Warsow, OpenArena, World of Padman, and Urban Terror. These cards use the R300g driver. Newer cards using the R600g driver (cards with HD in the name) are not currently anywhere near these results.

A bit of history:

A long time ago, documents describing the specifications of graphics cards were generally available under NDA to XFree86 developers. Then Nvidia started releasing binary only drivers. ATI eventually followed suite. The last series with docs available from this era is ATI's R200. The R300 released in 2002 did not have docs released for it. Following the lack of docs, driver development stagnates.

April 6, 2004 XFree86/X.org fork.
After Keith Packard was kicked out of the XFree86 core group and XFree86 switched to non-gpl compatible license a fork ensues. Project Leadership of XFree86 had been basically hostile to developers and had retarded increases in the developer base and improvements in the graphics stack for literally years. Following the fork a renaissance in X Server development begins.

July 24, 2006 AMD acquires ATI.
Speculation about open drivers begin.

May 10, 2007 Red Hat Summit
AMD's Henri Richard says something about improving the open source drivers. Speculation becomes flood of rumors.

September 06, 2007 ATI/AMD's New Open-Source Strategy Explained
AMD announces plans to contribute specification documents and code to the open source drivers. By this time successive X.org releases have seen:

• Removal of XIE, PEX and libxml
• Window translucency, XDamage, Distributed Multihead X, XFixes, Composite
• EXA, major source code refactoring. Switch to autotools build system instead of Imake
• EXA enhancements, KDrive integrated, AIGLX
• Removal of LBX and the built-in keyboard driver, X-ACE, XCB, autoconfig improvements
• Input hotplug, output hotplug (RandR 1.2), DTrace probes, PCI domain support.

September 11, 2007 XDS2007 Program
The "softpipe" talk by Keith Whitwell of Tungsten Graphics is the earliest reference I can find to Gallium3D. References to Gallium3D show up on Tungsten Graphics website at approximately the same time according to internet archive. Apparently Tungsten Graphics released a softpipe driver (gallium driver for cpu) at this time, along with a "proof of concept" i915 driver.

September 12, 2007 AMD Releases 900+ Pages Of GPU Specs
RV630 Register Reference Guide and M56 Register Reference Guide.

January 04, 2008 AMD Releases Additional R600 GPU Programming Documentation
M76 and RS690 register guide weighing in at 458 and 422 pages respectavly. Contains LVTMA and i2c information not found in previous docs. LVTMA is the second digital output block on the ATI R500/

The ATI drivers for Linux were never perfect, but they worked decently. But ATI/AMD would drop support for older chips that were still in use. The open source community never provided a shim to let these older drivers work with newer builds of X.

Does open sourcing the drivers really fix the compatibility problem? To me, not building a shim suggests a general lack of caring about ATI drivers. Do we really need the source to give a future to aging ATI/AMD chips?

As of January 19 phoronix, puts the average speed of the latest available open-source driver at roughly 70% the speed of the Catalyst driver before the pre-R600 support was discontinued in early 2009. This is using composite results from the ATI Radeon X1800XL, Radeon X1800XT, and X1950PRO graphics cards being benchmarked on Nexuiz, Warsow, OpenArena, World of Padman, and Urban Terror. These cards use the R300g driver. Newer cards using the R600g driver (cards with HD in the name) are not currently anywhere near these results.

A bit of history:

A long time ago, documents describing the specifications of graphics cards were generally available under NDA to XFree86 developers. Then Nvidia started releasing binary only drivers. ATI eventually followed suite. The last series with docs available from this era is ATI's R200. The R300 released in 2002 did not have docs released for it. Following the lack of docs, driver development stagnates.

April 6, 2004 XFree86/X.org fork.
After Keith Packard was kicked out of the XFree86 core group and XFree86 switched to non-gpl compatible license a fork ensues. Project Leadership of XFree86 had been basically hostile to developers and had retarded increases in the developer base and improvements in the graphics stack for literally years. Following the fork a renaissance in X Server development begins.

July 24, 2006 AMD acquires ATI.
Speculation about open drivers begin.

May 10, 2007 Red Hat Summit
AMD's Henri Richard says something about improving the open source drivers. Speculation becomes flood of rumors.

September 06, 2007 ATI/AMD's New Open-Source Strategy Explained
AMD announces plans to contribute specification documents and code to the open source drivers. By this time successive X.org releases have seen:

• Removal of XIE, PEX and libxml
• Window translucency, XDamage, Distributed Multihead X, XFixes, Composite
• EXA, major source code refactoring. Switch to autotools build system instead of Imake
• EXA enhancements, KDrive integrated, AIGLX
• Removal of LBX and the built-in keyboard driver, X-ACE, XCB, autoconfig improvements
• Input hotplug, output hotplug (RandR 1.2), DTrace probes, PCI domain support.

September 11, 2007 XDS2007 Program
The "softpipe" talk by Keith Whitwell of Tungsten Graphics is the earliest reference I can find to Gallium3D. References to Gallium3D show up on Tungsten Graphics website at approximately the same time according to internet archive. Apparently Tungsten Graphics released a softpipe driver (gallium driver for cpu) at this time, along with a "proof of concept" i915 driver.

September 12, 2007 AMD Releases 900+ Pages Of GPU Specs
RV630 Register Reference Guide and M56 Register Reference Guide.

January 04, 2008 AMD Releases Additional R600 GPU Programming Documentation
M76 and RS690 register guide weighing in at 458 and 422 pages respectavly. Contains LVTMA and i2c information not found in previous docs. LVTMA is the second digital output block on the ATI R500/

The ATI drivers for Linux were never perfect, but they worked decently. But ATI/AMD would drop support for older chips that were still in use. The open source community never provided a shim to let these older drivers work with newer builds of X.

Does open sourcing the drivers really fix the compatibility problem? To me, not building a shim suggests a general lack of caring about ATI drivers. Do we really need the source to give a future to aging ATI/AMD chips?

As of January 19 phoronix, puts the average speed of the latest available open-source driver at roughly 70% the speed of the Catalyst driver before the pre-R600 support was discontinued in early 2009. This is using composite results from the ATI Radeon X1800XL, Radeon X1800XT, and X1950PRO graphics cards being benchmarked on Nexuiz, Warsow, OpenArena, World of Padman, and Urban Terror. These cards use the R300g driver. Newer cards using the R600g driver (cards with HD in the name) are not currently anywhere near these results.

A bit of history:

A long time ago, documents describing the specifications of graphics cards were generally available under NDA to XFree86 developers. Then Nvidia started releasing binary only drivers. ATI eventually followed suite. The last series with docs available from this era is ATI's R200. The R300 released in 2002 did not have docs released for it. Following the lack of docs, driver development stagnates.

April 6, 2004 XFree86/X.org fork.
After Keith Packard was kicked out of the XFree86 core group and XFree86 switched to non-gpl compatible license a fork ensues. Project Leadership of XFree86 had been basically hostile to developers and had retarded increases in the developer base and improvements in the graphics stack for literally years. Following the fork a renaissance in X Server development begins.

July 24, 2006 AMD acquires ATI.
Speculation about open drivers begin.

May 10, 2007 Red Hat Summit
AMD's Henri Richard says something about improving the open source drivers. Speculation becomes flood of rumors.

September 06, 2007 ATI/AMD's New Open-Source Strategy Explained
AMD announces plans to contribute specification documents and code to the open source drivers. By this time successive X.org releases have seen:

• Removal of XIE, PEX and libxml
• Window translucency, XDamage, Distributed Multihead X, XFixes, Composite
• EXA, major source code refactoring. Switch to autotools build system instead of Imake
• EXA enhancements, KDrive integrated, AIGLX
• Removal of LBX and the built-in keyboard driver, X-ACE, XCB, autoconfig improvements
• Input hotplug, output hotplug (RandR 1.2), DTrace probes, PCI domain support.

September 11, 2007 XDS2007 Program
The "softpipe" talk by Keith Whitwell of Tungsten Graphics is the earliest reference I can find to Gallium3D. References to Gallium3D show up on Tungsten Graphics website at approximately the same time according to internet archive. Apparently Tungsten Graphics released a softpipe driver (gallium driver for cpu) at this time, along with a "proof of concept" i915 driver.

September 12, 2007 AMD Releases 900+ Pages Of GPU Specs
RV630 Register Reference Guide and M56 Register Reference Guide.

January 04, 2008 AMD Releases Additional R600 GPU Programming Documentation
M76 and RS690 register guide weighing in at 458 and 422 pages respectavly. Contains LVTMA and i2c information not found in previous docs. LVTMA is the second digital output block on the ATI R500/

http://www.phoronix.com/scan.php?page=news_item&px=OTAyNg

http://apple.slashdot.org/story/11/02/03/1335213/Pirated-App-Sold-On-Mac-App-Store

It would appear that the good guys get trampled on too easily.

Epic released information for several years on the development of a Linux client for Unreal, which in many gamers eyes meant that any engine games would be easy to port to linux, and open up real tier-one gaming on the OS. This was all a long stream of FUD, however.
http://www.phoronix.com/scan.php?page=news_item&px=ODI1OA

Of the 27 tests that were carried out with our first Debian GNU/kFreeBSD benchmarking session, in 18 of the tests Debian GNU/Linux 32-bit was faster than Debian GNU/kFreeBSD 32-bit. However, with many of those 18 wins, the GNU/kFreeBSD results were very close to the GNU/Linux numbers. With the 64-bit versions, Debian GNU/Linux did even better and was in front 23 of the 27 times compared to 64-bit Debian GNU/kFreeBSD. These 64-bit results were certainly quite interesting and it looks like the FreeBSD kernel can be better tuned for a 64-bit environment. Debian GNU/kFreeBSD 64-bit though did have strong advantages with the x264, 7-Zip, and Gcrypt CEMLLIA256-ECB Cipher tests over the Linux kernel.

Despite the tone, that's not what the GP said. He said DirectX 9 was when it surpassed OpenGL and I'm inclined to agree. This is around 2002, when the last big OpenGL games like Neverwinter Nights and Unreal Tournament 2003 were released. Version numbers are a little irrelevant when pretty much every major game made since has chosen to use DirectX and still do. May I point you to this story from 2008 - six years later when OpenGL 3.0 finally comes out and people call it a great disappointment? And that if you port it to OpenGL 4 only people running blobs can run it because mesa doesn't support OpenGL 3/4 and so neither do any open source drivers?

Be honest and admit that the OpenGL game market has been microscopic. While certainly there are a few OpenGL games, nobody has taken a serious interest in improving OpenGL for gaming use in many, many years and the fact that OpenGL 3 and 4 exist at all is more due to workstation and CAD/CAM use than anything else. Best proven by the fact that AMD and nVidia support it in their drivers - meaning they have a business case for it, while the community lack people and interest. True, OpenGL has seen some interest lately with mobile platforms but they live on limited hardware and OpenGL ES is much more a port of OpenGL 2.x than an effort to compete with DirectX.

I don't think there can be any doubt that Microsoft puts a helluva lot more time and money into DirectX than anyone does for OpenGL. And the same goes for the drivers AMD and nVidia put a helluva lot more time and money into optimizing DirectX than they do for OpenGL. Because that's where the money is. Here's AMD in direct reply to "A single open source driver with feature-parity and equal performance to the closed source drivers would certainly satisfy all customers." and I quote Yep, it would. It would also cost more each year than our total Linux graphics revenues. I would have a tough time presenting a "we lose massive amounts of money but make people happy" plan to our executives. Nobody spends money on OpenGL unless it's a moneymaker for them, and unlike the kernel there aren't many of those.

Linux will receive support directly from Intel for Ivy Bridge, with better timing than for Sandy Bridge (whose support for Linux was notably very late): http://www.phoronix.com/scan.php?page=news_item&px=ODk3Nw

PitaBred writes:
> Token? They've been working on open source drivers for the
> GPUs ever since AMD bought ATI. What more do you want?

I want enough resources provided so that *all* the features
are documented. In particular, UVD. Bridgman says that would
take about another 12 top people (6 for UVD, 6 for other).

According to yahoo, AMD has a market cap of $6.07 Billion,
a profit margin of 19.97%, and 10,400 full time employees.
AMD can easily afford another 12 people. There is no excuse
for a company of this size not properly documenting its products.
I've seen much better/complete documentation from projects done by
1-3 guys in their garage. So how do we convince AMD's management?

Evanisincontrol writes:
> I'd be surprised if VAAPI wasn't a high priority for this driver.

Be surprised. Video decode is at the bottom of Bridgman's
priority list. We need to either change his mind or get
him more people.

But don't trust my paraphrases, read Bridgman's own words here:
http://www.phoronix.com/forums/showthread.php?t=28075&page=6

Mesa GL 2.1 is already quite kickass, with a very capable shading language and plenty of extensions covering most of the advantages of OGL 3/4. The main improvement I'd like to see is geometry shaders, which are getting close.

Phoronix released a follow up article that looks a little closer. There is XVideo support but no VA-API, XvBA, or VDPAU. But this article says that there are plans for XvBA and VA-API for the ati drivers, and work is progressing on VA-API support for gallium.

For OpenCL, the classic mesa drivers have no support and no support is planned. But gallium has some support for OpenCL (see mesa/clover), and just today the gallium support for HD 6000 series has been released. So now the HD 6000 has both classic mesa drivers and gallium drivers.

Phoronix released a follow up article that looks a little closer. There is XVideo support but no VA-API, XvBA, or VDPAU. But this article says that there are plans for XvBA and VA-API for the ati drivers, and work is progressing on VA-API support for gallium.

For OpenCL, the classic mesa drivers have no support and no support is planned. But gallium has some support for OpenCL (see mesa/clover), and just today the gallium support for HD 6000 series has been released. So now the HD 6000 has both classic mesa drivers and gallium drivers.

Phoronix released a followup article today. A driver supports X video acceleration, but no VAAPI yet. Like you said, these cards seem to be aimed at gamers, but with the prevalence of HD video content these days, I'd be surprised if VAAPI wasn't a high priority for this driver.

Compared to zfs, which is the only other quasi-mainstream filesystem that has copy-on-write (which gives snapshots for free) and data checksums, btrfs is almost always faster. Most of btrfs's slowness is due to those two features. Comparing ext4 speed to btrfs speed is not fair unless you disable both with -o nodatacow.

http://www.phoronix.com/scan.php?page=article&item=btrfs_zfs_ssd&num=1
see page 4 for btrfs random write performance, which blows away both zfs and ext4 on hdds.

Without COW and checksumming, btrfs is closer to ext4. Even so, except for applications that are reading or writing massive amounts of data, I'd rather have data integrity and SSD wear leveling and free read-only snapshots instead of maximum speed.

I'm not going to argue with you: I'll just point out that the devs in question have said they messed up and will do better about having code out and backported for Ivy Bridge.

No, this is our job, and we blew it for Sandy Bridge. We're supposed to do development well ahead of product release, and make sure distros include the necessary code to get things working (we have separate teams to do development and aid distros in backporting, though most of them can handle it by themselves these days).

This thread discusses the availability of FOSS drivers for those snazzy ARM Cortex chips found commonly in touch-screen devices.
Even if you can 'root' your Android phone, getting a 3D accelerated x.org experience is unlikely. Even Nokia's forthcoming Meego device will be a binary blob affair, I suspect.

Unlike the proprietary drivers from ATI/AMD and NVIDIA or any of the drivers on the Microsoft Windows side, it's not easy to provide updated drivers post-release in distributions like Ubuntu due to the inter-dependence on these different components and all of these components being critical to the Linux desktop's well being for all users.

That's a funny was of saying Linux doesn't have a stable ABI because its architects are crazy.

I honestly hope in five years you can all go back and laugh at articles like these, but more than likely you'll have slightly bigger version numbers and different silly names.

hurl
blech

Unlike the proprietary drivers from ATI/AMD and NVIDIA or any of the drivers on the Microsoft Windows side, it's not easy to provide updated drivers post-release in distributions like Ubuntu due to the inter-dependence on these different components and all of these components being critical to the Linux desktop's well being for all users.

That's a funny was of saying Linux doesn't have a stable ABI because its architects are crazy.

I honestly hope in five years you can all go back and laugh at articles like these, but more than likely you'll have slightly bigger version numbers and different silly names.

hurl
blech

Uh... so you install a several months old version of Linux on a brand new architecture and it doesn't work, therefore the architecture is "broken"????? There are fully 100% open source drivers available for Sandy Bridge RIGHT NOW. Phoronix (usually the purveyor of sensationalism but a voice of reason in this case) goes out of its way to detail exactly what you need to run Sandy Bridge with 100% open source code. Now... is it 100% released yet? No, but at the same time, you have to remember that SB isn't even officially for sale yet. It WILL be fully released in the next round of distro updates, and you can get all the stuff to run it right now if you are truly as l33t as you think you are. I'm just sitting back and waiting for the AMD fanboys to scream about how AMD is so wonderful and all AMD graphics work perfectly in Linux when someone gets GLX gears running on a 6000 series part in 6 months......

That depends. If I recall correctly, the port was originally being held up by legal issues surrounding the PhysX engine. Technically, the port could have been fairly simple.

AMD opened up the firmware for all their graphics cards more than 2 years ago
http://www.phoronix.com/scan.php?page=article&item=amd_microcode&num=1

I'm not sure what those things are you've pointed out
Possibly old legacy firmware images that are being kept for some reason?

Provide a stable interface.

Here NVIDIAs (you know, those who actually do the drivers) opinion on the topic:

The lack of a stable API in the Linux kernel. This is not a large obstacle for us, though: the kernel interface layer of the NVIDIA kernel module is distributed as source code, and compiled at install time for the version and configuration of the kernel in use. This requires occasional maintenance to update for new kernel interface changes, but generally is not too much work.

Srouce: phoronix interview

The Unigine tech demos look excellent, and have been used to showcase just what Linux gaming can look like.

Providing AMD isn't withholding critical documentation about their GPUs from open source driver developers, and they can actually bring the open source drivers up-to-par.

Providing AMD isn't withholding critical documentation about their GPUs from open source driver developers, and they can actually bring the open source drivers up-to-par.

What features does ZFS have that ext4 doesnt? Its a simple question, but you had to act like an ass. Good job.

Jeez, where to start? They're night and day. EXT4 has more in common with FAT32 or UFS than it does ZFS.

It's got a handful of core features, all of which are significant on their own:

* copy-on-write, so you know your data gets committed
* integral RAID-like functionality, integrated with the filesystem. This reduces overhead and eliminates the need for archaic RAID controllers (almost) entirely (complete with their shitty firmware and quirks, etc.) - just the controller, please.
* Due to the above two, eliminates the RAID5 write hole
* instant (like, a second or two) snapshotting of very large amounts of data.
* You can transparently 'piggyback' any filesystem on top of ZFS to provide said filesystem with ZFSs' protection
* Integral iSCSI provider. Nice to have with the above feature!

Shortcomings might include:
* No fdisk. IMO it's a bit of a serious limitation, but "it's not needed". Still, it can't help you recover from something like...
* The potential loss of your zpool definition file. Unlike (say) mdraid on Linux, there are no block backups within the filesystem (as far as I know) so the pool definition can tenably be lost (if you have a backup file somewhere, it's easy enough to recover, but still..)

As for the original post "not terribly fast" diss? Sorry, not buying it. They really needed to compare the performance against (say) other ZFS-based systems to show it's utility - there are a lot of people 'forced' to use solaris and or FreeBSD because it's got ZFS. Another significant thing to consider will be its maturity/stability and feature-completeness (eg. FreeBSD is a good way behind Solaris/OS/Illumos in these departments).

Finally, this is still pretty beta code. The only 'significant' not-as-good performance failure is the Postmark benchmark, which may or may not be conclusive (I don't know what it does). If you compare it to this postmark benchmark for PCBSD, it doesn't look that bad (particularly when you consider the above linked article figures are 500 points or so higher across the board than the 'new' benchmarks) - and the new implementation appears better than XFS, which is still quite a decent filesystem.

Oh, yeah - consider it's still 'beta'. Noteably, considerably more 'beta' than Butter. Consider me excited. I'm not going to jump until I get fairly certain news that it's at least as stable as the FreeBSD implementation (while requiring less 'tuning' - bah!); I can do without features if it's stable. CoW and the basic RAID-like implementation on their own is enough to jump ship for.

I tried this, but it didn't help much.

As I ran out of memory, it will throw away the disk cache (including copies of currently running programs, IIRC) until it's constantly running back to the disk to grab the next chunk of needed code or data. At any rate, I had the exact same symptoms, but perhaps more acutely. A SSD might really help this as the random access thrashing wouldn't delay I/O nearly as much..

Linked to by the article, this might address this situation: http://www.phoronix.com/scan.php?page=news_item&px=ODQ3Mw

My solution was to learn the key combination Alt-SysRq-F - this basically tells the kernel to find the process taking the most memory and kill it. Hitting this (possibly a couple times) was the only realistic way to solve the situation, as I couldn't get to a terminal (due to the system being totally unresponsive) to check the currently running processes. (see also: https://secure.wikimedia.org/wikipedia/en/wiki/Magic_SysRq_key ) Note: it might need to be enabled, though in my experience it was enabled for some of the mainstream distros.

The Linux graphics drivers are in a state of extremely heavy development at the moment, you can follow the fun here, here and here. The main Phoronix website also has a lot of articles.

The Linux graphics drivers are in a state of extremely heavy development at the moment, you can follow the fun here, here and here. The main Phoronix website also has a lot of articles.

They talk about using nouveau for NVIDIA cards... well that is really not an option for some people.

Ubuntu should NOT limit their hardware choices.

They tested in a VM. Now where's the proof that by itself doesn't affect performance in an unpredictable way?

If they test in a VM, on only one particular hardware configuration, then the results only apply to that specific test setup. If the fact that the experiments are run inside a VM introduces variability into the results, then this will show up as a large variance. However, having a larger variance does not in itself negate the results - but remember that the results can't be generalised to other configurations - they only apply to this particular setup.

In order to produce experimental results that can be generalised you need to run your experiments on a randomised configuration of hardware and VM host software. Either test every possible combination of factors - hardware, VM host sw, sw under test - (full factorial), or some subset (fractional factorial).

I'm usually one of the first to bash Phoronix for not doing multiple replicates or any statistical analysis of their experiments, but things appear to have changed this time. Some of the big criticisms of Phoronix's benchmarks in the past were that they didn't consider whether or not their results were significant - instead doing only one replicate for each configuration, plotting a barchart, and concluding "X was 5 FPS faster. Therefore it wins!" Apparently they're now doing multiple replicates and some proper statistics to calculate whether or not observed differences are actually statistically significant ("our kernel test results were automated, easily reproducible, and statistically significant"). Also the graphs are showing error bars +/- 1SD. This is good. This means that if you want to reproduce their experiments, it should be easy to do so. You can get an idea from the graphs whether a difference is significant.

(Having said that, I'm not sure why some of the data points don't have error bars - presumably the standard deviation was very low? I also can't see the number of replicates mentioned anywhere - maybe he used his "dynamic number of trials" scheme, but statistically speaking this may well be a bad thing - if he is using only 2 or 3 trials there is some probability of getting the first few samples with similar variance, he should probably stick to doing a fixed 10 to 30 replicates instead).

You're looking at a bug that was fixed some time ago but those patches didn't make it into stable kernel yet. It should be fixed for everyone in 2.6.37 (about 3 months from now as 2.6.36 came out 3 days ago). In the mean time, you can grab those patches and compile your own kernel.

Phoronix is the site that cares about that sort of thing. I can't seem to find their most recent article on Windows vs. Linux closed drivers, but I remember there being one within the last year or so.

http://www.phoronix.com/scan.php?page=category&item=Display%20Drivers

(There was still a big gap in 2007)

All I know is that nVidia is really making a killing on all the Linux graphics clusters for government/defense sims that are replacing all the older SGI and SUN workstations. And it's still even difficult for them sometimes supporting certain API and driver options and wiping out graphics glitches between releases... I can only imagine how much work ATi would have to do to get into that rather lucrative field.

I want to like ATi, but I got burned big time the last time I bought an ATi Radeon 7500 All-in-Wonder way back when, just prior to the cutoff for their initial closed driver support. Have been pretty happy paying a small premium for nVidia cards and solid Linux support ever since.

Did you know that last September Direct3D 10/11 went native on Linux ?:

http://www.phoronix.com/scan.php?page=article&item=mesa_gallium3d_d3d11

And they are putting hooks into Wine to use it.

1. I'm not sure how soon that will happen. I do see some things, but nothing which will take away that problem soon. But I can tell you, having a Windows 7 64-bit on my desk at work is a total software-compatibilty nightmare as well. There is a lot of stuff which just doesn't want to work. There is other stuff which doesn't want to work on Windows 7/Vista in general and there is stuff which doesn't run on Windows 2000 or XP anymore. So yet there is fragmentation on Linux, but Windows isn't doing so well either.

2. It's actually a 2 way street. The creators of these systems don't seem to be interrested in releasing their products for Linux.

3. That could be changing soon, because Linux recently got native Direct3D 10/11 support:

http://www.phoronix.com/scan.php?page=article&item=mesa_gallium3d_d3d11

Funny you should mention that, did you know that last September Direct3D 10/11 went native on Linux ?:

http://www.phoronix.com/scan.php?page=article&item=mesa_gallium3d_d3d11

And they are putting hooks into Wine to use it.

Don't fret, word is native ZFS is coming to Linux next month.

With kernel modesetting, it is possible to run an accelerated X without root privileges (MeeGo does this) but currently there are safety caveats. To support multiple simultaneous users there is a need for a revoke syscall otherwise other users could snoop your input devices by not dropping previous access to devices (you can watch some X devs discussing the issue on Phoronix).

There is no talk of making any codec mandatory for HTML5 video. None.

Well, there were Ogg formats in the draft HTML5 spec. But then they were pulled out because Nokia and Apple got all tantrum-y about the whole thing. Really.

Having a default video codec would mean that people could just assume that there's Ogg Theora playback... or that there's Ogg Vorbis playback. Actually, as much contention as there was about Ogg Theora, I don't understand why people couldn't just compromise on getting Ogg Vorbis stuck in there. Even implemented in software, the iPhone and other handheld hardware could decode files very easily, and at least we'd finally be on our way towards sticking a fork in MP3.

HTML5 video specifically relies on the underlying browser (or OS) to provide decoding.

By definition, yes (unless you're relying on in-the-cloud decoding or magical pixies or something...), but I digress.

Just as you can put whatever kind of image you want in an img tag and rely on the browser to render it (if it can)...

Many browsers can't handle TIFF files, or BMP files, and last I checked IE had problems with PNGs and mostly barfed on SVG...

Most browsers (ie not Firefox) pass on video decoding to the operating system.

Many browsers may do so, but Firefox still has ~ 31% of the marketshare, about twice as much as Chrome, Safari, and Opera combined (source: wikipedia).

So what I'm saying is: Don't write off Fox... or the big red dinosaur (take your pick).

As most users have OS X or Windows, for which free, licensed h.264 decoders are readily available

That's free as in 'freeware', not Free as in Freedom.

or Linux with a GPU that has a hardware (also licensed) h.264 decoder

I actually don't know the numbers on this one and I'm curious about it. What percentage of hardware shipped today (desktops, servers, handhelds, etc...) has a fully-licensed (by the MPEG-LA) hardware decoder for H.264 in it?

And I'm no lawyer, but I wouldn't put it past the MPEG-LA to sue someone for using an H.264 software decoder, even if the hardware they were running it on had a fully-licensed hardware decoder in it.

most users don't have to worry about all this licensing malarkey.

I really wish that this were true, but I'm afraid that it's not the case. Just think for a second -- the H.264 hardware is only licensed for decoding not encoding. So if you want to upload a video from your DV-cam to your website or put it in your presentation, you'll need a license to go along with whatever software you use (or you'll need to pay a fee for software that includes such a license).

I'd root for Google's standard if it didn't suck balls so much and have practically no hardware support.

I'm no codec hacker, but I thought the whole point about all of this so-called "hardware" support was that it wasn't actually baked into silicon, but was low-level code that could be loaded onto DSPs. AFAIK google has 14 vendors working on hardware support, so it's just going to take a little time for that to make it to market.

And yes, it sounds like the VP8 codec needs ongoing help to get it whipped into shape. But given that people like a few FFMpeg developers have written much faster decoders than the reference one, it sounds like that work is well underway.

Have you actually used the version included in 8.x? It's much improved -- I believe it's even considered production ready. I'm not sure how well you can compare the UFS versions between Solaris and FreeBSD so relative performance expectations between FreeBSD's ZFS and UFS seem premature. It's worth noting though that in the current version of FreeBSD, in the benchmarks that I've seen, the ZFS numbers match or exceed UFS+S/UFS+J.

http://www.phoronix.com/scan.php?page=article&item=zfs_ext4_btrfs&num=5

The other response to my above message was also pretty informative.

The part that had "no basis in reality" were the overblown statements that Phoronix was making with headlines such as:

There Is No Doubt, Steam Is Coming To Linux!

It's Official: Valve Releasing Steam, Source Engine For Linux!

Really? There is no doubt that it was coming? Secondly, how can something be official when there was no statement from Valve saying so? A one-liner in an article with an unsourced rumor is not "official".

The part that had "no basis in reality" were the overblown statements that Phoronix was making with headlines such as:

There Is No Doubt, Steam Is Coming To Linux!

It's Official: Valve Releasing Steam, Source Engine For Linux!

Really? There is no doubt that it was coming? Secondly, how can something be official when there was no statement from Valve saying so? A one-liner in an article with an unsourced rumor is not "official".

Going to the *real* source of the rumours: Phoronix. It all started in this page [phoronix.com]. And they say, quote:

No, it all started back in 2008 here when they first claimed that Steam for Linux was "confirmed".

Also, doing the ridiculous thing of answering myself, I'd like to add this forum thread (yes, Phoronix and noted by Phoronix as well):

http://www.phoronix.com/forums/showthread.php?t=23328&page=5 (page 5 is interesting, be the thread is lengthy)

So...what was that thread all about? A user on page 6 says: They could be developing the client on Linux for Mac OS X. The fact that the files have support for Linux does not mean that they actually intend to support it. The best that you can conclude that Linux users will get is unofficial support without an official announcement.

Maybe he was right. Still, I stand by my words: Something doesn't add-up here.

Going to the *real* source of the rumours: Phoronix. It all started in this page. And they say, quote:
"Valve Corporation has [...] confirmed something we have been reporting for two years: the Steam content delivery platform and Source Engine are coming to Linux"

But where is this announcement? Later on that article we have something interesting: "An announcement from Valve itself is imminent."

Yet, Valve didn't make an announcement. We've been waiting for it.

As much as it may seem that Phoronix lied with their teeth here, they do point to other more respectful sources such as Telegraph.co.uk, who also seem to confirm said announcement: "Valve has also confirmed that it will make Steam available to Linux users in the coming months. "

That's it: It's a mess.

Valve confirmed in May that they were going to bring Steam and the Source engine to Linux. I think that will make them the defacto commercial gaming platform for Linux at that time IMHO. In addition there is speculation that it will support native play of ID's games.

I don't have any Valve games currently but will purchase them when it comes to Linux.

Link to an article on it: http://www.phoronix.com/scan.php?page=article&item=valve_steam_announcement&num=1
The article also cites several news sources on the topic. Unfortunately, there is no release date. It's a "when it's done project."

Yeah, right... http://www.phoronix.com/scan.php?page=article&item=valve_steam_announcement&num=1

Slower than Windows 7: http://www.phoronix.com/scan.php?page=article&item=linux_windows_part1&num=1

Yep, here's the article.

Hopefully they're delaying Portal 2 so they can dedicate their best and brightest to port Steam and all their Source games over to Linux by the end of this summer:
http://www.phoronix.com/scan.php?page=article&item=valve_steam_announcement&num=1

I just sold my old gaming rig (Dual SMP Athlon XP-M + nVidia Geforce 6800GS), so if Valve pulls this off, I wouldn't need to buy a new Windows gaming machine to go alongside my Linux system (Dual core Athlon II + nVidia Geforce 8800GT), and would be happy to spend the money on new Steam games instead :-P

Yes, wistful thinking, I know :P