It's still somewhat interesting because threads are a low-level programming primitive. If you can come up with work for 40k simultaneous threads, you can use the GPU effectively. For some tasks this parallelization is obvious (a HD video frame has 2 million pixels and shading them independently is trivial), and of course often it's anything but.

I see if with every major product announcement, the worst are usually Apple threads but it’s not constrained only there.

Btw. it appears you are shadow banned. You might want to check some of your comments and then contact dang.

They also aimed at markets that are ripe for disruption, because of weak competition: The MP3 player market before the iPod, the PDA-with-a-SIM-card market before the iPhone, etc. pp. all could be reasonably disrupted by just delivering a reasonably (but not even best-in-class, specs wise) product with better UX (not hard, in the cases mentioned) and massive marketing. You can't do that in a heavily competitive market that's already full of these products. VR headsets are probably closer to the "ripe for disruption" end of the spectrum, and I think the Vision will probably do well. But I doubt the "Apple Car" plans that have been floating around for 10 years now will ever lead to anything.

The iPod's only notable hardware that wasn't just a random off the shelf part was the click wheel, the chips were all off-the-shelf (until old iPhone chips counted as that), and iPhones didn't get custom chips until the 4.

So I guess the other part of the winning formula is "use market dominance in one sector to subsidize expansion into the next". I guess that's indeed one area where Google could reasonably try to be less inept, but I think all the institutional inertia makes that impossible by now. They'll go the DEC route of just drowning in their own internal problems until someone buys them up.

Sorry, I was around for DirectX 1.0 back when GPUs were called "graphics accelerators", and don't see how that's possible.

Do you have a source for that, or is there some implicit caveat like counting some emulation later or something? Even then...

