Discussion Qualcomm Snapdragon Thread

[ikjadoon]

5000 word review if the Surface Laptop 7 with Snapdragon X, by Zac Bowden:

Microsoft's Surface Laptop 7 Copilot+ PC is finally the best clamshell laptop on the market after 8 years of iterations

Surface Laptop 7th Edition is the clamshell form factor perfected — it's the laptop to beat in 2024.

www.windowscentral.com

Great to see battery life tested here and at 250 nits. That's exciting to see; though previously PCMark 10 Applications battery test was found to not support ARM64, so this would be a phenomenal result if it's running some test under emulation.

I'm interested at this line:

That includes heavy applications like Photoshop or Davinci Resolve, which are both ARM64 native and work so well on Surface Laptop 7.

Some reviewers have noted DaVinci Resolve (which is still a beta) can be rather rough on the SL7. Perhaps different types of footage or different builds?

I've been using DaVinci Resolve more often, so it would be great to see it get full ARM64 compat.

 

[Hitman928]

Some reviewers have noted DaVinci Resolve (which is still a beta) can be rather rough on the SL7. Perhaps different types of footage or different builds?

I've been using DaVinci Resolve more often, so it would be great to see it get full ARM64 compat.

I remember seeing one review (can't recall which one) where they tested DaVinci Resolve and the 1080p sample they used worked well enough, but when they tried to work on a 4K one, it was awful. I'll see if I can find it, but I'll be honest, I'm not gonna look that hard, lol.

 

[FlameTail]

Jon Masters got the Dell XPS 13 Snapdragon:

https://twitter.com/x/status/1806896575395836059

Dude named the laptop as 'gerard'

 

[FlameTail]

Phonebuff's battery test of Snapdragon X Elite Surface Laptop 7 vs M3 Macbook Pro 14

Spoiler: Surface Laptop beat the Macbook

 

[naukkis]

RISC doesn't mean anything anyway. Historically it means exactly two things: fixed-length and load-store. Beyond that it just turns into "I dunno, whatever people think was cool in the 80s, man." RV holding to this weird idea of 80s orthodoxy rules out a lot of useful functionality - ie, paired load/store, indexed addressing modes, pre/post-increment addressing, embedded SIMD, carry, etc, etc, etc. A certain amount of this is a product of an insistence on rigid 1W2R access.

RISV-C is about keeping instructions as independent as possible. Indexed addressing modes and pre/post incrementing addresses combine arithmeth with load-store operations. Those was really useful for hand made assembly programming but those are obstacle to design very high-speed cpu with massive out-of-order window where data addresses have to calculated thousand of instructions before actual load-store. With those instructions they have to implement whole new cpu portions which unlink address calculation to actual data manipulation to being able to widen that window - with RISC-V approach that window could be stretch in code with compiler and no additional hardware needed in implementation. Jim Keller have been very loud to defend that RV approach. And for SIMD - RV style to made it vector machine instead of hardwired SIMD makes hardware totally agnostic to SIMD register width. SVE is plain braindead implementation, with RV SIMD code is executable with any simd hardware, and without SIMD hardware at all, and code can extract full performance from wide SIMD execution from same code compilation.

 

[igor_kavinski]

And for SIMD - RV style to made it vector machine instead of hardwired SIMD makes hardware totally agnostic to SIMD register width.

Very interesting point. Created a thread for us to discuss it more.

Question - Are scalable vectors the ultimate solution to fixed width SIMD?

This thread inspired by the following quote from http://www.portvapes.co.uk/?id=Latest-exam-1Z0-876-Dumps&exid=threads/qualcomm-snapdragon-thread.2616013/post-41241585 And for SIMD - RV style to made it vector machine instead of hardwired SIMD makes hardware totally agnostic to SIMD register width. @naukkis @SarahKerrigan...

forums.anandtech.com

 

[Nothingness]

Indexed addressing modes and pre/post incrementing addresses combine arithmeth with load-store operations. Those was really useful for hand made assembly programming but those are obstacle to design very high-speed cpu with massive out-of-order window where data addresses have to calculated thousand of instructions before actual load-store.

I fail to see how the uop split required for address calculation and register update prevents massive OOO windows.

With those instructions they have to implement whole new cpu portions which unlink address calculation to actual data manipulation to being able to widen that window - with RISC-V approach that window could be stretch in code with compiler and no additional hardware needed in implementation.

You mean RISC-V has some form of black magic that doesn't require an additional instruction to update the address after doing the ld/st? A thing that can be done in a single instruction in AArch64?

I wonder why some companies added instructions to get extra addressing modes in RISC-V and had to make special versions of compilers. And why they have to implement uop fusion for high perf CPU to circumvent the stupid fundamentalist 80s RISC approach of R-V. They surely are stupid.

Jim Keller have been very loud to defend that RV approach.

Jim has been very vocal about any ISA not mattering for high perf CPU.
Anyway, no matter what he said, what do you expect from the CEO of a company doing RISC-V chips?

 

[igor_kavinski]

They surely are stupid.

Let's discuss their stupidity in my thread before we get FlameTail all upset for hijacking his thread

 

[Nothingness]

Jon Masters got the Dell XPS 13 Snapdragon:

https://twitter.com/x/status/1806896575395836059

Dude named the laptop as 'gerard'

Poor Jon who has to run Windows

 

[naukkis]

I fail to see how the uop split required for address calculation and register update prevents massive OOO windows.

It doesn't. But it has to split if code wants to create addresses few thousands instructions before actual load.

You mean RISC-V has some form of black magic that doesn't require an additional instruction to update the address after doing the ld/st? A thing that can be done in a single instruction in AArch64?

I wonder why some companies added instructions to get extra addressing modes in RISC-V and had to make special versions of compilers. And why they have to implement uop fusion for high perf CPU to circumvent the stupid fundamentalist 80s RISC approach of R-V. They surely are stupid.

No. Risc-V doesn't bring anything. Every cpu is capable calculating addresses as they calculate anything. Those addressing modes that RISC-V lacks are there to do some basic addressing calculations combined with actual load/store instructions. Those very extremely useful for hand assembly coding - and were also beneficial for simple cpu's where they could implement simple address math in specialized address generation units. But cpu designs are about to extract so big OOO windows that separating address generation from actual load/storing will come beneficial for extreme performance designs. RV is right there because it lacks that cheap implementation currently used.

 

[SarahKerrigan]

RISV-C is about keeping instructions as independent as possible. Indexed addressing modes and pre/post incrementing addresses combine arithmeth with load-store operations. Those was really useful for hand made assembly programming but those are obstacle to design very high-speed cpu with massive out-of-order window where data addresses have to calculated thousand of instructions before actual load-store. With those instructions they have to implement whole new cpu portions which unlink address calculation to actual data manipulation to being able to widen that window - with RISC-V approach that window could be stretch in code with compiler and no additional hardware needed in implementation. Jim Keller have been very loud to defend that RV approach. And for SIMD - RV style to made it vector machine instead of hardwired SIMD makes hardware totally agnostic to SIMD register width. SVE is plain braindead implementation, with RV SIMD code is executable with any simd hardware, and without SIMD hardware at all, and code can extract full performance from wide SIMD execution from same code compilation.

You'll note how I said embedded SIMD, not "we really think early-90s vector supercomputers were cool" SIMD. As in, 2x32 or 4x16 ops in registers that you're already paying for. Scalable vectors require a whole 'nother register file, among their other issues.

"Jim Keller sez" - argument from authority; not terribly impressed.

"Combining arithmetic with load-store" - how is this only useful for hand assembly programming? Compilers are entirely capable of emitting these for loop bodies and do so just fine on ARM, PPC, and other RISCs that don't idolize 1W2R as some kind of ideal.

In the real world, RV implementors have repeatedly re-added the features you insist don't matter.

 

[FlameTail]

https://twitter.com/x/status/1806830313831829780

Is this frame interpolation hardware accelerated like DLSS or not?

 

[podspi]

Can you guys stop arguing about ARM vs RISC-V, and talk about the amazing standby performance of Snapdragon X Elite?

The standby performance is pretty good. That is probably the most significant notable difference in day-to-day use.

Sure. I don't have any delusions that we'll be getting RISCV laptops soon.
But where are the fanless ARM laptops? Only seems to be Apple...

Personally, I don't mind there being fans on a laptop as long as they aren't running all the time in reasonable workloads. 2-in-1s and tablets make better sense for fanless applications, imho.

 

[Nothingness]

Some progress on the Linux front: Qualcomm Snapdragon X Elite Powered ASUS Vivobook S15 Laptop Seeing Linux Patches.

The good:

Known to be working with the yet-to-be-merged Vivobook S15 DT is CPU frequency scaling, NVMe storage but currently at PCIe Gen4x2 speeds rather than Gen4x4, keyboard and touchpad, the WCN7850 WiFi, two USB Type-C ports, the internal eDP display, and other basic functionality. The Adreno GPU and Bluetooth can also be made to work with additional yet-to-be-upstreamed kernel driver patches.

The bad:

But currently broken with this ASUS Vivobook Snapdragon X laptop on Linux is battery monitoring, display orientation switching, the USB Type-A ports, the front camera, the SD card slot, the HDMI connector, USB4, and any functionality relying on the laptop's embedded controller (EC). So it's still a long road ahead before the Snapdragon X Elite laptops are really usable on Linux... With relying on DeviceTree rather than ARM64 ACPI and the like also makes the Linux support experience for this new range of Qualcomm-powered laptops all the more frustrating and challenging. And with the pace of Linux kernel cycles, it basically means a number of months at least before there is the potential for nice out-of-the-box support for these Snapdragon X Elite laptops under Linux.

 

[igor_kavinski]

The best contributor to Linux for SD Elite X could be Microsoft with their opensource work but with their vested interest in making Windows 11 a direct alternative to MacOS, unfortunately that doesn't seem likely.

 

[gdansk]

Personally, I don't mind there being fans on a laptop as long as they aren't running all the time in reasonable workloads. 2-in-1s and tablets make better sense for fanless applications, imho.

Good for you, you have a billion options. But there's only one fanless laptop that doesn't suck on the market now. Selfishly I was hoping to have 2 options by now.

 

[eek2121]

RV is a potato. Compared to that, ARM64 is a wunder-ISA. (Compared to PPC, ARM64 still looks pretty good but decidedly less miraculous.)

It absolutely is not. Don’t compare the dated implementation found on SBCs to a decent implementation on N3. The fastest RISC-V chip is quite a beast, it is a custom design for a single vendor, so naturally we don’t get to see benchmarks, but it is right up there with x86 and ARM in terms of performance.

You won’t see a “good” RISC-V implementation until there is a reason for it to exist (software support is abysmal, but improving)

Ask the Tenstorrent guy his thoughts on RISC-V.

I will be so glad the day that this x86 vs ARM vs RISC-V vs whatever nonsense can be put to rest. None of the mentioned platforms have any advantage over the other. It is ALL about design and implementation, which comes from the talents of the people building the thing (there aren’t many folks that even CAN build a high performance chip, of any type)

Even if, let’s say ARM, for example, has a disadvantage, they can modify the ISA or others to remove that limit. These platforms aren’t fixed. This includes x86. ARM, x86, and RISC-V are ALL drastically different from their original implementations.

Stop looking at the ISA and start looking at the talent building the thing.

Much of the team that designed the M1, for example, have moved on. Follow where they go to find out who is designing the next banger of a chip.

Just don’t expect huge gains moving forward. I echo the sentiment some others have brought up: we appear to be gradually hitting some kind of bottleneck, regardless of ISA.

 

[SarahKerrigan]

It absolutely is not. Don’t compare the dated implementation found on SBCs to a decent implementation on N3. The fastest RISC-V chip is quite a beast, it is a custom design for a single vendor, so naturally we don’t get to see benchmarks, but it is right up there with x86 and ARM in terms of performance.

"She lives in Canada. You wouldn't know her."

 

[FlameTail]

The thing with X Elite/Hamoa is that it has an Apple M-Max class CPU paired with a base-M chip class GPU. This is an incredibly unbalanced setup. That M-Max class CPU meant that fanless options were never really viable due to the CPU's power consumption.

What they should for 2nd gen is have 2 dies:

Die A
4P + 4E Oryon cores (Base-M chips class CPU)
Adreno 830 overclocked (Base-M chip class GPU)

Die B
12P + 4E Oryon cores (M-Max class CPU)
2x Adreno 830 overclocked (M-Pro class GPU)

Die A would be suitable for fanless laptops.

 

[Doug S]

The thing with X Elite/Hamoa is that it has an Apple M-Max class CPU paired with a base-M chip class GPU. This is an incredibly unbalanced setup. That M-Max class CPU meant that fanless options were never really viable due to the CPU's power consumption.

What they should for 2nd gen is have 2 dies:

Die A
4P + 4E Oryon cores (Base-M chips class CPU)
Adreno 830 overclocked (Base-M chip class GPU)

Die B
12P + 4E Oryon cores (M-Max class CPU)
2x Adreno 830 overclocked (M-Pro class GPU)

Die A would be suitable for fanless laptops.

If they wanted a fanless SKU they could just sell one with half the P cores disabled, or that was quick to ramp down frequency if you tried to use all 12 cores at once. With all the SKUs they have, the fact that not one is suitable for a fanless device indicates to me that either Qualcomm doesn't believe fanless matters or the big PC OEMs don't.