Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Intel Releases New OpenCL Implementation for GNU/Linux

Unknown Lamer posted about a year and a half ago | from the do-your-own-thing dept.

Intel 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.

cancel ×

60 comments

Sorry! There are no comments related to the filter you selected.

Any hashing improvements? (-1)

Anonymous Coward | about a year and a half ago | (#43458435)

Just need a few more mining hashes.

Re:Any hashing improvements? (-1, Troll)

cheater512 (783349) | about a year and a half ago | (#43458483)

Mod -1 Sad

Seriously just buy a 2nd GPU. Easier.

OpenCL is a heterogeneous processing language (-1)

Anonymous Coward | about a year and a half ago | (#43458469)

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.

Re:OpenCL is a heterogeneous processing language (1, Funny)

OhANameWhatName (2688401) | about a year and a half ago | (#43458485)

The person has no clue what the hell he was talking about

Welcome to /.

Re:OpenCL is a heterogeneous processing language (5, Informative)

Plombo (1914028) | about a year and a half ago | (#43458561)

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 (0)

Anonymous Coward | about a year and a half ago | (#43458631)

So can Clover run without X11, without OpenGL, and without a graphics card? (I hope so.)

Because of course OpenCL can and should be able to do all of those things. It must be able to run on a machine containing not even a hint of graphics code.

Re:OpenCL is a heterogeneous processing language (3, Insightful)

Plombo (1914028) | about a year and a half ago | (#43458647)

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.

Re:OpenCL is a heterogeneous processing language (0)

Anonymous Coward | about a year and a half ago | (#43458801)

Not according to Wikipedia and Phoronix.

Phoronix says that "the OpenCL/Clover state tracker amounts to a little less than 15,000 lines of new code for Mesa" [phoronix.com] , and that it "is now living on a branch of the mainline Mesa repository."

And Wikipedia says that "Mesa is a software library for 3D computer graphics that provides a generic Khronos-compliant OpenGL implementation for rendering three-dimensional graphics on multiple platforms." [wikipedia.org] And Wikipedia also says that "Gallium3D is a free software library for 3D graphics device drivers." [wikipedia.org]

So unless things have changed, all this OpenCL work done the Clover way is entirely wrapped up in graphics-related code. It may work without a graphics card being present, but it seems that it's entirely dependent on the Mesa graphics code being present..

Or are all those references out of date? I hope so, because otherwise that's a dreadful and totally unnecessary code dependency.

Re:OpenCL is a heterogeneous processing language (1)

Plombo (1914028) | about a year and a half ago | (#43458803)

Yes, both of those references are out of date.

Re:OpenCL is a heterogeneous processing language (0)

Anonymous Coward | about a year and a half ago | (#43458859)

Got a reference for us that isn't out of date, and which explains how Clover is independent of Mesa and Gallium3D? The latest update to Wikipedia's Gallium3D article is dated yesterday, so the page certainly doesn't look out of date on casual inspection.

"I heard it on Slashdot" isn't the way I'd like to convince someone that Clover is the way to go for OpenCL on Linux and it has no dependency on graphics code, when the most visible public documents suggest otherwise. This is pretty important for headless servers that want to stay lean, mean and secure.

Re:OpenCL is a heterogeneous processing language (5, Informative)

Plombo (1914028) | about a year and a half ago | (#43458891)

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:OpenCL is a heterogeneous processing language (1)

ardor (673957) | about a year and a half ago | (#43460215)

In that case, please fix the Wikipedia page.

Re:OpenCL is a heterogeneous processing language (2)

alexo (9335) | about a year and a half ago | (#43466551)

He can't, being a primary source...

Re:OpenCL is a heterogeneous processing language (0)

Anonymous Coward | about a year and a half ago | (#43469587)

Yes he can, he just needs to cite sources

Re:OpenCL is a heterogeneous processing language (0)

Anonymous Coward | about a year and a half ago | (#43459685)

Sorry, but I have to...

You think I heard [sic] it on Slashdot isn't a valid reference, but still consider Wikipedia one..?

I think there's a huge piece of irony hidden in there, somewhere.

Re:OpenCL is a heterogeneous processing language (0)

Anonymous Coward | about a year and a half ago | (#43465243)

Yeah yeah, we know it's cool to bash Wikipedia in the groupthink.

But Wikipedia is at least community reviewed, and while that doesn't guarantee accuracy at any point in time, the community edits average out and stabilize towards something fairly accurate, and certainly good enough to be useful when the subject area allows it.

Perhaps you're mostly acquainted with Wikipedia's material on politics and other contentious subjects in which objectivity is almost impossible to achieve, in which case all bets are off. But in my areas of science and engineering, Wikipedia achieves a pretty impressive standard of accuracy, so the groupthink is hilariously wrong.

Re:OpenCL is a heterogeneous processing language (4, Informative)

Plombo (1914028) | about a year and a half ago | (#43458835)

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.

Re:OpenCL is a heterogeneous processing language (0)

Anonymous Coward | about a year and a half ago | (#43458935)

Thanks, that was much more informative.

However, it still doesn't address the key point that I was trying to make, and your description lent further weight to the worries when you wrote: "Gallium is not exclusively for "graphics". It's for anything that uses the GPU ".

OpenCL will be running on a wide variety of hardware besides GPUs , the primary alternatives being ordinary CPU cores and specialist hardware like FPGAs. The need to install a library or two from the Gallium3D project to support OpenCL in a generic manner is perfectly fine, but if it means having to install the entire Mesa 3D suite or X11 then this is a showstopper for many headless servers that want to be well clear of such a massive dependency. Is it something like the former rather than the latter?

Re:OpenCL is a heterogeneous processing language (0)

Anonymous Coward | about a year and a half ago | (#43459051)

I think you've answered this in the other child of the parent, no need to repeat it again if so. And it seems to be excellent news, just what I wanted to hear, namely that Clover really is independent of GPU and graphics code. Hopefully the docs will make this clear in due course.

All that remains is to be sure that Clover and the parts of Gallium that it needs can be compiled and installed independently, without needing to compile nor install anything that refers to GPU and/or graphic back ends. That's a project structuring issue, and hopefully Gallium has been structured so that the logical separation of backends is also a physical code separation for compilation and installation.

I now look forward to playing with Clover on my headless servers, whereas what I'd read previously did not encourage it. Many thanks for your responses. :-)

Re:OpenCL is a heterogeneous processing language (0)

Anonymous Coward | about a year and a half ago | (#43458725)

>You must not recognize the name of Dave Airlie
Not everyone follow the Church of Linus. At least not in the context of Heterogeneous Computing.

>i.e., he is the person who submits the pull requests to Linus for the graphics drivers in the kernel.
He can say whatever happens to his domain of accepting graphic driver, but Intel is free to release whatever they please to make their CPU/GPU (or whatever hardware) useful for Heterogeneous Computing crowd.

If a Intel or ARM customer want to run his code on Intel or ARM's hardware, there better be an compiler for that. Are you tell him that the person has to rewrite the code to run in Mesa framework (with whatever overhead) just to do what the AMD crowd does?

OpenCL happens to run on GPU for general computing, What place is a 3D graphic driver if I have a box of mixed DSP or FPGA hardware churning out parallel algorithms say decrypting something or doing DNA protein work?

I can see guys from nVidia complaining about OpenCL duplicating efforts on their CUDA, but he is out of line in his rant.

Re:OpenCL is a heterogeneous processing language (1)

Kjella (173770) | about a year and a half ago | (#43459357)

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 even among the intelligent. We just like to think that because we're smart we're not armchair quarterbacks.

Re:OpenCL is a heterogeneous processing language (1)

MurukeshM (1901690) | about a year and a half ago | (#43458593)

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 (4, Informative)

phizi0n (1237812) | about a year and a half ago | (#43458717)

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:OpenCL is a heterogeneous processing language (1, Interesting)

gigaherz (2653757) | about a year and a half ago | (#43459063)

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 CUDA, and what I said above is just an excuse, but I can't prove either.

Re:OpenCL is a heterogeneous processing language (1, Insightful)

TheRaven64 (641858) | about a year and a half ago | (#43459377)

OpenCL is a fairly typical industry standard. All of the major industry players wanted to ensure that it could be compiled to their GPUs, so it ended up with an abstract model that doesn't really match any GPU and a load of features that exist because one GPU has a very fast path for executing them, but none of the others do. Come to an LLVM Dev Meeting some time and you'll hear about a hundred compiler developers complaining about it. When you have some MIMD, some SIMD, and some SIMT architectures all trying to run the same code, all implementing a different set of ALU ops, writing code with vaguely predictable performance is really hard, and trying to run code written with one target in mind on a different one with reasonable performance is very hard.

Re: OpenCL is a heterogeneous processing language (2)

bouldin (828821) | about a year and a half ago | (#43459997)

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.

Re: OpenCL is a heterogeneous processing language (1)

ardor (673957) | about a year and a half ago | (#43460253)

Then you have code that runs well for AMD, and not well for others. You might as well use hardware specific APIs then.

Re: OpenCL is a heterogeneous processing language (2)

TheRaven64 (641858) | about a year and a half ago | (#43460443)

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.

Re: OpenCL is a heterogeneous processing language (1)

cheesybagel (670288) | about a year and a half ago | (#43501547)

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: OpenCL is a heterogeneous processing language (1)

TheRaven64 (641858) | about a year and a half ago | (#43502815)

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 with dedicated logic. OpenCL encourages you to write kernels that run in parallel, but the synchronisation primitives in hardware and the cost of having kernel flow control diverge vary massively between GPUs (and even more if you compare GPUs to CPUs).

David Arlie (-1)

Anonymous Coward | about a year and a half ago | (#43458493)

David Arlie is a malcontent. This is the kinda silliness that keeps companies away from FOSS. Good on Intel.

Re:David Arlie (-1)

Anonymous Coward | about a year and a half ago | (#43458967)

undo mods

Re:David Arlie (0)

Anonymous Coward | about a year and a half ago | (#43459931)

Hurr durr you insulted the Debian GNU/Linux fellate Linus hail RMS hive mind.

Duplicated effort (4, Interesting)

Plombo (1914028) | about a year and a half ago | (#43458519)

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 (0)

Anonymous Coward | about a year and a half ago | (#43458821)

There aren't any production quality OpenGL or OpenCL drivers using Gallium3D. The X.org Intel graphics driver doesn't use it. The AMD driver which does use it performs laughably compared to the Catalyst drivers.

I'd be out of school speculating as to why this is the current state of affairs but I imagine that the Beignet developers had some technical reasons for their decision not to use Gallium3D.

Re:Duplicated effort (4, Informative)

Plombo (1914028) | about a year and a half ago | (#43458855)

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:Duplicated effort (0)

Anonymous Coward | about a year and a half ago | (#43458931)

When has "duplicated effort" become detrimental instead of being the cornerstone of open source development that it used to be? This isn't an app store, you know? To have actual choice, some things need to be done multiple times in slightly different ways.

Re:Duplicated effort (1)

MrMickS (568778) | about a year and a half ago | (#43459269)

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 else. I've had some pretty decent achievements in my IT career but at no point have I been that arrogant to assume that my way was the only way.

Re:Duplicated effort (1)

nmr_andrew (1997772) | about a year and a half ago | (#43464265)

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:Duplicated effort (1)

You're All Wrong (573825) | about a year and a half ago | (#43465041)

Like if the for-profit Apple were to get some benefit from using a BSD kernel?
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? (1)

Anonymous Coward | about a year and a half ago | (#43458541)

Should this really be called "for GNU/Linux" if it's built with LLVM? I see Linux, but not a whole lotta GNU.

Re:Linux yes, GNU maybe? (0)

Anonymous Coward | about a year and a half ago | (#43458681)

Better get your eyes examined because there's no linux either. It's an OpenCL compiler based on Clang/LLVM.

Re:Linux yes, GNU maybe? (1)

Behrooz Amoozad (2831361) | about a year and a half ago | (#43459771)

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:Linux yes, GNU maybe? (0)

Anonymous Coward | about a year and a half ago | (#43460847)

That compiles code to be run by...the Linux kernel. So, yes, there is Linux involved.

Re:Linux yes, GNU maybe? (1)

unixisc (2429386) | about a year and a half ago | (#43460437)

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.

The Truth About The Boston Bomb (-1)

Anonymous Coward | about a year and a half ago | (#43458601)

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.

Re:The Truth About The Boston Bomb (-1)

Anonymous Coward | about a year and a half ago | (#43458715)

Fuck off, you moronic troll.

How much sense this made to me (-1)

wonkey_monkey (2592601) | about a year and a half ago | (#43458997)

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.

slashdot hive-mind explodes (3, Funny)

smash (1351) | about a year and a half ago | (#43459247)

Intel = bad, AMD = good. OpenCL = apple = bad, Linux = good. LLVM = apple = bad. Oh what spin should the /. groupthink put on this?

Re:slashdot hive-mind explodes (0)

Anonymous Coward | about a year and a half ago | (#43459339)

The reality is complex. This is not some children's tale where the bad guy wears dark clothing and laughs menacingly while the Prince on the white horse fights for good.

All these actors you mention are selfish. Sometimes their actions benefit the Free Software Movement and sometimes they don't. And we cherry pick and try to manage them from our view point.

Intel provides the only fully free manufacturer support graphics stack at the moment. On the other hand their wifi is notorious for not working with only free software.

AMD helps with Coreboot but their graphics don't work fully with only free software.

Apple is mostly a very bad company that tries to control and confine us all. Yet they do contribute some useful freely licensed code also.

It's kinda baffling how the good AND the bad progress hand in hand. Often it's very hard to tell which one is winning at any one time or what the consequences of a specific action will eventually be. Only time will tell. And we must work every step of the way.

The only thing necessary for the triumph of evil is for good men to do nothing.
                -- Edmund Burke

Re:slashdot hive-mind explodes (1)

Anonymous Coward | about a year and a half ago | (#43459705)

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:slashdot hive-mind explodes (1)

ceoyoyo (59147) | about a year and a half ago | (#43461819)

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:slashdot hive-mind explodes (1)

smash (1351) | about a year and a half ago | (#43470203)

CLANG / LLVM is funded by Apple, btw, specifically so they can get away from GCC.

Re:slashdot hive-mind explodes (0)

Anonymous Coward | about a year and a half ago | (#43462287)

Intel = bad...

Actually, Intel's OpenCL drivers are the shittiest drivers around. Even for Windows.

1. I have code that compiles fine on nVidia (optimization keyword). Compiles fine on AMD with a warning (optimization keyword ignored). Intel turns a warning into a hard error...

2. Not sure if this still occurs, but not so recently, 0.1f literal caused a compilation error with Intel. 0.1 works but is deemed a double on nVidia. So the only solution is a metric ton of shit like exp((float)3.0*x); where x is float :S :S :S

3. And this takes the cake - Beta drives from Intel for Windows add themselves to the PATH, including libQt4.dll. If drivers are not in the PATH, they will not get loaded. It seems Intel developers haven't heard about saving paths in configuration strings in registry.

Anyway, quality of the OpenCL drives is nVidia >> AMD >> Intel. In this case, Intel=bad. Hopefully, their new drivers they can translate to better than bad.

What is the point of floating point units anymore? (1)

BlueCoder (223005) | about a year and a half ago | (#43459821)

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:What is the point of floating point units anymo (1)

unixisc (2429386) | about a year and a half ago | (#43460543)

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.

Re:What is the point of floating point units anymo (0)

Anonymous Coward | about a year and a half ago | (#43461567)

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.

Re:What is the point of floating point units anymo (1)

ceoyoyo (59147) | about a year and a half ago | (#43461893)

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! (1)

GlobalEcho (26240) | about a year and a half ago | (#43461117)

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?

Does it support Xeon Phi??? (0)

Anonymous Coward | about a year and a half ago | (#43465945)

Does it support Xeon Phi??? (MIC, KC, KB, larabee,et al)

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?