Slashdot Mirror
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.
Just need a few more mining hashes.
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.
David Arlie is a malcontent. This is the kinda silliness that keeps companies away from FOSS. Good on Intel.
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.
Should this really be called "for GNU/Linux" if it's built with LLVM? I see Linux, but not a whole lotta GNU.
The Bible Code predicted the Boston Bomb over two thousand years in advance, and thanks to modern technology, scientists have realized that it reveals even more.
Did you know that citizens who witnessed the Boston Bomb were brought in for questioning by FEMA? What evidence did they collect, and for what reasons? Will we ever really know?
If you listen to radio waves coming from the constellation of Orion, you will be shocked to hear what sounds like routine transmissions from FEMA -- but why are they coming FROM outer space?
A peer-reviewed academic article found buried evidence that the Boston Bomb was entirely planned almost 10 years in advance.
I'm willing to tell the truth about this, despite the dangers, because my commitment to justice and truth is extraordinary.
The truth is out there. Find it.
An anonymous reader writes
"Intel has released its first version of Parp, an open-source Parp run-time and Parp back-end for Linux that uses Parp/Parp and is compatible with Ivy Bridge processors. Right now there's partial support for Parp 1.0 and 1.1 along with other basic functionality."
This is not using Parp, and at least Some Guy thinks it should not be a par.p project because it duplicates functionality already present in Parp.
systemd is Roko's Basilisk.
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.
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.
Either that, or revert back to the old days, when FPUs came separately, like the 487s. Essentially, make CPUs that are just integer units, and include a separate (and optional) floating point unit in the chipset. That FPU could even use different types of RAM that are even faster than standard DRAMS. That way, it could be a custom solution for the engineering segment of the market, such as CAD simulations and so on.
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?
Actually, most of the time, or the task is not vectorizable (what GPGU is good for) or it may represent quite an effort to vectorize it. Anyway I agree, there is too much real state dedicated to FP nowadays, as there is too much redundancy repeating the same semantics in the CPU vector unit and the GPU. I suppose most of it is for legacy reasons.
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.
Does it support Xeon Phi??? (MIC, KC, KB, larabee,et al)