karolherbst 🐧 🦀<p>Anybody ever ran into synchronization issues with e.g. Davinci Resolve and <a href="https://chaos.social/tags/Rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Rusticl</span></a> ?</p><p>I fixed some issues with gl_sharing and wondering if that resolves it for everybody as well: <a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36249" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">gitlab.freedesktop.org/mesa/me</span><span class="invisible">sa/-/merge_requests/36249</span></a></p>
fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software.
If you wish to join, contact us for an invite.
Administered by:
Server stats:
8.8Kactive users
fosstodon.org: About · Status · Profiles directory · Privacy policy
Mastodon: About · Get the app · Keyboard shortcuts · View source code · v4.4.2
#Rusticl
1 post · 1 participant · 0 posts today
Gamey :thisisfine: :antifa:<p>I want to get <a href="https://chaos.social/tags/davinci_resolve" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>davinci_resolve</span></a> working on <a href="https://chaos.social/tags/Fedora" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Fedora</span></a> 42 with my now very old AMD rx480 8GB but it uses <a href="https://chaos.social/tags/OpenCL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenCL</span></a>. The obvious choice would be <a href="https://chaos.social/tags/rocm" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rocm</span></a> but that dropped support for my GPU years ago and from what I found also causes issues with Davinci resolve for even more years. The other obvious choice would be mesas implementation but while <a href="https://chaos.social/tags/Rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Rusticl</span></a> improved things it's still not a feature complete implementation and rather slow. Is it smart to use the amdgpu-pro ICD with mesa drivers for this?</p>
txt.fileToday’s hate about computers and software
tnt<p>Symbol linking nightmare ...</p><p>In <a href="https://chaos.social/tags/fosphor" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>fosphor</span></a> I try to make use CL/GL interop.</p><p>When used inside gnuradio the whole GL thing will end up being loaded first and apparently GLX will be loaded with RTLD_LOCAL.</p><p>So when CL driver (either <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> or intel-compute-runtime) tries to find glXGetProcAddress using dlsym, because those are dynamically loaded after GLX and don't link to GLX themselves, they just get NULL.</p><p>My best work around so far is call dlopen("libGLX.so.0", RTLD_GLOBAL) in fosphor 😭 🤢</p>
Robert Mader<p>The <a href="https://mastodon.social/tags/mesa" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mesa</span></a> 24.3 release is, as usual, pretty neat. Some random personal highlights:<br>1. <a href="https://mastodon.social/tags/Rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Rusticl</span></a> for freedreno. While not enabled by default yet, this finally brings OpenCL support to QC devices. How useful that is remains to be seen, given that Vulkan also slowly evolves as compute platform - it could come in pretty handy for image related tasks, though, especially on <a href="https://mastodon.social/tags/linuxmobile" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>linuxmobile</span></a> devices.</p><p>1/3</p>
tht 🇧🇬<p>Thank god <a href="https://mstdn.social/tags/Rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Rusticl</span></a> exists, it has made setting up <a href="https://mstdn.social/tags/opencl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>opencl</span></a> on <a href="https://mstdn.social/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a> so easy, you just install <a href="https://mstdn.social/tags/mesa" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mesa</span></a> and you are done, everything "just works"</p>
karolherbst 🐧 🦀<p>And another btw: I have Shared Virtual Memory implemented in Rusticl on top of Iris (Intel) and radeonsi (AMD) and the mechanism for that is driver independent, so...</p><p>yes, SVM in <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> will work across devices of different vendors once it's all finished. I still have a couple of bugs to sort out, but yeah :)</p>
karolherbst 🐧 🦀<p>btw, <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> is also conformant on <a href="https://chaos.social/tags/zink" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>zink</span></a> as of 2 or 3 weeks ago? Anyway, that's done</p>
karolherbst 🐧 🦀<p>Though of the day: I should make more of use lifetimes in Rust to express dependencies between API objects in <a href="https://chaos.social/tags/Rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Rusticl</span></a> </p><p>So far I haven't as using Arc is a good enough solution here. But I'm getting to the point where it's getting in the way.</p><p>The main reason I haven't is, that API objects are managed by the application and given <a href="https://chaos.social/tags/OpenCL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenCL</span></a> being a C API there isn't much I can do really if the application destroys objects in a weird order.</p><p>So that's kinda annoying.</p>
karolherbst 🐧 🦀<p><span class="h-card" translate="no"><a href="https://toot.cafe/@matt" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>matt</span></a></span> yeah.. this is the main reason why with <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> my policy basically is "I use at most whatever FireFox ESR needs", because FireFox ESR is something every distro has to build and package unless they want to risk an insecure web browser.</p>
karolherbst 🐧 🦀<p>Maybe at some point I should talk about some of the push back I've gotten when I proposed <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> to be merged into mesa.</p><p>But all in all I think we can safely say that introducing Rust to Mesa as a success.</p><p>I don't know how much that impacted <span class="h-card" translate="no"><a href="https://mastodon.gamedev.place/@gfxstrand" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>gfxstrand</span></a></span> writing NAK in rust, but at least I've dealt with some of the meson and rust integration problems early on, so at least I enabled that to be a bit simpler than if I hadn't done that 🙃</p>
David Heidelberg<p>If you play with photography or LLMs on your X13s, <a href="https://floss.social/tags/OpenCL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenCL</span></a> for Qualcomm <a href="https://floss.social/tags/Adreno" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Adreno</span></a> 6xx and 7xx series MR is now ready. Rewrite of ops lowering needed for <a href="https://floss.social/tags/Rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Rusticl</span></a> also fixes additional dEQP GL test 🤞 for Mesa3D 24.3 release!<br><a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30835" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">gitlab.freedesktop.org/mesa/me</span><span class="invisible">sa/-/merge_requests/30835</span></a></p>
karolherbst 🐧 🦀<p>I wished we'd had a way in <a href="https://chaos.social/tags/rust" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rust</span></a> to say "usize is at least u32 big", because that would allow me to get rid of a loooooooot of "as" statements in <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a></p>
karolherbst 🐧 🦀<p>I'm gonna fix the most annoying and most weird bug I have atm inside <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> : "volatile private" variables getting optimized to registers.</p><p>And you might think "why does this even remotely matter?" Turns out the <a href="https://chaos.social/tags/OpenCL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenCL</span></a> CTS checks with a simple kernel having two constants in volatile private memory how rounding actually works on hardware.</p><p>However, we constant fold it all away, so the detection fails, which also means that "fma" tests are failing on Apple M1/M2 in weird corner cases 🙃</p>
karolherbst 🐧 🦀<p><a href="https://chaos.social/tags/OpenCL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenCL</span></a> CTS on <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> on <a href="https://chaos.social/tags/asahi" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>asahi</span></a></p><p>Pass 2691 Fails 5 Crashes 0</p><p>I really should fix those two remaining bugs...</p>
karolherbst 🐧 🦀<p>I'm currently looking into what's the best way to support SVM/USM in <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> and one thing I'm wondering about is, if there are any drawbacks doing:</p><p>mmap(some_chosen_address, ram_size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, 0, 0);</p><p>and reserve a lot of virtual memory, and then suballocate SVM allocations out of this region with "PROT_READ | PROT_WRITE" and "MAP_FIXED"?</p><p>Alternatively, I was considering allocating smaller heaps on demand.</p>
karolherbst 🐧 🦀<p>soo.. apparently the broadcom VC4+ GPUs (the ones used in raspberry pis and stuff) do not support format-less image writes, sooo.. supporting OpenCL images in <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> on that hardware will be a bit "difficult", because it needs to be handled within the kernel...</p><p>I should probably check out how other drivers are handling this, because either I'm missing something here or some other vendors are kinda in the same situation (not for all hardware, probably just older GPUs).</p>
karolherbst 🐧 🦀<p>I wonder what should I focus on next quarter.</p><p>I'm mildly leaning towards proper SVM/USM support in <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a>, because that's also required by more and more software (e.g. AdaptiveCPP)</p>
karolherbst 🐧 🦀<p>Soo. the initial set of <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> enablement patches for the raspberry pi4 and newer are merged and will be part of mesa 24.2 (<a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25362" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">gitlab.freedesktop.org/mesa/me</span><span class="invisible">sa/-/merge_requests/25362</span></a>)</p><p>It doesn't support profiling and images yet, but it's stable enough to pass around 97% of the OpenCL CTS</p><p>Of course there will be bugs, so any kind of testing will be appreciated.</p><p>In the meantime I'll try to get images supported.</p>
karolherbst 🐧 🦀<p>uhh, so a few days ago I found out, that passing structs by value in <a href="https://chaos.social/tags/rusticl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rusticl</span></a> through OpenCL C or SPIR-V in fact doesn't pass the argument by value.</p><p>Turns out we don't handle the SPIR-V "ByVal" Function Parameter Attribute...</p><p>this might explain a few bugs I've seen in the past...</p>
TrendingLive feeds
Mastodon is the best way to keep up with what's happening.
Follow anyone across the fediverse and see it all in chronological order. No algorithms, ads, or clickbait in sight.
LoginDrag & drop to upload