Microsoft's "CLOn12" Mesa Code Adds SPIR/SPIR-V Support

[Snaipersky]

Mesa has OpenCL?

There is no libOpenCL.so anywhere in my Mesa builds.

Clover is an openCL implementation in mesa.

[MadeUpName]

This will probably help you understand what is going on. Basically the same approach as ROCm with the exception that unlike ROCm this may actually work some day. What I don't get is the biggest use case for openCL is Linux in the data center so why would you want to bring virtualized Microsoft into your super computer stack?

https://devblogs.microsoft.com/direc...ows-10-on-arm/

If every OS is going to be dependant on Direct X I would like to see it open sourced.

[smitty3268]

Mesa has OpenCL?

Yep.

There is no libOpenCL.so anywhere in my Mesa builds.

I don't think it's necessarily ready for end users. It's been a work in progress for a long time, but you can compile it with the right args. The clover state tracker provides OpenCL support.

[smitty3268]

What I don't get is the biggest use case for openCL is Linux in the data center so why would you want to bring virtualized Microsoft into your super computer stack?

I haven't followed this too closely, but the impression I get is that this is about MS wanting to allow people to run Machine Learning linux apps in WSL that use OpenCL.

[dragorth]

This will probably help you understand what is going on. Basically the same approach as ROCm with the exception that unlike ROCm this may actually work some day. What I don't get is the biggest use case for openCL is Linux in the data center so why would you want to bring virtualized Microsoft into your super computer stack?

https://devblogs.microsoft.com/direc...ows-10-on-arm/

If every OS is going to be dependant on Direct X I would like to see it open sourced.

Microsoft wants to be the developer platform for everyone. That is the reason is type of thing. So you can use Visual Studio to make those apps to deploy on Linux on Azure.

[DrYak]

Whatever happened to "Vulkan is cross-platform"?

Basically, Microsot and Apple happened to Vulkan. a.k.a.: Nah, don't use the cross-platform thingy! That would be too much freedom and interoperability! We order you to use our proprietary lock-in!

In practice, Vulkan is still a good bet as windows drivers by the big player (AMD, Nvidia) will continue to offer it in the forseeable future, it's available on multiple other platforms, and there are going to be Vulkan-to-Metal wrapper for the edge cases at Apple (now that they produce their own GFX cores for ARM and don't depend on external companies, chances are lower that someone will smuggle in Vulkan in the driver pack).

But it start to smell again like the 00s-10s, where technically OpenGL is the most cross-platorm, widely available solution, but companies are managing (or at least trying) to push their lock-in onto game devs.

Though this time around it looks like it won't pan out as easily: the most anti-cross-platform, Apple, isn't a dominant platform in the gaming industry. Their Mac OS platform (desktops and older laptops) are merely seen as a checkmark on a list of targetted platform, and even their iOS platform (smartphone, tablets, and recent ARM-portable) aren't dominant for games to be exclusives (most iOS games are also released on Android).

I don't see what is stopping Microsoft from doing OpenCL directly over DirectX.

In practice that is what they are doing: Mesa isn't a separate different graphical API, it's a standardized way for back-ends to expose low-level functionality upon which higher-level API (like OpenGL, OpenCL) can be built (with Vulkan drivers being the exception that breaks this image).
DirectX 12 is merely one way to address low-level hardware. Microsoft is making sure that there's a good enough DX12 back-end so that it's possible to get OpenCL running atop of it.

What I don't get is the biggest use case for openCL is Linux in the data center so why would you want to bring virtualized Microsoft into your super computer stack?

The big question is What would the Data Center devs / HPC academics / etc. develop the code that runs there ?

The things that has been making Microsoft C-levels crap their pants in terror is that for quite some time they are losing developers:
- Back when running Business Software locally was the norm, most devs where working on Windows machines and targetting mostly Windows. (Same also for gamedevs).
- Nowadays with everything - even MS' own Office 365 service - is moving to the cloud (which is absolutely dominated by various GNU/Linux platforms) and academic clusters (wait, what do you means there's an other OS beside RedHat? :-D ) devs are moving to more UNIX-y platforms.
- I've seen a lot of devs moving to Mac OS (due to its BSD UNIX parts under the hood), most of the other research around me use that.
- Then there's even the people who entirely move to GNU/Linux(*) as their day-to-day work platform (and thanks to efforts such as from Valve: also could be used as their evening entertainment platform in a pinch, without needing to dualboot).
- To that also a bunch of users who simply use their laptops as glorified SSH machines and do directly work on HPC nodes and Cloud instances (and thus work with merely Chromebooks, iPad Pros and other such netbooks)
and suddenly Microsoft sees that they slowly started sliding along a slope into obsolescence, where nobody has any strong interest into buying their products (except for gaming).

(And personally I'm using a mix of the last two: exclusively Linux on my machines and also a lot of SSH-ing when on-the-go from SBC-class subnotebooks, e.g.: my trusty Pinebook Pro).

It turns out that Linux on the server was a strong gateway drug into the UNIX world (of mostly Mac OS and GNU/Linux)

One way to address that is their Office 365 - become a (rather crappy, in my taste) web-app and so everyone can use it on any platform in the sun, even those who ran away from installing MS software locally.

The other way is to try to catch back some of the dev crowd by offering them way to run not only UNIX, but the precise(*) GNU/Linux environment will face while on the cloud, all that without needing to go through the hassle of installing and learning to use Ubuntu, or needing to run it inside a VM beside their normal OS.

So they have leveraged a lot of the past work they've done in (for now, still failed) attempt to run Android Apps under Windows (back when they wanted a share of the Smartphone pie while buying Nokia), and brought WSL (a NT-kernel subsystem that expose enough Linux-like API to run GNU) , and more recently WSL2 (basically co-Linux: have a real deal Linux kernel run cooperatively along side NT-kernel).

So Cloud / HPC devs can run and test their code natively on their Windows laptops.

---

(*): there's a weird case of opensource EEE here (mostly inherited from an UNIX ecosystem that has seen the Unix wars while in its infancy) where there are subtle incompatibilities between different flavours of Unix.
And GNU/Linux, because of it being opensource, easy to hack and a vibrant community, has piled up new feature and deviated a bit from the POSIX standard.
To the point that I've been bitten back, because I mostly develop on Linux on my laptop, or remotely on the cluster, and run production on a Linux HPC, but my colleague researchers tend to run Mac OS, and I've accidentally used some Linux-isms which aren't available on Mac OS' BSD core.
(e.g.: GNU and BSD shell utils have different options, different features, etc.)

So by offering real-deal GNU/Linux to cluter & HPC devs, Microsoft is helping them tip-toe around these Mac OS vs GNU/Linux "typical UNIX inconsistancies" shennigans.
In a way, they are leveraging EEE as usually, except for once they aren't entirely responsible for the middle "Extend" part - we Linuxers did it entirely on our own.

[uid313]

This does OpenCL over DirectX 12.
Does it also do OpenGL and Vulkan over DirectX 12?