Mesa 22.3 Lands New "Rusticl" OpenCL 3.0 Implementation

[karolherbst]

It gave Karol Herbst something to do while waiting for Nvidia to not obstruct the open source graphics stack.

too close to the truth....

[oleid]

Yep. I needed like 1-2 months to do the real work. Everything else was just random fixes or trying things out.

Did rust have anything to do with it (i.e. would writing it in C have been similarly quick)? And were you already fluent in rust?

[Quackdoc]

It already does. I even pass the official conformance tests on 12th gen intel

Any idea if it works on DG2? I was able to borrow one from a friend temporarily if some testing is needed.

[mdedetrich]

Did rust have anything to do with it (i.e. would writing it in C have been similarly quick)? And were you already fluent in rust?

If you are decent in Rust then writing equivalent Rust code is much faster because you have a compiler holding you hand finding any race conditions/concurrency/memory bugs (as long as you are not using unsafe). This can save significant time in diagnosing hard to find errors.

[NM64]

Finally, maybe soon enough I'll have a working OpenCL solution on my Ryzen 4800U (which ROCm straight-up does not support).

Previously I was using Intel Haswell integrated graphics where getting OpenCL was quite simple, but I've since kind of sworn off Intel graphics on any external/desktop display other than an HDTV (which has its own scaling options) or a CRT monitor (is multisync, 'nuff said) when I discovered that, specifically for external/desktop displays, Intel graphics basically don't have a (simple?) way to enable preserve aspect ratio / GPU scaling, but such a thing is stupid-simple on AMD graphics (though, even at your monitor's native resolution, the setting seems to be limited to your monitor's first-listed EDID refresh rate at this time which is commonly 60Hz even on higher-refreshing monitors despite the OS claiming to be running at a higher refresh rate)

[oleid]

If you are decent in Rust then writing equivalent Rust code is much faster because you have a compiler holding you hand finding any race conditions/concurrency/memory bugs (as long as you are not using unsafe). This can save significant time in diagnosing hard to find errors.

That's my experience as well. I was just wondering how karolherbst felt about the matter. Especially since they used the project as an excuse for learning rust.

[Luke_Wolf]

If you are decent in Rust then writing equivalent Rust code is much faster because you have a compiler holding you hand finding any race conditions/concurrency/memory bugs (as long as you are not using unsafe). This can save significant time in diagnosing hard to find errors.

I'd like to echo this sentiment. The only language I feel my development time is faster in is C# but only for code where the safety advantages of Rust don't matter. Every other language I regularly work with: Scala, C++, Python, Java, etc I'm either just as fast to develop in Rust or faster because the compiler and VS Code Plugin is more useful than the equivalent relevant IDEs (Intellij, Kdevelop, etc). I can generally rely on Rust Analyzer to point out all my mistakes and Rust libraries on the whole tend to be better documented than similar libraries in other languages.

[dragon321]

Too bad I can't try it on my main machine (Radeon GPU). I tried playing with Clover but application support was pretty bad. Then I tried proprietary driver and it worked fine but I realized I don't really need OpenCL that much and got rid of that (I prefer to not use proprietary software unless I really need it). Now that gives me some hope of having useful open source OpenCL support. karolherbst good work. I really should learn Rust more.

[karolherbst]

Did rust have anything to do with it (i.e. would writing it in C have been similarly quick)? And were you already fluent in rust?

Well, I had to track down close to no memory corruption bug. And the threading/locking stuff is really easy to use. But maybe it wouldn't have taken so long with C either. Don't know. Still learning Rust, but what I can say is, that Rust really "forces" you do think more about your abstractions and how to actually make it safe from a memory point of view and that also helps with having fewer bugs in the code base.

[mdedetrich]

I'd like to echo this sentiment. The only language I feel my development time is faster in is C# but only for code where the safety advantages of Rust don't matter. Every other language I regularly work with: Scala, C++, Python, Java, etc I'm either just as fast to develop in Rust or faster because the compiler and VS Code Plugin is more useful than the equivalent relevant IDEs (Intellij, Kdevelop, etc). I can generally rely on Rust Analyzer to point out all my mistakes and Rust libraries on the whole tend to be better documented than similar libraries in other languages.

Regarding Scala, have you tried the metals extension for Scala with VSCode https://scalameta.org/metals/docs/editors/vscode ? I use it quite frequently and its very polished now.