Yes correct. But there aren’t public versions yetYeah; As long as the GPU driver has an ARM compatible version, should be possible to just slot into PCIe.
Yes correct. But there aren’t public versions yetYeah; As long as the GPU driver has an ARM compatible version, should be possible to just slot into PCIe.
Uh it depends on what GPU it is! And iGPUs have improved a ton in an absolute sense tonget them to good enough. Qualcomm isn’t targeting the top enthusiast gamers.Especially because of the GPU. I knew some gamers, who bought a new graphics card every half year.
Unless ARM/Qualcomm/Microsoft devise a standard efficient way to use external graphics cards, I bet "pro gamers" won't be too happy about an ARM SoC with integrated GPU.
Well, knowing these guys and based on QC; their track record is more direct than with the others save Apple.Gauntlet thrown … though I’ll repeat my previous statement: IPC leader but in which workload? When it’s close that matters …
I for one can’t wait to see Crysis run on a Grace Hopper GPUNvidia already has arm gpu driver to facilitate grace hopper and their other soc projects. And amd had a Radeon in a Samsung arm chip.
Even within GB6 ST there are subtests - so stating you have the overall IPC advantage on GB6 means you have the advantage on a weighted average of two geomeans of a bunch of independent tests and that's really what I'm getting at. Depending on the lead, you can easily get leads in some subtests and not others. Obviously Apple's lead on say Zen 4 is so substantial that well ... that doesn't really come into play, Apple Silicon is going to lead in all of the subtests though by differing amounts (even there, there are two subtests where Zen 4 gets close to M1, but not M4, in IPC). Further, leading in GB6's Clang subtest might be more important to some users while leading in HTML5 might be more important for others. Bottom line, as you expressed in the second post, I don't imagine that in the future any "overall" lead between the two will be substantial and will possibly be ephemeral generation to generation and, as I wrote, situational test to test.Well, knowing these guys and based on QC; their track record is more direct than with the others save Apple.
They like GB and Spec and CB stuff. It’s not AMD and Intel who go crazy with cherrypicking and compiler optimizations. Qualcomm did do the Linux thing, but at least later they just showed Windows and real demos, which I liked much more than stuff like: where they don’t explicitly give me numbers! But Intel’s was still more redeemable than AMD’s lol.
View attachment 29804
View attachment 29805
Basically I’m inclined to believe he means in GB6. Ofc X86 guys hate GB6 now because v6 even pre 6.2/3 seems more geared to real workloads and Arm cores do better, but it’s IMO the best out there especially on ST.
I think that's very likely. V2 will be fascinating - especially the E-cores. Apple has some built-in advantages here like its size and relationship with TSMC means Apple will likely have access to new nodes sooner and since it is vertically integrated it can more easily spend die area to improve performance. Having that said these are not insurmountable advantages and for the latter it’s important to remember that AMD and Intel are Qualcomm’s primary direct competitors (until more ARM chips come online) not Apple and we know that, so far Qualcomm appears to enjoy a substantial price advantage relative to them. So they also have room to play here. Basically all the ARM chip makers mustn’t cheap out on cache like they did in the early days of competing against Apple in the mobile space.I suspect “ahead of” would be really small and pending M5 anyways though. I don’t really care about beating Apple as much as I do want to see them both in the same +-10% range which I think is possible, but we’ll have to see.
Apparently, I'm to much used to embedded SoCs with limited interfaces. Qualcomm lists PCIe 4.0 for the Snapdragon X Elite (although only under "SSD/NVMe Interface").
But as you already said, the drivers still have to be ported, otherwise the best dGPU is just unutilized silicon.
Even within GB6 ST there are subtests - so stating you have the overall IPC advantage on GB6 means you have the advantage on a weighted average of two geomeans of a bunch of independent tests and that's really what I'm getting at.
Depending on the lead, you can easily get leads in some subtests and not others. Obviously Apple's lead on say Zen 4 is so substantial that well ... that doesn't really come into play, Apple Silicon is going to lead in all of the subtests though by differing amounts (even there, there are two subtests where Zen 4 gets close to M1, but not M4, in IPC). Further, leading in GB6's Clang subtest might be more important to some users while leading in HTML5 might be more important for others. Bottom like, as you expressed in the second post, I don't imagine that in the future any "overall" lead between the two will be substantial and will possibly be ephemeral generation to generation and, as I wrote, situational test to test.
Compiler optimizations I gotta agree with. AMD's ... well here's the thing ... I don't like that a first party did it for obvious reasons, but if I'm being honest and looking at the set of subtests if a 3rd party had constructed that list, it’s as reasonable as any other.
But the whole point of a normal benchmark like GB6 especially is to show some range and give a composite, also they didn’t even show a SpecInt which is arguably the single easiest to BS but also the hardest for just the compilation.Sure the geomean is meaningless but then it always is except as a convenient shorthand. Would replacing GB5 AES with GB6 object detection matter? Probably not. Would removing AVX-512 workloads entirely make a difference? Yeah a small one but then there are people who care about that. Just as there are users who care about the gaming subtests that you won’t find in GB and those two sets of users probably don’t overlap completely.
I could probably construct any reasonable suite of tests and get a result between 10 and 20% IPC which is why I both agree with your criticism and think it should be expanded. It’s the subtests that matter and at least AMD gave those scores* so if someone puts the extra effort in they can at least see how much improvement they’re workloads are likely to see.
*under ideal conditions for most of these vendors, as @leman said both here and on Anandtech forums there is so much run to run variation, especially in real world implementations, YMMV wrt any vendor supplied numbers no matter how honest they’re trying to be. Hell Apple seems to be low balling their (CPU) performance increases recently.
I think that's very likely. V2 will be fascinating - especially the E-cores.
Oh I agree. Hell I think they’ve done that for years now? It’s awesome because they leave us a little goodie to he surprised by, M4 ST being the latest example.Hell Apple seems to be low balling their (CPU) performance increases recently.
Yeah. I could be wrong, and it’s just measly — and you guys can call me out on it if it’s a joke, but I think realistically based on their past 1-3 years and how well they still did, based on where Cortex X is, and based on the team’s history — I’d be surprised if Oryon V2 didn’t get them in the M4’s IPC league (so +- 5-7%ish on SpecInt, GB6) and corrected some power stuff even independently of node.I think that's very likely. V2 will be fascinating - especially the E-cores.
PCIe is pretty common even on small scale (e.g. RasPi's SoC).
On the contrary, PCIe is a very bad choice for an internal SoC bus. It spends lots of area and power on features which are only useful when communicating over off-die high speed SERDES links to something that may be physically quite remote.PCIe makes for a great internal bus on the SoC die that is cost effective and can hook up easily to the different I/O blocks, since the I/O blocks are expecting to be sitting at the end of a PCIe bus already.
If one can take something away from UltraFusion, it’s that SERDES isn’t great for intrapackage interconnects; wide is the way.On the contrary, PCIe is a very bad choice for an internal SoC bus. It spends lots of area and power on features which are only useful when communicating over off-die high speed SERDES links to something that may be physically quite remote.
I can understand why you might think otherwise - lots of peripherals are available as standalone PCIe devices and you're probably thinking that the designers of such chips might want to license their contents as IP cores to SoC design houses. But most of the time, if you drill down into what's inside such PCIe peripheral ICs, there's a clean separation between the PCIe interface and the peripheral logic. Not only is this good design practice, it's common to simply license PCIe IP cores from someone else, and these are typically delivered as encrypted IP which the buyer does not have the right to alter or sub-license. So if they decide to offer their peripheral as IP to others, it won't be delivered with a PCIe interface, they'll just figure out what on-die bus their customers expect and put appropriate bus interface glue in front of it.
In the Arm SoC world, most peripherals use AXI, AHB, or APB. All three are Arm standards. AXI is the highest performance, and is the interface you'll find at the edge of Arm-designed CPU complexes. AHB and APB are older, slower, and simpler standards than AXI. They persist since they're easily bridged to AXI, and virtually all SoCs have a bunch of simpler I/O peripherals which need very little performance, meaning the gate and power overhead of implementing even AXI in every single one would be a waste.
On the contrary, PCIe is a very bad choice for an internal SoC bus. It spends lots of area and power on features which are only useful when communicating over off-die high speed SERDES links to something that may be physically quite remote.
I can understand why you might think otherwise - lots of peripherals are available as standalone PCIe devices and you're probably thinking that the designers of such chips might want to license their contents as IP cores to SoC design houses. But most of the time, if you drill down into what's inside such PCIe peripheral ICs, there's a clean separation between the PCIe interface and the peripheral logic. Not only is this good design practice, it's common to simply license PCIe IP cores from someone else, and these are typically delivered as encrypted IP which the buyer does not have the right to alter or sub-license. So if they decide to offer their peripheral as IP to others, it won't be delivered with a PCIe interface, they'll just figure out what on-die bus their customers expect and put appropriate bus interface glue in front of it.
I was thinking of mentioning something about cases like this. Often, SoC designers can fake just enough of PCIe to make unmodified (or nearly so) PCIe device drivers load and work. PCIe is mostly about memory-mapped I/O, so there's really not a lot to emulate. Can the driver dereference a MMIO base pointer plus offset and have ordinary memory address decoding transparently route the "memory" access to the appropriate peripheral register? If so, you're basically there.And double checking on the BCM2711, it does have a PCIe lane which gets used for an external USB controller. Its internal Ethernet controller just happens to look similar enough to PCIe to load the Realtek PCIe driver, and doesn't sit on PCIe.
I was thinking of mentioning something about cases like this. Often, SoC designers can fake just enough of PCIe to make unmodified (or nearly so) PCIe device drivers load and work.
I think that was actually reported.This dispute has always seemed odd. One company holding an Arm architectural license acquires another also holding an Arm architectural license, so what's the problem from Arm's side?
Here's my best guess. No sources here, this is pure speculation from me, and I'm not an insider in any way. (Or a lawyer.) Maybe Arm negotiated much lower up-front and/or royalty rates for Nuvia to help them since they were a startup, but doesn't want to let Qualcomm use that to backdoor their way into lower rates. So they're taking flier with this legal theory (which may have a basis in the contract, for all I know) that Nuvia's contract ended at the moment of acquisition, and now QC needs to renegotiate to bring all former Nuvia projects under QC's architectural license umbrella.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.