I never said it was independent of Gallium - it's not. Gallium, however, is a general-purpose API for GPU libraries that is independent of OS or any particular GPU hardware, and has LLVMpipe as a working and fast software backend for machines without a GPU.

As for being independent of Mesa, Clover has never been dependent on Mesa. It just lives within the Mesa repository, because almost all GPU-related code in userspace lives in the Mesa repository. Clover and all other Gallium state trackers (with the obvious exception of the Mesa state tracker) have no dependency on core Mesa or OpenGL, and never have.

I follow Mesa and Gallium development closely and have made (and am currently making) some non-trivial contributions, so I would consider myself a fairly credible primary source here. Certainly more credible than the Wikipedia page which makes LLVMpipe look like it's still in an experimental stage (it's been stable for years now) and has a list of arbitrary "milestones" that hasn't been updated in the last year and a half.

The performance of the AMD Gallium driver is not because of Gallium - it's because of manpower. There are 2-3 paid full-time developers on the entire open source AMD graphics stack. Catalyst has easily 50 times that investment - it's only natural that it's faster and better optimized than the open source driver. On the contrary, as you can see from a few benchmarks on Phoronix and elsewhere, if an Nvidia card is reclocked properly to get around Nouveau's current lack of good power management, the performance of the nv50 and nvc0 Gallium drivers are quite competitive with Nvidia's own proprietary driver running at the same power level.

The lack of a quality OpenCL implementation also has nothing to do with Gallium and everything to do with the minimal developer interest in Clover. If someone cared enough to take an interest in Clover and actively develop it, it would work much better. Clover is still farther along than Beignet, though.

I realize that the reply I just posted is unnecessarily vague, so here is a better explanation:

* Clover has been merged to Mesa since that Phoronix article was published.

* Mesa is indeed the name of the OpenGL implementation, but the larger Mesa project contains all of Gallium and its state trackers as well. That's what's being referred to here, not the OpenGL implementation specifically.

* Wikipedia's description of Gallium isn't necessarily wrong, but it's also not the greatest. First of all, there are two working software drivers for Gallium in addition to the hardware drivers - the reference driver softpipe and the fast/practical LLVMpipe. And by "a free software library for 3D graphics device drivers", what Wikipedia really means (or what it should mean, anyway) is that Gallium is a common framework for implementing libraries that communicate with the GPU (OpenGL, OpenCL, OpenVG, VDPAU, etc.) across a wide range of hardware as well as the aforementioned software drivers.

What it comes down to is that Clover is Gallium-based, but Gallium is not exclusively for "graphics". It's for anything that uses the GPU, including GPGPU libraries like OpenCL, and has no dependency on anything graphics or display-related.

Yes, both of those references are out of date.

Clover does not depend on X11 or OpenGL. It will be able to run without a graphics card if LLVMpipe has support for it; I don't remember if it does. So yes, it can do all of those things. On the other hand, Beignet currently requires an Ivy Bridge CPU and graphics hardware.

No, you're quite wrong and he's entirely right. This has everything to do with Gallium and Mesa. Despite it sometimes being called "Gallium3D", Gallium is not just for graphics. It also supports GPU compute, specifically OpenCL, through the Clover state tracker.

You must not recognize the name of Dave Airlie - among other things, he's an active Mesa developer, one of the main X.Org developers, and the maintainer of the Direct Rendering Manager in the Linux kernel; i.e., he is the person who submits the pull requests to Linus for the graphics drivers in the kernel. Not exactly the kind of person who would get confused over the difference between OpenGL and OpenCL, or who has "no clue" what he's talking about.

Dave Airlie is right. There is no good reason for Intel to duplicate all of the work already done on Clover. Of course, Intel hasn't used Gallium for anything before, but their GL drivers have been around since before Gallium drivers became the standard and their video decoding implementation came before there were Gallium state trackers for video decoding.

This, however, just seems like mismanagement to me. Maybe it has to do with this being developed by Intel OTC China instead of Intel OSTC Portland where Intel's Mesa developers are employed, but we now have two frontends that do the same thing.

From the readme in its repository, it seems that Beignet is still far from complete. Hopefully Intel will change its mind and use Clover if it wants OpenCL working on its hardware under Linux.

That's not true. The BSD license is definitely present in the FSF's list of free software licenses.

It might not directly answer the question asked, but it does solve the problem. The Wayland developers have made clear that no one expects X11 to disappear from Linux distributions in the foreseeable future. Since every toolkit on Linux already supports X, you can use the X backend of whatever toolkit when running the application remotely, and the Wayland backend otherwise.

And neither can Mir.

What's that supposed to mean? Have you ever tried going to the Wayland IRC channel (#wayland on freenode) and asking? Wayland is a project developed out in the open, but you make it sound like it's a secret how exactly Wayland development proceeds. It's not.

Everything else you say in your post is fair enough, but the point about Canonical not contributing to Wayland deserves more mention than it has been getting in these discussions. It's nice to want to use Wayland, but if their only problem with it was development not going fast enough, then implementing a new display server from scratch is the exact opposite of a solution, especially when none of the Mir developers have significant prior experience working on display servers. If they wanted to have a modern display server to happen faster, the easiest and most reasonable way to accomplish that - both for Canonical's needs and for everyone else's - would be to take an active role in the development of Wayland.

The companies you mentioned all have vastly more resources and technical expertise at their disposal than Canonical does.

But the main reason that his "NIH syndrome" criticism is valid is that in all of its recent defense of MIr, Canonical has not cited any other reason for not being satisfied with Wayland. Or at least not any other reason that wasn't later retracted for being based on blatantly false claims.

Wayland actually [i]has[/i] gotten quite far, though. It's still not ready for widespread use, but there is a lot that goes into a display server, and most of that is in Wayland currently. Mir, on the other hand, is nowhere near that. Just look at the to-do list for Mir. Mir doesn't even have basic things like resizing windows or any form of window decorations yet.

That's not entirely true. If ignorance is the reason, it has to be paired with gross incompetence - they didn't bother to do their homework or even ask one of the developers about the capabilities and future direction of Wayland. Not to mention that it was beyond irresponsible to spread fear, uncertainty, and doubt about the capabilities of Wayland without fact-checking in what they had to know would be widely disseminated. Now, even though they've retracted it all since literally every one of their claims was wrong, we have to deal with that false information being mistakenly claimed as fact in discussions like this one.

Who needs security vulnerability when you have a complete lack of services and modern IRC features?