3 months
appreciate the info, will pass this on
grow a plant, hug your dog, lift heavy, eat healthy, be a nerd, play a game and help each other out
- 0 posts
- 81 comments
Joined 3 years ago
Cake day: June 12th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
Harry (from the github thread) hasn’t been able to repro on Ubuntu so far
I’m curious if you’ve been using
--usecase=graphicson install?
Thank you for checking in with this. Strangely it seems to work fine for other people using different distros. Will follow up internally.
huh, weird. I’ll check in with that and see what’s going on.
hey, hope you’re doing well. Can you confirm if ROCm 7.2.1 fixes the issue for you?
The fluxer appimage will ‘install’ itself into /opt/ without your knowledge. I think because it’s essentially an electron package similar to stoat, standard notes and discord, large parts of it can self-update without needing to bump the actual package version, but this is really shitty behaviour considering what appimages are designed to do.
can you tell me which device this is with?
edit: nvm i saw you posted it directly into the thread - gfx1103 = 780M iirc
no hurry at all, thanks a bunch!
Someone on the github issue thread has been asking for clinfo output on affected systems, theorising that client issues are caused by issues with vendor detection.
This is a bit of an ask, but if it’s quick to jump forward and back between ROCm releases on your setup, would you be able to pass your clinfo output from 7.2.0 into the ticket linked above? No worries if not
Good news, seems there’s an existing internal ticket covering this defect. It’s an application-side issue pertaining to libProResRAW.so.
I believe we’re shipping a workaround at the ROCm framework side in 7.2.1
We’ll find out. It’s filed to the public issue tracker, which is a nice change of pace. Hope you can stay appraised of the progress from the following link:
have filed this to the ROCm team, hope to get someone looking into this tomorrow.
I don’t suspect it’s davinci resolve. This is likely due to rocm-opencl.
It’s a long weekend, so I likely won’t hear back from my colleagues until Tuesday at the earliest
Thank you for linking these. The second one suggests the following
Update: Turns out that this is happening because the update of opencl-amd package, the newest ROCm 7.2 drivers appear to not be compatible with DaVinci, I installed rocm-opencl-runtime from the extra repo since it still on 7.1.1 and now its working again… It also doesn’t work with opencl-mesa, it crashes launching a project
I’ll dig through to see what can be done about it.
Can you share the post here? Does it elaborate on what’s failing?
Valve do work pretty closely on contemporary hardware, but to your point, the kernel driver is decently robust, the display abstraction layer is largely common with the windows side (and also resides in the KMD on both environments), the mesa GL driver is solid and Marek’s team are also beginning to contribute towards RADV.
AMD are also heavily involved with improving Linux desktop experience (particularly with Wayland), and host regular hackathons to that effort.
probably, though I’ve not had that in a good while
in-place upgrades are fine for just about any contemporary, mainstream Linux distro. You may find this experience to be more robust than on windows.
I believe you can also upgrade via separate installation media, but you won’t find yourself needing to.
totally fine in my experience, and I ‘dumb guy’ my way through the whole thing.
my primary workstation system started with Fedora 28 > 43 - persisting through many hardware swaps and all sorts - though that’s with the gnome desktop.
I’d imagine you could conduct full system upgrades via Discover on KDE too.
appreciate you 😊