Intel's OpenCL Beignet Project Is Gaining Ground

[Alejandro Nova]

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?

[curaga]

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.

[uid313]

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.

[pingufunkybeat]

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!

[smitty3268]

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.

[Sidicas]

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.

[mrugiero]

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.

[Krejzi]

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.

[uid313]

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?

[archibald]

I see.
Why is that Intel make their own DRI driver and refuse to use Gallium3D?

They don't agree that it's the best way to write their drivers. If you look for posts by Kayden on here he's gone into detail about it.