Rusticl Posted For Working On OpenCL 3.0 Within Rust For Mesa Gallium3D Drivers

[phoronix]

Phoronix: Rusticl Posted For Working On OpenCL 3.0 Within Rust For Mesa Gallium3D Drivers

Mesa has long had the OpenCL "Clover" Gallium3D state tracker that has supported OpenCL 1.x but lacked important extensions that impaired its practicality. With AMD backing their ROCm compute stack in more recent years and Intel going with their Compute-Runtime stack for oneAPI and OpenCL support, there also isn't a major backer to Clover besides Red Hat engineers and the community. Now though "Rusticl" has been published as a new Mesa OpenCL implementation written in the Rust programming language...

https://www.phoronix.com/scan.php?page=news_item&px=Rusticl-Mesa-OpenCL-MR

[tildearrow]

It's too bad the compute market is fragmented:
- oneAPI is Intel-primary, with little support for other vendors
- ROCm is AMD-exclusive
- CUDA is NVIDIA-exclusive
- OpenCL is cross-vendor but sadly it's difficult to use when compared to CUDA

[soulsource]

It's too bad the compute market is fragmented:
- oneAPI is Intel-primary, with little support for other vendors
- ROCm is AMD-exclusive
- CUDA is NVIDIA-exclusive
- OpenCL is cross-vendor but sadly it's difficult to use when compared to CUDA

You've forgotten to mention Compute Shaders. They are less flexible when it comes to the hardware types they run on (afaik only GPU, or with software rendering also CPU), but they are vendor-neutral (work on anything that can run OpenGL 4.3), and are very easy to write/use.

[karolherbst]

You've forgotten to mention Compute Shaders. They are less flexible when it comes to the hardware types they run on (afaik only GPU, or with software rendering also CPU), but they are vendor-neutral (work on anything that can run OpenGL 4.3), and are very easy to write/use.

compute shaders only have 32 bit pointers, which is a big issue for some compute workloads

[Mathias]

compute shaders only have 32 bit pointers, which is a big issue for some compute workloads

Ist that also the case with Vulkan Compute?

[Jannik2099]

Could we please wait with getting unstandardized, unstable languages into critical system components until said language matures and becomes standardized?

[WizardGed]

Could we please wait with getting unstandardized, unstable languages into critical system components until said language matures and becomes standardized?

How would you intend to force that? This is a personal project and developers can work on whatever they like and if it works better than the alternative (Clover) then whoever wants to use it can. no one is stopping you from using one of the alternatives if you want to ensure clover works you'll have to convince others it's worth saving/fixing, save/fix it yourself, or pay someone else to. The constant barrage of people complaining whining etc about language use that are NOT active developers in the project themselves is painful to listen to. It really does come down to use what you want and to use a somewhat crude turn of phrase, "step up or shut up".

[Jannik2099]

How would you intend to force that? This is a personal project and developers can work on whatever they like and if it works better than the alternative (Clover) then whoever wants to use it can. no one is stopping you from using one of the alternatives if you want to ensure clover works you'll have to convince others it's worth saving/fixing, save/fix it yourself, or pay someone else to. The constant barrage of people complaining whining etc about language use that are NOT active developers in the project themselves is painful to listen to. It really does come down to use what you want and to use a somewhat crude turn of phrase, "step up or shut up".

It's not a personal project, it leverages existing mesa code and is intended as a mesa component.

I have no issue with people using Rust in their personal projects, but it's simply too immature for critical components like the system OpenGL (& friends) driver at this point.

[darkbasic]

I have no issue with people using Rust in their personal projects, but it's simply too immature for critical components like the system OpenGL (& friends) driver at this point.

So immature that's being used in the kernel as well

[Jannik2099]

So immature that's being used in the kernel as well

It's not in the kernel yet, and "but what about X" is generally not a technical argument, is it? The kernel has been using GNU C89 for way longer than sanely needed aswell, so it's not exactly the golden reference when it comes to evaluating programming languages.

There are simply too many technical deficiencies in Rust (or the rustc toolchain rather), along the lack of a standard, lack of a stable ABI, and partial language instability - it is just too immature at this point to be the (great) systems programming language it aspires to be, and rushing it will do no good for anyone