Intel Releases New OpenCL Implementation for GNU/Linux 60
An anonymous reader writes "Intel has released its first version of Beignet, an open-source OpenCL run-time and LLVM back-end for Linux that uses LLVM/Clang and is compatible with Ivy Bridge processors. Right now there's partial support for OpenCL 1.0 and 1.1 along with other basic functionality."
This is not using Gallium 3D, and at least David Arlie thinks it should not be an fd.o project because it duplicates functionality already present in Mesa.
Re: (Score:2, Funny)
The person has no clue what the hell he was talking about
Welcome to /.
Re:OpenCL is a heterogeneous processing language (Score:5, Informative)
This has nothing to do with Gallium 3D or Mesa which are 3D graphics related. The only similarity is that some of the targets happens to be GPU. The person has no clue what the hell he was talking about. May be he is confused it with OpenGL!?
This is AMD's answer to CUDA.
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 [freedesktop.org] 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.
Re:OpenCL is a heterogeneous processing language (Score:4, Insightful)
Re: (Score:2)
Re:OpenCL is a heterogeneous processing language (Score:5, Informative)
Got a reference for us that isn't out of date, and which explains how Clover is independent of Mesa and Gallium3D?
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.
Re: (Score:2)
In that case, please fix the Wikipedia page.
Re: (Score:3)
He can't, being a primary source...
Re:OpenCL is a heterogeneous processing language (Score:5, Informative)
* 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.
Re: (Score:2)
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.
Par for the course around here, you hear the same crap about Wayland despite it being made by ex-X and current-X devlopers who have spent 10+ years staring at the innards of X. That might make a good case for insanity, but not ignorance. It's hardly limited to IT, it seems many here feel qualified to be Supreme Court justices and a host of other things. Yet we laugh hard at others who think software development are about throwing up a few dialogs in Visual Basic, the Dunning-Kruger effect is alive and well
Re: (Score:2)
If the OpenGL guys released this, and it was adopted by Intel, AMD and nVidia, how is this AMD's answer to anything? Genuinely curious.
Re:OpenCL is a heterogeneous processing language (Score:5, Informative)
http://en.wikipedia.org/wiki/OpenCL
>Open Computing Language (OpenCL) is a framework for writing programs that execute across heterogeneous platforms consisting of central processing units (CPUs), graphics processing units (GPUs), DSPs and other processors.
>OpenCL includes a language (based on C99) for writing kernels (functions that execute on OpenCL devices), plus application programming interfaces (APIs) that are used to define and then control the platforms. OpenCL provides parallel computing using task-based and data-based parallelism. OpenCL is an open standard maintained by the non-profit technology consortium Khronos Group. It has been adopted by Intel, Advanced Micro Devices (AMD), Nvidia, Altera, Samsung, Vivante and ARM Holdings.
This has nothing to do with Gallium 3D or Mesa which are 3D graphics related. The only similarity is that some of the targets happens to be GPU. The person has no clue what the hell he was talking about. May be he is confused it with OpenGL!?
This is AMD's answer to CUDA.
Neither do you. How can it be AMD's answer to (Nvidia's) CUDA when Apple developed it with help from AMD, IBM, Intel, and Nvidia?
AMD's answer to CUDA was their Stream framework that they abandoned in favor of an open standard (OpenCL) but Nvidia built a business around CUDA so they're supporting both but still pushing CUDA on their customers and using it as an excuse not to support other GPU's in PhysX.
Re: (Score:2, Interesting)
I have heard it said that the general purpose solutions (OpenCL and DirectCompute both) can't represent the GPU architecture in enough detail to get the same level of efficiency as using a platform-specific API such as CUDA. If you want your code to be as fast as possible, and you know you are building a system around NV hardware, then CUDA is supposedly a better target.
Of course the alternative is that NV isn't putting as much effort in making the OpenCL/DirectCompute driver interfaces as efficient as CUD
Re: (Score:2, Insightful)
Re: OpenCL is a heterogeneous processing language (Score:3)
Re: (Score:2)
Then you have code that runs well for AMD, and not well for others. You might as well use hardware specific APIs then.
Re: (Score:3)
Re: (Score:1)
So it is just like C. It will run anywhere if coded to the standard but you need to take care to optimize for a specific architecture. Does not sound particularly bad to me FWIW in my experience you just need to change some constants in your program to get most of the performance. These can be determined in runtime by querying the device. So it is not as bad as people paint it.
Re: (Score:2)
So it is just like C. It will run anywhere if coded to the standard but you need to take care to optimize for a specific architecture
No, not really. Pretty much any architecture that you run C on will implement the C abstract machine pretty directly. If you restrict yourself to mainstream CPUs (i.e. anything you might run a *NIX OS on, not embedded microcontrollers) then you have very similar performance characteristics, and you improve performance by doing things like reducing data-dapendent flow control and increasing data locality. On a GPU, the differences are far more pronounced. Some will implement operators in microcode, some
Duplicated effort (Score:5, Interesting)
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 [freedesktop.org] 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.
Re:Duplicated effort (Score:5, Informative)
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.
Re: (Score:2)
If Arlie is right why is there more than one Linux distro? Why does Linux exist at all, we had free BSD Unixes before hand? Why is there more than one Smartphone OS? Why is there more than one console? Why are there both diesel and petrol combustion engines? In fact why are there engines at all, horses will do the job of pulling carts and carriages around.
Arlie is pissed because something that Intel releases is likely to get more traction than his pet project. His comments are as much about ego as anything
Re: (Score:2)
This sounds right on the money to me.
Also, if Intel were to make use of Mesa, just think of the outcry on /. over a for-profit company getting some benefit from using free code.
Re: (Score:1)
Or if the for-profit IBM were to get some benefit from using linux?
Or if the for-profit Amazon were to get some benefit from using Apache Hadoop?
Or if the for-profit Cisco were to get some benefit from using postgreSQL?
Methinks you're imagining outcries that are not in evidence.
Linux yes, GNU maybe? (Score:1)
Re: (Score:1)
Better get your eyes examined because there's no linux either. It's an OpenCL compiler based on Clang/LLVM.
Or the other way around.
Re: (Score:2)
Very good point. Of course, it could be that they avoided using GCC, but are using other GNU utilities, but that's what I'd like to know. But if they are using other Linux utilities outside GNU, and not a lot of it - either deliberately or otherwise - there ain't a good case at least here for calling it GNU.
slashdot hive-mind explodes (Score:4, Funny)
Re: (Score:1)
Um, this is what one tends to see on /.:
Intel = good and very bad on a case-by-case basis, AMD = good, Apple = often bad, but with some very good project, OpenCL = very good, and prime example of good apple goodness, LLVM = awesome (and not = apple, who - like some others others - don't own it and didn't start it, but use it and hire some devs to contribute to it)
I don't know where you get your groupthink opinions from.
Re: (Score:2)
Not bad, except that anything good Apple does is quickly attributed to someone else. Like the guy above who proclaimed loudly that OpenCL was AMD's answer to CUDA.
Re: (Score:2)
What is the point of floating point units anymore? (Score:2)
Especially with baseline video on chip the video hardware is a better floating point unit. I think it would be better to scrap most of the FPU cores and put more integer cores on chip. It saves both power and chip real estate.
Re: (Score:2)
Re: (Score:2)
Standard video hardware is a crappy FPU for most things. The only time it works really well is if you've got an embarrassingly parallel problem with a high computational demand. You don't want to be offloading it to the GPU every time you need to add a couple of numbers.
You might get away with it in the hybrid CPUs that have the GPU and CPU integrated in one package, but you'd still be better off with a separate single purpose FPU.
More acronyms please! (Score:2)
Intel has released its first version of Beignet, ... LLVM/Clang ...Ivy Bridge ... OpenCL 1.0 and 1.1 ...Gallium 3D... David Arlie ...fd.o ...Mesa.
Could we please have more jargon and name-checks in the summary?