Announcement

Collapse
No announcement yet.

OpenCL 1.0 Specification Released!

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic OpenCL 1.0 Specification Released!

    OpenCL 1.0 Specification Released!

    Phoronix: OpenCL 1.0 Specification Released!

    Khronos Group has today announced the ratification of the OpenCL 1.0 specification! The 1.0 specification of the Open Computing Language is backed by Apple, AMD, NVIDIA, Intel, and other industry leaders as a new open standard to exploit graphics processors for general-purpose computational needs. What OpenCL 1.0 defines is a C99 programming language with extensions geared for parallel programming, an API for coordinating data and task-based parallel computation across a wide range of heterogeneous processors, numeric requirements based on the IEEE 754 standard, and efficient interoperability with OpenGL, OpenGL ES, and other graphics APIs. The press release announcing the release of the OpenCL 1.0 specification can be found in the Khronos news area. NVIDIA has already announced today as well that the OpenCL 1.0 specification will be added to their GPU computing toolkit...

    http://www.phoronix.com/vr.php?view=NjkxMw

  • deanjo
    replied
    FYI anandtech has a interesting write up on openCL.

    http://www.anandtech.com/video/showdoc.aspx?i=3488&p=1

    Leave a comment:


  • marcheu
    replied
    When doing video over gallium directly, we also gain the ability to add in specific video decoding pipeline stages. So yeah, it makes more sense that way.

    As for doing OpenCL on top of gallium, it seems possible, but I'm not 100% sure yet, I have only read parts of the specification.

    Leave a comment:


  • Zhick
    replied
    Originally posted by StefanHamminga View Post
    Another question: Could OpenCL implementations replace (most of) the 'proprietary' video offloading extensions like UVD and PureVideo?
    My guess is that Video-acceleration will be implemented directly on top of gallium3d (or better: already is implemented), at least for the free drivers. This will propably also be faster, since OpenCl for the free drivers (I suspect) will also be implemented on top of gallium3d. And it doesn't take a X developer to figure out that Hardware->Gallium3d->VideoDecoding will most likely be faster than Hardware->Gallium3d->OpenCl->VideoDecoding.
    And the proprietary drivers will most likely naturally continue to use their proprietary extensions...

    Leave a comment:


  • drag
    replied
    Originally posted by StefanHamminga View Post
    Another question: Could OpenCL implementations replace (most of) the 'proprietary' video offloading extensions like UVD and PureVideo?
    I hope so, but I don't know. The comparison is between two APIs where one fairly generic vs having something that is specialized for video.

    So I suppose, unless the OpenCL stack is done very well, that the UVD/Purevideo will always have a edge on performance. But with OpenCL it's going to be much easier to deal with and you should see substantial gains versus just CPU-based processing.

    Plus I expect that those video-specific APIs are geared towards very specific media types.. like h264 or whatever. Were as OpenCL could be applied to most anything, including things like Dirac. I really don't know all the details or whatnot.. not a programmer. So it's just guessing.

    Leave a comment:


  • StefanHamminga
    replied
    Thanks for clearing that up Drag! I was wondering because I suppose their goal is to enable many projects to make use of the GPU, but to me that only makes sense when you can actually efficiently share the GPU amongst processes.

    Another question: Could OpenCL implementations replace (most of) the 'proprietary' video offloading extensions like UVD and PureVideo?

    Leave a comment:


  • deanjo
    replied
    Ars Technica has a nice little write up on openCL today.

    http://arstechnica.com/news.ars/post...c-release.html

    Leave a comment:


  • drag
    replied
    Originally posted by chaos386 View Post
    This is what worries me a little about Larrabee. I'm certainly no expert, but what I've read about x86 is that it's not the most efficient architecture out there, yet Intel is pushing for it to become the standard ISA for graphics & stream processing as well as general computing. Even if x86 is easier to code for today, wouldn't it be better in the long run if a better architecture was chosen? If we're essentially starting fresh anyway, why waste valuable die space converting x86 commands to RISC when we can just code in RISC in the first place?
    Well despite the baggage Intel and AMD are able to make their systems outperform PowerPC by a wide margin, price-wise. Most problems I see are with very low-power cpus like those systems which are now dominated by ARM-style CPUs.

    So I don't think it's nearly a big of a deal as people try to make it out to be.


    What I'm wondering about: how does this work exactly? Is there some kind of scheduler for these programs? Or will one OpenCL program 'claim' the entire GPU exclusively?

    If there were some kind of scheduling, wouldn't the driver have to replicate a very large part of the linux kernel functions?

    Well this is probably going to be driver specific for the time being, until the GPGPU folks figure out how to create a new architecture and standardized ISA so that Linux can simply treat it as a new type of computer.

    A huge part of it, for Linux and open source, will be Gallium.

    Gallium is, essentially, a modularized DRI2 driver. A Mesa-derived DRI-style driver currently only support OpenGL and are extremely complex. HOWEVER, only a relatively small part of a driver of that type is actually very hardware-specific. So Gallium's goal is to talk to the in-kernel DRM driver, via the DRI2 interfaces, and separate out the hardware-specific portions of the DRI2 driver into a Winsys (I think) portion and then add support for running many different types of APIs.

    So how much of your GPU is consumed by running OpenCL would depend on the Linux kernel scheduling and the memory management facilities. Hence the need for GEM-type advanced memory management in the DRM driver.

    The Linux kernel should be able to effectively manage application's time slices on the GPU and try to manage video memory access, trying to balance everything else.

    This leads to quite a bit more overhead then just running a pure graphics or pure compute workload, but allows for multitasking and whatnot.



    -----------------------

    Somewhat perversely I expect that one of the reasons AMD and Intel have taken such a interest in making sure that Linux has open source drivers is to provide a effective clustering and workstation OS for taking advantage of their new GPGPU-style platforms.

    -------------------------------


    Of course it's important to keep in mind that Nvidia and Apple are the ones that are spearheading this OpenCL stuff and Linux far behind. (and Nvidia has significant financial benefits from high-end graphics stuff on Linux).

    I am hoping, however, that Linux devs should hopefully be able to take aggressive advantage of this sort of thing as soon as the Gallium stuff starts working out.
    Last edited by drag; 12-09-2008, 06:47 PM.

    Leave a comment:


  • StefanHamminga
    replied
    What I'm wondering about: how does this work exactly? Is there some kind of scheduler for these programs? Or will one OpenCL program 'claim' the entire GPU exclusively?

    If there were some kind of scheduling, wouldn't the driver have to replicate a very large part of the linux kernel functions?

    Leave a comment:


  • chaos386
    replied
    Originally posted by drag View Post
    A modern Intel x86 processor, for example, is VERY different from the old CISC designs. The actual part of the CPU that does the processing is in fact a high speed RISC processor, but there is a great deal of hardware logic to turn the x86 CISC-style commands into something that the modern CPU can deal with.

    This is how Intel is able to maintain machine code-level compatibility back into DOS days.
    This is what worries me a little about Larrabee. I'm certainly no expert, but what I've read about x86 is that it's not the most efficient architecture out there, yet Intel is pushing for it to become the standard ISA for graphics & stream processing as well as general computing. Even if x86 is easier to code for today, wouldn't it be better in the long run if a better architecture was chosen? If we're essentially starting fresh anyway, why waste valuable die space converting x86 commands to RISC when we can just code in RISC in the first place?

    Leave a comment:

Working...
X