24,576 threads (or however many, I didn't validate the number and it depends on the occupancy, which depends on thread resource usage, like registers => depends on the shader program code) is how many threads can be executed concurrently (as opposed to in parallel), as in, how many of them can simultaneously reside on the GPU. A subset of those at any time are actually executed in parallel, the rest are idle.

You can think of this situation as follows using an analogy with a CPU and an OS:

1. 128 * the-number-of-cores is the number of CPU cores(*1)

2. 24,576 threads is the number of threads in the system that the OS is switching between

Major differences with the GPU:

3. On a CPU context switch (getting a thread off the core, waking up a different thread, restoring the context, and proceeding) takes about 2,000 cycles. On a GPU _from the analogy_ that kind of thread switching takes ~1-10 cycles depending on the exact GPU design and various other details.

4. In CPU/OS world the context switching and scheduling on the OS side is done mostly in software, as the OS is indeed software. In GPU's case the scheduler and all the switching is implemented as fixed function hardware finely permeating the GPU design.

5. In CPU/OS world those 2,000 cycles per context switch is so much larger than a roundtrip to DRAM while executing a load instruction that happened to miss in all caches - which is about 400-800 cycles or so depending on the design - that OS never switches threads to hide latencies of loads, it's pointless. As far as performance is concerned (as opposed to maintaining the illusion of parallel execution of all programs on the computer), the thread switching is used to hide the latency of IO - non-volatile storage access, network access, user input, etc. (which takes millions of cycles or more - so it makes sense).

In the GPU world the switching is so fast, that the hardware scheduler absolutely does switch from thread to thread to hide latencies of loads (even the ones hitting in half of the caches, if that happens), in fact, hiding these latencies and thus keeping ALUs fed is the whole point of this basic design of pretty much all programmable GPUs that there ever were.

6. In real world CPU/OS, the threads that aren't running at the time reside (their local variables, etc) in the memory hierarchy, technically, some of it ends up in caches, but ultimately, the bulk of it on a loaded system is in system DRAM. On a GPU, or I suppose by now we have to say, on a traditional GPU, these resident threads (their local variables, etc) reside in on-chip SRAM that is a part of the GPU cores (not even in a chunk on a side, but close to execution units in many small chunks, one per core). While the amount of DRAM (CPU/OS) is a) huge, gigabytes, and b) easily configurable, the amount of thread state the GPU scheduler is shuffling around is measured typically in hundreds of KBs per GPU Core (so on the order of about "a few MBs" per GPU), and the equally sized SRAM storing this state is completely hardwired in the silicon design of the GPU and not configurable at all.

Hope that helps!

footnotes (*1) a better analogy would be not "number of CPU cores", but "number-of-CPU-cores * SMT(HT) * number-of-lanes-in-AVX-registers", where number-of-lanes-in-AVX-registers is basically "AVX-register-width / 32" for FP32 processing which (the latter) yields about ~8 give or take 2x depending on the processor model. Whether to include SMT(HT) multiplier (2) in this analogy is also murky, there is an argument to be made for yes, and an argument to be made for no, and depends on the exact GPU design in question.

Let’s guess: maybe they have different drivers? Would be far from surprising, given that they’re running on different processors.

How very odd.

Imagination Technologies is a near 40 year old British silicon IP company that has been doing GPUs for quite some time, just not ones supporting DX up until now, and it has nothing to do with MS (in terms of ownership / rights / etc).

[1] https://learn.microsoft.com/en-us/windows/win32/direct3d11/o...

Of course the idea of Apple switching from Metal to D3D is rubbish, but a Proton-like solution for macOS totally makes sense (maybe the "Game Porting Toolkit" will be exactly that eventually).

Perf of a GPU can be limited by any one of the thousand little things within the micro-architectural organization of the GPU in question, any on-chip path can become the bottleneck:

1. DRAM bandwidth

2. ALU counts

3. Occupancy

4. Instruction issue port counts

5. Quality of Warp scheduling (the scheduling problem)

6. Operand delivery

7. Any given cache bandwidth

8. Register file bandwidth (SRAM port counts)

9. Head of the line blocking in one of the many queues / paths in the design whatever that path is responsible for:

- sending memory request from the instruction processing pipelines to the memory hierarchy - or sending the reply with the data payload back, - or doing the same but with the texture filtering block (rather than memory H), - or the path that parses GPU commands from command buffers created by the driver, - or the path that subsequently processes those already decoded commands and performs on-chip resource allocation, warp creation / tear down, all of which need to be able to spawn the work further down fast enough to keep the rest of the design fed;

and so on and so on and so on.

By the time a high quality design is fully finished, matured, and successful enough on the market to show up on everyone's radar outside of the hardware design space, due to the commonly occurring ratios of costs of solutions for these various problems above, it usually ends up being 1, 2, or 3, but that's experimental data + statistics + survivorship bias, there is no "definition" that that's the case.

Further, what's "commonly occurring" is changing over time as designs drift into different operational areas in the phase space of operating modes as they pick out low-hanging fruits, science and experience behind the micro-architecture grows, common workloads change in nature, and new process nodes with new properties become the norm. Doubling up of F32 ALUs in Ampere is a good example of that, that was done in a way that changed the typical ratios substantially. And now M3 threw a giant wrench into incumbent statistics of relationships between (3) and the rest of the limiters, as well as between (3) and what's actionable for a GPU program developer to do to mend it.

You can be low on DRAM bandwidth util and ALU util at the same time. How would that be if there were no other limiters?

Generally, a component X of a computer system needs to be a limiter Y% of the time where Y equals the portion of the total cost of the system X is responsible for.

The principle is the easiest to apply in a "calculus of variations" manner: if doubling the key performance metric of X results in an increase of the cost of the entire system as a whole by 5%, but how often X is the limiter drops from 10% of the time to 5% of the time, doing the doubling would bring the design quite close to proper balance wrt. X.

Things that are cheap to beef up are relatively rare a limiter in well-designed systems as a result. Things that are expensive to beef up are often the limiter. What is and isn't expensive to do depends heavily on where in the design space the current design is at and where the technology is at, all of which is changing over time.

FP32 was cheap to double up in Ampere, so they doubled it up, even though that provided only relativelyl small performance improvement. But now as a result, FP32 is very rarely a limiter (in Ampere and Ada). That doesn't automatically mean that these designs are "gimped" in DRAM bandwidth or anything of the kind. Rather, the whole perception that a good GPU design just gotta be ALU limited all the time is nothing but a mistaken perception, just like "it's either ALU limited or DRAM bandwidth limited by definition" also is just untrue. See "occupancy limited" for a prime example.

Other monitors work without flicker in Intel Macs, and suddenly M1 Macs have flicker issue...

Solution: "Buy Apple Display"

In kernel space you as the hardware manufacturer implement a display miniport driver, and heavily lean on dxgkrnl.sys

https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

And implement interfaces like this one for D3D12 https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

There's quite a bit though and it's kind of spread across several sections on MSDN.

> ...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 at the microarchitectural level? Are they out-of-order? Do they do register renaming?

>Also many developers support even more than 2, as you are fogetting Playstation and Switch, both of which with their own APIs, 2 for Playstayon (GNM and GNMX), 3 for Switch (NVN, Vulkan and OpenGL).

I didn't imply that developers only support 2.

As in facts from certified market analysis company, showing actual number of players per platform.