Intel Releases New OpenCL Implementation for GNU/Linux
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.
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.
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 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.
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.
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.
* 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.
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.
Intel = bad, AMD = good. OpenCL = apple = bad, Linux = good. LLVM = apple = bad. Oh what spin should the /. groupthink put on this?
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
It's not that hard when vendors like AMD have a whole set of docs on how to code OpenCL for AMD GPUs. The docs tell you how to optimize for their particular hardware.
Yes, that's what I said. You can write using a subset of OpenCL, in a particular style, and have fast code on AMD GPUs. You can write using a subset of OpenCL, in a particular style, and have fast code on nVidia GPUs. You can write using a subset of OpenCL, in a particular style, and have fast code on ARM GPUs. You can write using a subset of OpenCL, in a particular style, and have fast code on Intel GPUs. You can write using a subset of OpenCL, in a particular style, and have fast code on CPUs. These subsets and styles are somewhat overlapping, but taking code written to run fast on nVidia GPUs and compiling to to run fast on AMD or Intel GPUs is very hard.
I am TheRaven on Soylent News
He can't, being a primary source...