Originally posted by DanL
View Post
Announcement
Collapse
No announcement yet.
Mesa 22.3 Lands New "Rusticl" OpenCL 3.0 Implementation
Collapse
X
-
Originally posted by karolherbst View Post
Yep. I needed like 1-2 months to do the real work. Everything else was just random fixes or trying things out.
- Likes 1
Comment
-
Originally posted by oleid View Post
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?
- Likes 2
Comment
-
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)Last edited by NM64; 13 September 2022, 04:00 AM.
Comment
-
Originally posted by mdedetrich View Post
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.
Comment
-
Originally posted by mdedetrich View Post
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.
- Likes 2
Comment
-
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.
- Likes 2
Comment
-
Originally posted by oleid View Post
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?
- Likes 9
Comment
-
Originally posted by Luke_Wolf View Post
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.
Comment
Comment