Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 35

Thread: Intel's OpenCL Beignet Project Is Gaining Ground

  1. #11
    Join Date
    Apr 2009
    Posts
    501

    Default

    Quote Originally Posted by 6L3ZZ View Post
    I suspect that this is at least partially to support embedded systems. Having OpenCL makes a lot of sense for some embedded applications and linking in vendor specific libraries (e.g. Intel's ipp and mkl) that match the target CPU you've picked is a common approach. Since AMD has been implementing OpenCL on their Fusion APUs perhaps Intel is getting some market pressure to do something similar. Nvidia's CUDA is the 800lb proprietary gorilla here so I fail to see how supporting an open API is a bad thing. Also, see the article 'Intel's Mesa Team Has Grown About 10x In Three Years'. Its possible we're seeing disjoint pieces of some larger strategy so its WAY to soon to grab out pitchforks and storm the castle over this.
    Yeah, talk about splitting hairs, for Linus' sake! Intel is producing, as usual, an open source solution for Linux. They honor the standard APIs. But they choose a path that doesn't seem the best in terms of code reuse by other OS partners. But hey, they need to move quickly and chase NVIDIA, I would assume that they assessed the situation and chose what they feel best works for them. Was that soooo bad, really? Chill, my friends, chill!

    Cheers!

  2. #12
    Join Date
    Feb 2008
    Location
    Santiago, Chile
    Posts
    220

    Default

    I'm uninformed here.

    Is Intel implementing their own API, like NVIDIA CUDA? Or is this a free extension made to leverage OpenCL APIs but without Gallium?

  3. #13
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,754

    Default

    Quote Originally Posted by Alejandro Nova View Post
    I'm uninformed here.

    Is Intel implementing their own API, like NVIDIA CUDA? Or is this a free extension made to leverage OpenCL APIs but without Gallium?
    It's an OpenCL implementation, not an extension.

  4. #14
    Join Date
    Dec 2011
    Posts
    1,936

    Default

    Quote Originally Posted by Alejandro Nova View Post
    I'm uninformed here.

    Is Intel implementing their own API, like NVIDIA CUDA? Or is this a free extension made to leverage OpenCL APIs but without Gallium?
    As I understand it AMD and Nouvoue are implementing OpenCL support using the Gallium3D state tracker.

    Intel however, instead of using the Gallium3D state tracker and sharing code with AMD and Nouvoue so we can have a common OpenCL implementation shared by all drivers, they're making their own OpenCL implementation outside of Gallium3D that will only be used by themselves.

  5. #15
    Join Date
    Jun 2009
    Posts
    2,910

    Default

    Quote Originally Posted by uid313 View Post
    As I understand it AMD and Nouvoue are implementing OpenCL support using the Gallium3D state tracker.

    Intel however, instead of using the Gallium3D state tracker and sharing code with AMD and Nouvoue so we can have a common OpenCL implementation shared by all drivers, they're making their own OpenCL implementation outside of Gallium3D that will only be used by themselves.
    This is unfortunate, but probably inevitable when you employ more people to work on something than all of your competitors combined.

    Oh well, go clover!

  6. #16
    Join Date
    Oct 2008
    Posts
    2,915

    Default

    Quote Originally Posted by Alejandro Nova View Post
    I'm uninformed here.

    Is Intel implementing their own API, like NVIDIA CUDA? Or is this a free extension made to leverage OpenCL APIs but without Gallium?
    It's OpenCL support without using the existing code already present in Gallium.

    The thing is, that support is very flexible. Nouveau is sending it through TGSI to take advantage of their current driver support. AMD is sending it through an entirely different LLVM pipeline. There's no reason Intel couldn't just copy and paste their Beignet code into the same framework, getting the benefit of some shared code in the front while keeping their same custom backend code.

    Except, they are apparently allergic to anything named Gallium that might actually work to benefit their competitors. So, we get a completely separate out-of-Mesa support that shares no code at all. Similar to Mir, the original announcement came with a bunch of technical reasons behind the decision, which were all quickly outed for bullshit within a couple hours. Since then, there's been no more discussion at all about why beignet even exists, other than, well, they'd already started it.


    Yes, I agree Intel has every right to do whatever they want to do with their own time and money. Just as I'm free to call them out about what i think is stupid.
    Last edited by smitty3268; 08-18-2013 at 05:21 PM.

  7. #17
    Join Date
    Jun 2011
    Posts
    315

    Default

    Quote Originally Posted by smitty3268 View Post
    Just in terms of the sheer, "we don't like upstream so we're going to reimplement everything from scratch" NIH syndromeness.

    At least this project will still have the same OpenCL API that apps can all share. I'm half surprised they aren't making their own incompatible API that will "better fit Intel hardware".
    Have you ever been involved with a project being out-sourced to india/china? If so, you would understand why the India/China team does not want to work with anybody outside of their team. Outsourcing firms are not "community" developers.

    The best programmers in India/China have the absolute worst English I've ever heard and they can't say much more than Hello and Bye in video conferences. They can't read anything more complicated than Dr. Seuss and so they need to have a translator/spokesman for communication.

    That's why they have a go-between to do all the communications. Expecting an outsourced India/China team to work together with an Open Source community like Mesa/Gallium that speaks English at such a high level? Not going to happen on the money they're getting paid to do the project. The spokesman/translator is often a linguist who understands absolutely nothing of source code and can become a big problem for communicating anything more than very specific requirements and specifications.

    If Intel implemented OpenCL using Gallium, they would have to work closely with other Gallium devs.

    Getting an outsourced team to work together with Gallium devs would be a lot more expensive than letting the outsourced team work on their own from very specific requirements and specifications and then just merging it in without using Gallium at all.

    Of course Intel is going to keep the work that absolutely needs to be coordinated with the open source community in-house instead of out-sourcing it... And anything that can be developed separately, they'll out-source it to India/China for a tiny fraction of the development cost.. It's the wise thing to do from a business perspective, and it's exactly what they're doing.
    Last edited by Sidicas; 08-18-2013 at 10:05 PM.

  8. #18
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by pingufunkybeat View Post
    This is unfortunate, but probably inevitable when you employ more people to work on something than all of your competitors combined.

    Oh well, go clover!
    That's not inevitable at all. If you employ more people, you can actually put them to work on features not implemented by anyone else, instead of duplicating the same work. Just saying.

  9. #19
    Join Date
    Feb 2013
    Posts
    70

    Default

    Quote Originally Posted by uid313 View Post
    As I understand it AMD and Nouvoue are implementing OpenCL support using the Gallium3D state tracker.

    Intel however, instead of using the Gallium3D state tracker and sharing code with AMD and Nouvoue so we can have a common OpenCL implementation shared by all drivers, they're making their own OpenCL implementation outside of Gallium3D that will only be used by themselves.
    They can't implement their OpenCL within Gallium since they have DRI driver, not Gallium one. They'd need to port their driver(s) to Gallium first (which they countless times said they wont) to use clover state tracker.

  10. #20
    Join Date
    Dec 2011
    Posts
    1,936

    Default

    Quote Originally Posted by Krejzi View Post
    They can't implement their OpenCL within Gallium since they have DRI driver, not Gallium one. They'd need to port their driver(s) to Gallium first (which they countless times said they wont) to use clover state tracker.
    I see.
    Why is that Intel make their own DRI driver and refuse to use Gallium3D?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •