Its super early, given the presumed late summer/early fall 2026 release timeframe estimate. Thats what makes me the most skeptical about it. If there are already desktop ES floating around that are pushing scores like that, AMD should have a ton of time to optimize microcode, produce new steppings, and hone the boost algos. 9950X released August 15, and we didnt start seeing actual GB or CPU-z scores before around what, May/June or so?
Blender uses Embree as well but as you said don't know the exact version they are using for Geekbench also Skymont's FP is lagging when I looked at CnC it needs a boost.Nope. It uses SSE2NEON which is a translator. It is problematic for ARM CPUs. You ever wondered why Apple’s chips do poorly in this subtest vs native Blender where they beat Intels equivalent. This subtest doesn’t reflect real applications because of outdated code.
AMD also beats Intel in Blender but loses in Cinebench R23.
GB6 probably uses an old build or some very badly optimised build of Intel Embree.
The Blender open test shows that GB6 Ray tracer test isn’t indicative of real world performance.
In fact it shows how behind Intel is in FP when it can’t feed more watts to its cores.
View attachment 127420
Blender - Open Data
Blender Open Data is a platform to collect, display and query the results of hardware and software performance tests - provided by the public.opendata.blender.org
Enabling AVX512 has benefits for the scalar fp code gen path too, I don't think this holds for SME. While the benefits are situational and might be they don't apply in geekebench, they are there (compiling for avx512 gives compiler access to 32 architectural fp registers, even when running a scalar code, what means fewer spills to stack, this level the field against ARM which also have 32 architectural registers for the fp paths (both scalar and simd)).
Geekbench is using outdated compilers anyway. I wonder if they will update for the APX rollout, or pretend it doesn't exist.
Somebody would need to rewrite code to wrap the translated intrinsics in something more high level, like google's highway, but I guess using SSE2NEON is fast way of getting it to compile instead of optimizing for perf. If ARM cared, they would contribute the resources, I wonder if they maintain they own alternative to embree.
yeah kind of funny x86_64 is stuck at 16 architectural registers since introductions and they haven't bothered to increase it till now
don't know about Geekbench but we will get a new Cine bench version lol if their release cycle continues.
It just depends on how the devs implement Intel Embree, Blender uses SIMD everywhere and is much better implementation than the SS2NEON in RenderKit.
1) large scale (compared to available) register renaming helped mitigate the problem
AVX512 should be compared with SVE2 and is much more useful than SME. SME is an AI extension and Primate Labs is ruining its database. They need to separate or have a toggle for cores that have shared accelerators.
If they even bother? Intel just shut down their Clear Linux distro, so they won't even have quick support for their own new stuff.
Adoption should be in theory much quicker than AVX512 since rewrite for SIMD isn't required, but the jury is out on what real benefit APX will bring, Intel claims are pretty modest - is extra complexity of a core worth it when you can just add another core?
It does not mitigate the problem I outlined. You can have 1000 entry big register file, but compiler can operate only on the architectural registers, so it will spill. The costs of spills can be mitigated by some tricks, but these do not always apply, so the best way is to minimise spills.
What that does have to do with anything? How many users Clear Linux had compared to RedHat, Ubuntu or whatever M$ is rolling in Azure. It's important the compiler get the support, and they got it already (this is one thing Intel still does much better than AMD, which is unable to get Zen5 scheduler model merged to mainstream llvm after a year since Zen5 release)
That's right,
Come to think of it, I don't remember whose article it was, but I've seen people say that the scheduling of Zen5 is not going well.
I doubt you have read anywhere an article about llvm scheduling model
Might be you confuse the issue with dual decoders or the fp scheduler latency problem, which are separate things to what I complain about. Right now in llvm, Zen5 is using Zen4 scheduling/cost model, generally it's not like it's tanking the performance, the difference between the two would most likely be visible only in code gen for some specific corner cases, but it's just showing that AMD doesn't care. In GCC I think RedHat engineers provided the corrected model and final tunings, though I might be wrong, and in upstream llvm the initial enablement for Zen5 (basically to ensure that people using -march=native don't shoot themselves in the foot) came barely in time, exceptionally landing into release candidate, and the PR to update the cost/scheduling model is open since March, without any updates from AMD side. Now, I would be more understanding if their own AOCC wouldn't be a downstream fork of LLVM itself. It's not like they don't know the codebase... And AOCC is not available on Windows, when Clang can be directly installed from within Visual Studio... 
Don’t worry, I’m sure Lip Bu Tan will cut out all the unnecessary instructions as a cost reduction measure. He heard SIMD uses a lot of “cash registers” and thought - we can’t have that.
He ain't cutting core business like NEX/Auto as for clear linux the company that wants to maintain it can fork it themselves.
Facebook
Twitter