6 ms·
I don’t code for GPUs but it seemed pretty straightforward to me: 1. General purpose GPU code assumes optimization characteristics where memory constraints are
by eyelidlessness 5y ago
I don’t code for GPUs but it seemed pretty straightforward to me:
1. General purpose GPU code assumes optimization characteristics where memory constraints are less restrictive for this use case
2. Without optimizing for this platform, typical code will not exercise the full potential of the chip
The thread is discussing it as a design flaw; I don’t know if it is. But if normal “recompile for ____ target” in XCode or whatever isn’t enough for common workloads to be relatively close to optimal, and you have to do and know to do special work for the memory architecture… yeah that’s probably not ideal. And the other takeaway from the thread, that they’re likely to throw more memory hardware at the problem in the future, sounds right to me.
- ngcc_hk 5y agoThe key is apple code especially os and their tools. That is what m1 and future apple cpu and gpu are for. Hence optimisation should not be the issue. The whole thing is all about optimisation. The question is whether it affect other or 3rd party products (that cannot compete, or not shown to the public eg the private api ). And does apple care. Unless it shows is that limitation important ?
- ribit 5y agoThe only problem: Apple GPUs are general purpose GPUs and other GPUs have bigger memory constraints than Apple G13. It is kind of funny that they complain about the small cache on M1 Ultra when 3090 Ti has 10x less cache
- justsid 5y agoNot just that, but the claim that GPUs don’t mask memory latency by switching to other work is patently false as well. That’s exactly how GPUs do it. Memory bandwidth is a huge issue on GPUs and to maximize throughput, they absolutely do context switches to other work.
- dragontamer 5y ago> I don’t code for GPUs but it seemed pretty straightforward to me: I don't know all the words that are being used in this tweet. But the words I _DO_ understand are being used incorrectly, which is a major red-flag. 1. The temperature issues are non-sequitur, but that's where the discussion starts. There are a whole slew of power-configuration items on modern chips, none of them discussed in this set of twitter posts. 2. TLB is a CPU-issue, traditionally. I understand that Apple has an iGPU that shares the memory controller, but GPU-workloads are quite often linear and regular. It is difficult for me to imagine any step in the shader-pipeline (vertex shader, geometry shader, pixel / fragment shader) that would go through memory so randomly as to mess up the TLB. If you're saying the TLB is the problem, you need to come forth with a plausible use-case why your code is hopping around RAM so much to cause page-walks. 3. In fact, everything they say about GPUs in the thread is blatantly wrong at its face, or possibly some kind of misstatement about the peculiarity of the M1 Apple iGPU. 4. I realize that mobile GPU programmers are always talking about this "tile-based rendering" business (popular on Apple / Android phones), and I've never bothered to learn the details of it. But I can almost assure you, even in my ignorance, that this has nothing to do with TLBs at all. ----- The argument simply does not track with reality, or my understanding of GPUs in general. The vague advice I've heard for GPUs on mobile systems is to learn about the peculiarities of tile-based rendering, and to optimize for it specifically, because that's the main difference in GPU-architecture between Desktop GPUs and Phone GPUs. But nothing discussed in this set of twitter posts seems to match what I've often heard about iPhone/Android GPU programming. I've seen the experts advice on Android/Apple phone architecture / tile-based rendering. I don't know it, but... I think I can recognize it when I see them talking. This set of twitter posts is not an expert talking.
- deleted 5y ago[deleted]