yes

I got a pro because it was heavily discounted at the time. The one thing I sort of appreciated is the display LTPO thing, which enables it to gear all the way down to 1hz to save power.

thing is kinda moot since the 9a and 10a achieve significantly better battery life than the 10 pro (10a uses the prior gen SoC which seems to have better idle power characteristics).

it was, just in an early state under the developer settings

vendor collaboration is difficult to get right. hope it all goes well.

I genuinely wish that would be the case but client portfolio performance rarely has any bearing on it.

I guess I don’t have a comprehensive understanding of the proportion of affected users but I don’t think Intel suffered at all for the raptor lake failures, even though it affected workstations and notebooks (though I could be mistaken).

not trying to defend anyone but graphics drivers (particularly in windows) are black magic fuckery. It’s no easy task, Intel Arc has been a very public example of how difficult this can be with their first foray into serious dgfx.

I don’t think client gfx will really impact their share price either. If there was a delay with server/dc products them maybe.

fsr 4’s algo was enabled on rdna 4 via hardware changes. people will argue that it works on rdna 2 & 3 via a leaked int8 path, often leaving out that:

• it’s not identical in terms of visual quality (even though it does often improve upon 3.X)
• most critically, it doesn’t generally offer the same level of perf uplift to make it worthwhile (though there are a handful of very good cases)

I suppose I’m kind of opinionated about the whole upscaling and mfg ‘meta’ of (mostly) pc gaming today, but I find it sad that this is what end users clamour for, rather than for games to just not run like shit to begin with.

can you elaborate on these issues

what’s wild is that you’d post this in Linux gaming (rather than a generic Linux message board), where technologies like display independent VRR, scaling and HDR become increasingly relevant.

Wayland is the standard today, in that

• The xorg development team moved directly on to it
• It’s the default for major distros and desktop environments

Arguing about this is an exercise in futility.

If you’re not trolling, I’m genuinely sorry that you’re wasting time and effort down in this rabbit hole occupied by shitty pundits preying on young, impressionable minds, claiming they wish to ‘strip the politics away from software’ when they’re busy doing the direct opposite of what they preach.

cool, I’m just gonna go ahead and enjoy my contemporary display technologies and improved security.

also mixed display scaling values and extended colour space support. Like there’s no argument against today. There were breaking changes as first, sure. The software ecosystem has more or less caught up.

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:

https://github.com/ROCm/ROCm/issues/5970

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.