Apple M1 SoC

whoa! thanks for the info. i was in the middle of lamenting between getting a 64GB or 256GB iPad mini with a15. as it have no microsd card slot. or wait for a new M1 mini. or get the M1 air.

i guess i need to wait for lenovo legion y700 to come to my region

Spoiler

(i will mostly use the tablet for reading manga, but i would like the ability to play games when cousins comes to visit, etc. Currently I'm using android on switch and... yeesss... very long load time. The performance is still good tho)

 

@PSman1700 lenovo y700 actually have higher resolution than iPad air m1. i wonder, maybe the throttling of M1 iPad air is because apple optimized it for burst performance instead of long sustained performance. Ideally the performance governor automatically understand the workload and setup the clock speeds and voltages accordingly. But i have never found a tablet or phone that properly switch performance governor automatically properly (other than "cheating" by switching to max allowed thermal for benchmarks....)

Does iPad M1 have a performance profile option? IIRC I've read somewhere that on M1 MacBook, apple provides a performance profile option. But i can't find anything about it for iPad.

 

Is the M1 gpu still based on IMG patents/tech ? Or they're done with them and have a licence just for backward compatibility stuff ?

 

It is still a TBDR GPU at its core, so most likely it is bound to IMG patent licensing. Otherwise, there isn't much public info to say whether how far Apple has gone on the road of a custom architecture.

 

One thing of particular interest is whether they have adapted IMG's "multi-core GPU" IP (in A/B-series) for 2-die M1 Ultra (and allegedly the 4-die Jade-4C for Mac Pro) in some ways.

 

Base TBDR patents are expired by now. As you say it’s really difficult to say from the API and testing just how the silicon is organized and whether it would infringe on any current patents.
It’s a bit of a moot point given that Apple does have a patent licensing agreement with ImgTech. It may be that this is just to avoid having to spend resources on future legal battles, but it’s difficult to know, much less what Apples future plans might be.
From a tech geek point of view, I’m thrilled that there is someone with deep pockets pushing a TBDR GPU architecture forward. Yes, there are points to standardisation but total homogenity is also a bit boring. Apples GPUs seem to do very well running all kinds of code and do really well on code that explicitly target them. It would be a different situation if they pushed something that sucked just for the sake of being proprietrary.

 

I severely doubt it has anything to do with the Albiorix architecture; last time I heard anything Apple hadn't licensed any architecture above Rogue, as they've re-written a healthy portion of that base architecture (mostly ALUs?). Unless I'm understanding their data for their GPU wrong each cluster or "core" consists still of 16 SIMD lanes capable of 2 FMACs each, 2 TMUs and 1 ROP/RBE. Anything Albiorix would have to have single FMAC 128 SIMD lanes/cluster.

IHVs tend to one way or the other renew or expand old patents. For the last paragraph I'd love to see Apple pushing for some sort of geometry tiling as mfa suggested here in the forums at one point. You can search for JohnH's last conversations here with a developer, where it's obvious that Apple tends to handle quite a few cases different than IMG and that not always for the better.

 

Yes, this was one of my main concerns when Apple started recruiting with the expressed purpose of creating "their own world class graphics IP", and then followed up by not only not buying ImgTech, but saying they wouldn’t license their IP. Just how many hoops would Apple have to jump through to dodge patent infringements, and what ultimately would the costs be in terms of die area/efficiency/power draw? I want the architecture to be as efficient as it can possibly be at a given time, without the constraints of tiptoeing through a patent minefield. Apple does have a license agreement though, and I hope it is broad and long lasting enough that such concerns are unfounded.

As an aside, not only do I have a soft spot for TBDRs since the Kyro days, but different folks working at ImgTech has contributed a lot to these forums over the years, and always in a very constructive manner. When someone like JohnH speaks about his field, one shuts up and listens because he knows whereof he speaks. And it is appreciated that he takes the time to do so.

 

Here's to say that John himself admitted here in the forum that if possible he'd rather have the advantages of both worlds (IMR vs. TBDR) and I can't say I disagree. My layman's instinct tells me that we still have years ahead before GPUs move to almost entirely programmable architectures. In the meantime I'd be delighted to see architectures that can accomplish the benefits of both sides without inheriting each sides disadvantages. Unfortunately public detaills on how Qualcomm Adreno GPUs handle things, but I think their GPU drivers attempt something along that line. Now if it's something that's mostly sw/driver limited I'd love it to expand into "supporting" hw/algorithms too. Here's to say that I have no idea if today's Adrenos already have fragments in that direction.

Unfortunately Apple has the advantage of having its own API and there the GPU driver in the majority of cases reacts as expected; on the Android side developers have a constant headache of unexpected/unwanted behavior.

 

Apple Silicon Exclusively Hit With World-First "Augury" DMP Vulnerability | Tom's Hardware (tomshardware.com)

Similar to Spectre/Meldown on x86 processors but not limited to actively in use data. Apple know of it as the researchers first shared the discovery with Apple but Apple hasn't commented on what they'll do to mitigate it.

Regards,
SB