Live data from Hacker News

GPU advancements in M3 and A17 Pro [video]

developer.apple.com

141–148 of 148 posts

Re: GPU advancements in M3 and A17 Pro [video]

#141

Earlier quoted context omitted.

Sorta, yeah! Also, your "128 cuda cores" of Skylake variety run at higher frequencies and work off of much bigger caches, so they are faster (in serial manner)... ...until they are slower, because GPU's latency hiding mechanism (with occupancy) hides load latencies very well, while CPU just stalls the pipeline on every cache miss for ungodly amounts of time... ...until they are faster again when the shader program us…

Thank you! > ...until they are slower, because GPU's latency hiding mechanism (with occupancy) hides load latencies very well, while CPU just stalls the pipeline on every cache miss for ungodly amounts of time... Is the GPU latency hiding mechanism equivalent to SMT/Hyperthreading, but with more threads per physical core? Or is there more machinery? Also, how akin GPUs "stream multiprocessors"/cores are to CPUs ones…

I'll leave your first question to the other comment here from frogblast, as I really battled with how to answer it well, given my limited knowledge and being an elbow deep into an analogy, after all. I got a writer's block, and frogblast actually answered something :D

> how akin GPUs "stream multiprocessors"/cores are to CPUs ones at the microarchitectural level?

I'd say, if you want to get a feel for it in a manner directly relevant to recent designs, then reading through [1], [2], subsequent conversation between the two, and documents they reference should scratch that curiosity itch well enough, from the looks of it.

If you want a much more rigorous conversation, I could recommend the GPU portion of one of the lectures from CMU: [3], it's quite great IMO. It may lack a little bit in focus on contemporary design decisions that get actually shipped by tens of millions+ in products today and stray to alternatives a bit. It's the trade-off.

> Are they out-of-order?

Short answer: no.

GPUs may strive to achieve "out of order" by picking out a different warp entirely and making progress there, completely circumventing any register data dependencies and thus any need to track them, achieving a similar end objective in a drastically more area and power efficient manner than a Tomasulo's algorithm would.

> Do they do register renaming?

Short answer: no.

[1] https://forums.macrumors.com/threads/3d-rendering-on-apple-s...

[2] https://forums.macrumors.com/threads/3d-rendering-on-apple-s...

[3] https://www.youtube.com/watch?v=U8K13P6loyk ("Lecture 15. GPUs, VLIW, Execution Models - Carnegie Mellon - Computer Architecture 2015 - Onur Mutlu")

Re: GPU advancements in M3 and A17 Pro [video]

#142
post #2

I skimmed the video but a lot of it sounded more like advertising than technical information to me. On the other hand, I'm looking forward to watching the Asahi folks crack this stuff open.

What's not technical about it? It tells you what the new advancements in the M3/A17 GPUs are, what you should look out for, and how you can take advantage of them. It provides enough information so you can understand what technical tradeoffs you need to make when you target M3 / A17 GPUs. E.g. Register pressure is a real concern in large shaders, and this helps explain how the behavior would be different under a dynamic allocation scheme. It explains how the ray tracing acceleration works, and how it reorders the different intersection calls and how you should avoid intersection queries.

There are some hyperbole interjected about how incredible the performance is but that's only in between the useful data. (I did chuckle at the… enthusiasm of the speaker though)

This isn't a technical document for GPU designers. Apple doesn't really need or want you to understand exactly how the implementation works because that's basically trade secret for them. This is aimed at letting app / game developers know how they should optimize for the new GPUs, since previously Apple just made some ambiguous remarks about some of these new technology ("Dynamic Caching") without explaining what they meant.

But yes, I do like how the Asahi folks tend to end up documenting a lot of how these hardware works, but they also only have public information like this to start from so these are still useful info to have for them.

Re: GPU advancements in M3 and A17 Pro [video]

#143
post #9

Earlier quoted context omitted.

I don't know about your facts, but "Is it that hard to just copy the winning formula?" yes it is, thanks to IP law. And back in the day Steve Jobs already wanted thermonuclear war on Samsung, because he felt their flagship at the time was too close to the IPhone.

To be fair, there was a moment when Samsung was in full copy mode. All the way down to having their own version of the dock connector and a retail box that closely mimicked Apple. In retrospect, a bit embarrassing for a company we know is capable of much more.

The thing is, people do not like to learn a new UI to do the same thing on a different device. But they have to.

Re: GPU advancements in M3 and A17 Pro [video]

#144
post #133

Earlier quoted context omitted.

Mobile gamers dwarf the number of console and PC gamers.

What does dwarf in numbers actually means? As in facts from certified market analysis company, showing actual number of players per platform.

What exactly is your argument?

Re: GPU advancements in M3 and A17 Pro [video]

#145

So ... the registers are dynamically allocated from a chunk of cache? Does this mean there, effectively, are no registers? Does this cache have one clock latency?

I doubt anyone will be able to answer questions this fine grained, not now (if the implementation is architecturally exposed - leaks into the ISA - and Asahi Linux group figures some of it out), or possibly not ever (if it's architecturally transparent and thus entirely micro-architectural). > Does this mean there, effectively, are no registers? I can only point out just for context that if by any chance you're askin…

Oh! Well, that explains that then. Wild!

Re: GPU advancements in M3 and A17 Pro [video]

#146

Earlier quoted context omitted.

I doubt anyone will be able to answer questions this fine grained, not now (if the implementation is architecturally exposed - leaks into the ISA - and Asahi Linux group figures some of it out), or possibly not ever (if it's architecturally transparent and thus entirely micro-architectural). > Does this mean there, effectively, are no registers? I can only point out just for context that if by any chance you're askin…

Oh! Well, that explains that then. Wild!

There is a fairly informative survey on the subject: https://www.osti.gov/servlets/purl/1332070 (A Survey of Techniques for Architecting and Managing GPU Register File)

Re: GPU advancements in M3 and A17 Pro [video]

#147

Earlier quoted context omitted.

Oh! Well, that explains that then. Wild!

There is a fairly informative survey on the subject: https://www.osti.gov/servlets/purl/1332070 (A Survey of Techniques for Architecting and Managing GPU Register File)

An easier to read research article that's narrower in subject and seemingly more relevant to the OP: https://research.nvidia.com/sites/default/files/pubs/2012-12... ("Unifying Primary Cache, Scratch, and Register File Memories in a Throughput Processor", 2012)

Re: GPU advancements in M3 and A17 Pro [video]

#148
post #137

Earlier quoted context omitted.

Not on mobile, which is where Apple GPUs come from. FP32 is not necessary for many computations related to graphics, it is just simpler to deal with one data type.

Are you claiming that people aren't using FP32 on mobile, or are you claiming that people are using FP32 on mobile but could technically have gotten away with FP16? If it's the latter, it's still correct to say that FP32 is king in mobile graphics.

Unless people explicitly ask for high or at least medium precision in the code, they probably will get FP16 floats on a mobile chip, which is totally fine for most fragment shader calculations.
Post reply on HN