Slashdot Mirror

32-bit pointers may consume less space (unless you start using 64-bit pointers with pointer compression like newer JVMs do), but in general this is offset by the ability to use 64-bit CPU instructions which can manipulate more raw data per clock.

Most benchmarks show that 64-bit is faster than 32-bit.

Or you can see that they were trying to enable it but they want to use the DMA-BUF API to pass the buffers between the open source and proprietary driver but can't because it's GPLed.

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

The very reason it's a clusterfuck is because of the fragmentation these guys are trying to address. Each device has a different kernel, even those that use the same SoC (because the GPIOs, etc. are hardcoded). That means that the developers efforts are fragmented - only a small number of people see the bugs and put in the effort to fix them, which undermines Linus' law. 3.7 will help, but there's still a lot to be done before ARM has the kind of compatibility that x86 does.

tldr: These guys are doing useful, important work that will vastly improve the state of Linux ARM.

"The 64-bit ARM ISA is pretty interesting: it's more of wholesale overhaul than a set of additions to the 32-bit ISA."

OS based on Linux and OSS just need athat GCC supports it, which it already does, and Microsoft will only need another 12 years of rewriting^w research until they can come up with Windows RT 64.

(I stand corrected: the Linux kernel itself was up and running on ARM 64 even before GCC ofically supported it: http://www.phoronix.com/scan.php?page=news_item&px=MTIwNzU )

Uh, Linux hasn't been bad at sound for at least like 3 years now. I haven't even had any problems with high-end creative cards

Yes, for watching Movies or Listing to music, the Linux audio system is fine. Want to develop something that requires low latency like professional music software or hmmm GAMES maybe? Good luck with that under Linux's current ALSA and PulseAudio subsystems.
Read about the nightmare the WINE dev's are having with PulseAudio's massive latency:
http://www.phoronix.com/scan.php?page=news_item&px=MTEyODM

A perfect example how the pragmatists who supported OSSv4, were right all along, but still lost out to the the pony tail hippies in charge of the kernel. But we, the Linux gamers, are the real losers.

Perhaps the author of this summary could have been more precise. The bug is very unlikely to be triggered, here are some examples: https://lkml.org/lkml/2012/10/24/535 and http://phoronix.com/forums/showthread.php?74697-EXT4-Data-Corruption-Bug-Hits-Stable-Linux-Kernels&p=293446#post293446 . Indeed is a good measure to downgrade to a safe version and wait for a patch to come. I have been using the 3.6.2 on my two Gentoo boxes for a couple of days and nothing happened. As a precaution I will downgrade till they release such fix.

Look at the Phoronix benchmarks. Vishera beats the 3770k in many benchmarks as long as you're running multithreaded code.
http://www.phoronix.com/scan.php?page=article&item=amd_fx8350_visherabdver2&num=1
And do the math about power savings. Unless you're a folder you'll need several years to recap the additional cost of an Intel CPU.

Here are a set of benchmarks that are more centered on the Linux world from phoronix and are thus a little less prone to intel compiler discrimination. The results seem more realistic: better and worse and similar to an i7 at different work, still hard on power usage, low purchase price.

Maybe if Wayland takes off, Enlightenment can be ported to run there instead of X11

E17 has already been ported to Wayland

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

Back in 2011 Evas already runs on Wayland

https://plus.google.com/118426816251488376359/posts/AmCFdvRDj9F

E17 should be out in a few days. But even so, E17 runs on top of X11 rather than running as a replacement. Maybe if Wayland takes off, Enlightenment can be ported to run there instead of X11, but we'll have to wait to see where things go from here.

But does it run linux worth a damn? Inquiring minds want to know. I got boned by buying an Athlon 64 L110/R690M machine for which proper Linux support was never forthcoming. Now I want to see power saving and the graphics driver work before I give AMD money for more empty promises about Linux support.

They do: http://www.phoronix.com/scan.php?page=news_item&px=MTE0Mzk
It's also not hard to do it yourself: http://linuxfordummies.org/installing-the-cinnamon-desktop-environment-in-fedora-16/

NO, not in the low power segment. Here are some hard numbers from another /. article today.
http://www.phoronix.com/scan.php?page=news_item&px=MTE4NjU

CPU Model Performance TDP Efficiency
AMD FireStream9370 - 52 / 225 / 2.35
Intel Atom N570 - 6.7 / 8.5 / .79
ARM Cortel-A9 - 2 / 0.5 / 4

As you can see in the low power domain, ARM is still more that 4x as efficient and uses 17x less much power than Intel.

Phoronix

(Note the clockspeed advantage)

Here you go:

New XWayland Protocol Published

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

Maybe it's intentional, maybe it's not

It's probably intentional that Apple haven't gone out of their way to make sure that Linux Just Works(TM) on their machines. They probably don't care that much about Linux-on-Macs one way or the other; I doubt they'd go out of their way to make it work or to make it not work.

but it does seem to be a trend.

I'm not sure there's a long-term trend to make it harder. It might have gotten a bit easier after the switch to x86, with more use of standard rather than custom glue chips.

And, if you actually look at the intel-gfx thread pointed to by the Phoronix article, and follow that into the Linux kernel mailing list, it might just have been a bug or, at least, unnecessary (mis)feature that was subsequently fixed/removed.

The Phoronix article also linked to a blog post about a non-Apple laptop that needed a bit of help to boot Debian from a USB installation and didn't support all the hardware, so it's not as if "not entirely happy to run Linux" is an Apple-only problem.

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

Maybe it's intentional, maybe it's not, but it does seem to be a trend.

Why can't you have the integrated graphics render most things, and your games/cad software using a discrete card when they need it?

Because until a couple weeks ago, NVIDIA refused to make that technique (which it calls Optimus) possible on a GNU/Linux operating system.

Phoronix ran benchmarks of all the popular Window Manager and Desktop Environments, that included: Kwin (KDE), Mutter (Gnome-Shell), XFCE and Unity. Guess who came out on top, in terms of performance?

XFCE won, with Mutter (Gnome-Shell) a very close second. The conclusion was, XFCE and Gnome 3 performed best across a wide variety of graphic drivers.

Hopefully that will change soon with the reverse engineering effort underway: http://www.phoronix.com/scan.php?page=news_item&px=MTE3NTE

To provide some better links to actual games...
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=6 Open arena
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=7 Open Arena 0.8.8
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=8 Prey 1.4
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=9 Quake $ V1.4 didn't even run with the opensource drivers..
etc etc.

So yes, there wasn't much differance in lightsmark, but plenty in other apps.

To provide some better links to actual games...
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=6 Open arena
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=7 Open Arena 0.8.8
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=8 Prey 1.4
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=9 Quake $ V1.4 didn't even run with the opensource drivers..
etc etc.

So yes, there wasn't much differance in lightsmark, but plenty in other apps.

To provide some better links to actual games...
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=6 Open arena
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=7 Open Arena 0.8.8
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=8 Prey 1.4
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=9 Quake $ V1.4 didn't even run with the opensource drivers..
etc etc.

So yes, there wasn't much differance in lightsmark, but plenty in other apps.

To provide some better links to actual games...
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=6 Open arena
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=7 Open Arena 0.8.8
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=8 Prey 1.4
http://www.phoronix.com/scan.php?page=article&item=amd_r600g_compete12&num=9 Quake $ V1.4 didn't even run with the opensource drivers..
etc etc.

So yes, there wasn't much differance in lightsmark, but plenty in other apps.

Nobody cares if GNOME3 *EVER* can run on BSD. Last I heard they weren't "discussing" making systemd mandatory - they were dictating it.

Systemd and its dependencies add 2 million lines of code to the early boot process, which on the face of it is a pretty gratuitous burden and negatively affects reliability. It's about 200 times as many lines to support as simple init scripts.

Pretty much any other DE/WM can run on BSD, and many of them are far superior to GNOME3.

About this much (unless they radically improved in 2 months)

You might want to keep an eye on compatibility here:

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

Personally, paying the extra cost for anything Mac and then not running the OS custom tailored to the hardware would not cross my mind. Well, not again, not after my failed experiments with my late 2009 MacBook Pro.

Holy crap:

A lot of reasons people have been using this view are due to the other two views sucking for various reasons ... The role for compact view is unclear. Our research suggests that it is something like: the only view that works for browsing a lot of files at once. This is really hard to reconcile with providing good defaults that just work and having consistency with the file chooser.

So you admit people are using the view, it works best for browsing lots of files, and somehow, this means the reason for existence is unclear somehow so you should delete it because you don't use it yourself?

Meanwhile, they try to circle the wagons and discuss what to do to address an issue of dwindling support:
http://www.phoronix.com/scan.php?page=news_item&px=MTE0ODg
Their conclusion including how to address brain drain and exodus of users? *MORE* Gnome 3, stop thinking about the desktop paradigm as much and make it more different, and Gnome hasn't taken over *enough* and needs to be its own OS.

Oh well, guess GNOME will descend into oblivion. They had some neat aspects in Gnome 3, but it's just so hard to deal with some of the intended design choces that they clearly have no intention of revisiting.

Addendum:

Just as an example of the involvement of Intel in speeding up the OpenGL 4.3 / OpenGL ES 3.0, this just in at Phoronix:
http://www.phoronix.com/scan.php?page=news_item&px=MTE1Njg

OpenGL ES 3.0 announced by Intel for the opensource drivers for their next generation of graphic cards (currently still alpha quality), and should became available during the first quarter of next year.

Okay, it's not the full OpenGL 4.3 specs, it's only the ES 3.0 subset of it, there still some work to go. But, thanks to the modular architecture of Mesa/Gallium3D this front end is insta-magically available to any back-end exposing the necessary hardware features.

That means that potentially 2013 will not only see support for OpenGL ES 3.0 for Intel HD, but also for older Intel hardware (thanks to Google) or AMD hardware (thanks to their opensource initiative) or Nvidia hardware (no thanks to Nvidia. Fuck you ((c) by Linus), but thanks to the countless reverse engineers), as long as said developers expose the corresponding hardware functionality in their drivers. (And same for the embed chips running Gallium3D based opensource drivers, like Mali on Lima, Freedno on Qualcomm, etc.)

Pour enough resources on it, and full Open GL 4.3 becomes realistic within 2013. (Intel/VMware, Valve, AMD, Google, ... I'm looking at you !)

Now as a scientist, I would enjoy to see some love given to the OpenCL front end too.
(It's not lagging that much behind API-wise because OpenCL is a rather recent standard too. But it's not stable enough and some back-end aren't yet able to use it.
On the other hand, this has some efforts paid by Google and even Pathscale).

And I would guess that a few Linux Gamers would like to see the DX10/DX11 front-end some more serious development beyond the proof of concept stage.

It's not the stated reason that matters. It would be too hard politically to pass such a change without a massive debate that would drain a giant amount of time from everyone involved. And here, we have a sane choice done over some easily fixable detail (recompressing everything as .xz, already in progress, would allow Gnome3 to fit).

Great kudos to Joey Hess. And if you have doubts he's right, consider what Linus said a year ago. Or, take a look at recent Slashdot, Phoronix, or even gnome.org articles.

For the ARM Mali T6xx Linux enablement, they are only using a DRM driver for driving the display controller while they have their own separate kernel driver for poking and handling the GPU itself. ARM though isn't being too open-source friendly in terms of a fully open stack or providing proper documentation.

Good grief.

This isn't the first time that the Nvidia driver has had serious security vulnerabilities. It also happened in 2006:

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

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

Good luck getting real open source drivers out of Nvidia, ATI/AMD, and Intel for their graphics hardware.

Intel develops open source drivers for their graphics hardware. See for yourself on their Intel Linux Graphics website. Intel worked with Valve recently to improve their drivers for Valve's games. Phoronix has some statistics on the development history of Intel's open source drivers.

And please, no pretending that X on Linux doesn't crash. It does, and this is the 4th time I've restarted this laptop today. Hanging hard with VirtualBox.

That's not X hanging, that's VirtualBox hanging.

Valve?

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

They might be slow, but:
- They *DO* end up releasing specs. (Although after a long time in legal checks before getting approved for release).
- They do *PAY* developers to write open source drivers for their GPUs.

This has ended up well nicley for them: unlike Nvidia, they have a nice opensource driver that can be ported to chinese (MIPS based) CPUs, bringing lot of money to them. (Also in five year, expect cheap chinese clones of current Radeon GPUs :-P).

(And its not the first time that the opensource driver has been useful for AMD: they have ported it for Windows Embed Compact 7).

Also if you follow news on phoronix:
AMD is working on better collaborate with the opensource world, and better keep it in mind in their production piepline. The target is to have less legal checks before releasing specs, and have more opensource friendly components (less problem with the video DRM).
The long term plan is to reach the kind of integrated opensource development that Intel is enjoying with same day support.
So in a few year, they will probably reach intel-levels of support. For now they aren't as good, but at least, unlike nvidia, they show that they put some efforts in there.

They might be slow, but:
- They *DO* end up releasing specs. (Although after a long time in legal checks before getting approved for release).
- They do *PAY* developers to write open source drivers for their GPUs.

This has ended up well nicley for them: unlike Nvidia, they have a nice opensource driver that can be ported to chinese (MIPS based) CPUs, bringing lot of money to them. (Also in five year, expect cheap chinese clones of current Radeon GPUs :-P).

(And its not the first time that the opensource driver has been useful for AMD: they have ported it for Windows Embed Compact 7).

Also if you follow news on phoronix:
AMD is working on better collaborate with the opensource world, and better keep it in mind in their production piepline. The target is to have less legal checks before releasing specs, and have more opensource friendly components (less problem with the video DRM).
The long term plan is to reach the kind of integrated opensource development that Intel is enjoying with same day support.
So in a few year, they will probably reach intel-levels of support. For now they aren't as good, but at least, unlike nvidia, they show that they put some efforts in there.

Tiny market segment? Well, that depends on whether you think more than 10 million GPUs is tiny. It could actually be in their best interest to open the programming specs for their hardware. Stranger things have happened.

Posting anon because I've already modded this thread - I've clearly been way too far out of the loop for way too long. Is this to say that ATI is now the Linux-friendly manufacturer whereas NVidia is not? I thought that in the past, NVidia had the lead by way of better drivers, better stability, and VDPAU. Did ATI/AMD leapfrog ahead or is NVidia still the better way to go when building a PC with the intention of running Linux on it?

ATI/AMD's New Open-Source Strategy Explained:
http://www.phoronix.com/scan.php?page=article&item=826&num=1

AMD Releases 900+ Pages Of GPU Specs:
http://www.phoronix.com/scan.php?page=news_item&px=NjA1Mw

AMD Releases Additional R600 GPU Programming Documentation:
http://www.phoronix.com/scan.php?page=article&item=960&num=1

AMD Releases 3D Programming Documentation:
http://www.phoronix.com/scan.php?page=article&item=amd_tcore_release&num=1

Posting anon because I've already modded this thread - I've clearly been way too far out of the loop for way too long. Is this to say that ATI is now the Linux-friendly manufacturer whereas NVidia is not? I thought that in the past, NVidia had the lead by way of better drivers, better stability, and VDPAU. Did ATI/AMD leapfrog ahead or is NVidia still the better way to go when building a PC with the intention of running Linux on it?

ATI/AMD's New Open-Source Strategy Explained:
http://www.phoronix.com/scan.php?page=article&item=826&num=1

AMD Releases 900+ Pages Of GPU Specs:
http://www.phoronix.com/scan.php?page=news_item&px=NjA1Mw

AMD Releases Additional R600 GPU Programming Documentation:
http://www.phoronix.com/scan.php?page=article&item=960&num=1

AMD Releases 3D Programming Documentation:
http://www.phoronix.com/scan.php?page=article&item=amd_tcore_release&num=1

Posting anon because I've already modded this thread - I've clearly been way too far out of the loop for way too long. Is this to say that ATI is now the Linux-friendly manufacturer whereas NVidia is not? I thought that in the past, NVidia had the lead by way of better drivers, better stability, and VDPAU. Did ATI/AMD leapfrog ahead or is NVidia still the better way to go when building a PC with the intention of running Linux on it?

ATI/AMD's New Open-Source Strategy Explained:
http://www.phoronix.com/scan.php?page=article&item=826&num=1

AMD Releases 900+ Pages Of GPU Specs:
http://www.phoronix.com/scan.php?page=news_item&px=NjA1Mw

AMD Releases Additional R600 GPU Programming Documentation:
http://www.phoronix.com/scan.php?page=article&item=960&num=1

AMD Releases 3D Programming Documentation:
http://www.phoronix.com/scan.php?page=article&item=amd_tcore_release&num=1

Posting anon because I've already modded this thread - I've clearly been way too far out of the loop for way too long. Is this to say that ATI is now the Linux-friendly manufacturer whereas NVidia is not? I thought that in the past, NVidia had the lead by way of better drivers, better stability, and VDPAU. Did ATI/AMD leapfrog ahead or is NVidia still the better way to go when building a PC with the intention of running Linux on it?

ATI/AMD's New Open-Source Strategy Explained:
http://www.phoronix.com/scan.php?page=article&item=826&num=1

AMD Releases 900+ Pages Of GPU Specs:
http://www.phoronix.com/scan.php?page=news_item&px=NjA1Mw

AMD Releases Additional R600 GPU Programming Documentation:
http://www.phoronix.com/scan.php?page=article&item=960&num=1

AMD Releases 3D Programming Documentation:
http://www.phoronix.com/scan.php?page=article&item=amd_tcore_release&num=1

Yup, to the tune of a couple 100 million: http://www.phoronix.com/scan.php?page=news_item&px=MTEyNTE

Funny you should mention that right when AMD wins a huge order of graphic chips precisely because they have open source drivers.

And anecdotally, I've never had a problem with AMD hardware, generally by the time the proprietary driver loses support, the open source one matches its performance.

I didn't see any mention of opening the 3D graphics drivers or video acceleration.

AMD GPU have had open specifications for a long time now. The OpenCL backend based on llvm was recently committed by an AMD developer. Phoronix has been tracking these developments rather well. http://www.phoronix.com/scan.php?page=news_item&px=MTA5MTk

This LLVM back-end for R600g has been one of the items that AMD's open-source team has been working on for several months. In early December was when the R600g LLVM back-end was published. This LLVM implementation is needed for OpenCL on Radeon hardware, among other purposes.

Nvidia did most of this with their cuda stuff already...

CUDA Frontend: http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTU
Nvidia PTX Backend: http://www.phoronix.com/scan.php?page=news_item&px=MTA5MzM

The missing nvidia part is currently provided by GDEV (the opensource device driver) https://github.com/shinpei0208/gdev

Nvidia did most of this with their cuda stuff already...

CUDA Frontend: http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTU
Nvidia PTX Backend: http://www.phoronix.com/scan.php?page=news_item&px=MTA5MzM

The missing nvidia part is currently provided by GDEV (the opensource device driver) https://github.com/shinpei0208/gdev

searching find this: http://www.phoronix.com/scan.php?page=news_item&px=OTYyNw

This means that for the Linux 3.1 kernel we could see the Cedar Trail graphics code merged, but more than likely it will still not be accelerated and only just be useful for kernel mode-setting. Before the Cedar Trail hardware is even publicly released we'll see the Linux 3.2 kernel and possibly even the Linux 3.3 release, so at least there's more time to hopefully better the open-source Cedar Trail capabilities.

so, looks like its still not ready for prime time yet.

Actually it costs them more to develop their own binary drivers in house, than it would to open source them and allow third parties (including the kernel devs) to take up some of the slack...

No, it wouldn't and even AMD agrees on this. Between licensed code, patents, DRM and a host of other reasons an OSS driver could not fulfill their customers' requirements on Windows. That is to say OEMs who have obligations to Microsoft who have obligations to the MAFIAA, not you. Not to mention the FPS junkies would probably not enjoy the performance hit because the third party IP would have to be ripped out.

Effectively you can either share closed cross-OS code like the Catalyst/nVidia driver does, or you can share open source code with the rest of the Linux community. Those two options are mutually exclusive, and no the those few bits you get from the community are no replacement for the 90-95% "free" cross-OS work the closed driver gives them. What you say is only true if you could flip the switch from "closed" to "open" and have everything you had before plus some more free work.

In a technical, nerdy sense you of course could do that since code doesn't magically break or become useless by publishing it. But legally that is impossible, they'd get sued to hell and their permissions to play any kind of DRM'd media would go away and with it any rights to be in a "designed for Windows $foo" sticker machine. How bad is that? Well, I'll let Bridgman that handles the open source OSS driver answer that, this isn't an official statement or anything just a forum post but:

If the worst case was as minor as not being able to release any more specs we wouldn't be worrying so much. The kind of risks we are worrying about are much larger, ie things which would either kill or cripple our graphics business.

Worst case is that we lose the ability to sell our products into the Windows market as a result of releasing info which results in our DRM implementation no longer being considered sufficiently robust. Without the Windows market (which is >90 % of our revenues) we would, for all practical purposes, cease to exist as a GPU manufacturer, especially since we would probably lose the Mac market at the same time.

Next worst case is that we find a way to continue shipping into the Windows market but get sued under one or more of the DRM-related agreements we have signed. These all have high dollar-value penalties, again enough to significantly impact our ability to continue operating.

There are a bunch of smaller risks but we spend proportionally less time worrying about them. What makes all this complicated is that we have to consider not just the information we release but the information which is likely to be reverse-engineered and published. Each time we release information we simply raise the bar for where reverse engineering starts, and it's the combination of released plus "likely to be reverse-engineered" info that we need to consider.

If we tripped any of these risks then the impact would not only affect the GPUs we are shipping today but anything we have in the pipe. Best guess is that we would lose the next generation (ie the one after 7xx) and see significant delays in the one after that.

Since we don't want that to happen (right ?) the alternative is to trim back the information we release until it appears safe, going through the review process each time until we find an appropriate level.

That's the consequences of open sourcing the binary driver, could it get much clearer?