bnieuwen

As the sibling said those numbers are very configurable. e.g. around the x86 handhelds there are tinkerers running their U/P class chips at anywhere from 5W configured to 30+W configured (and with the appropriate cooling could totally go to 60W+ if configured to do so. Silicon-wise there is very little difference between AMD's U and H class chips, mainly just stuff like binning and some configuration in the firmware). Typical reasons to configure this would e.g. be cooling or battery restrictions from the OEM.

Furthermore note there is a difference between SoC package power and power pulled from the wall. That depends on the rest of the device, but 5-10W isn't unreasonable. (So e.g. at 22W package power, pulling ~32W from battery is pretty common). Looking at the detailed graph in the NUC review, that difference is particularly large though, the package only pulls <20W in steady state and maybe 30W at boost[0], but this device somehow seems to have significant power draw coming from somewhere else, this is pretty atypical wrt laptops & battery draw at least.

I'm not sure what performance per clock advantage going from desktop to mobile you're referring to? The mobile chips are slower due to the lower max boost and power limits, but due to non-linear power scaling it tends to be not that* much worse than the desktop parts.

As an aside I find the Anandtech Zen3 review[1] a pretty good resource when I want to have a clue about reasonable clock/power expectations on zen3 (though it is only a single workload)

(Also not sure where the 52W claim comes from, my searching on the linked page seems to yield no results?)

*: With the notable exception that pre-6000 series AMD had some horrible delay clocking up the cores when on battery, hitting short tests like geekbench. That said even on AC the chips should be adhering to configured power limits.

[0] https://images.anandtech.com/doci/16236/wm-aida_power.png [1] https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-di...

Actually Phoronix has power benchmarks for the ACPI power profiles[1]. Seems like a boost to ~28W or so with a long term average of 22-23W.

(Note that this is SoC package power instead of the full laptop though, but that is pretty typical, so no idea what the 22W was for comparison.)

[1] https://www.phoronix.com/review/ryzen7-6850u-acpi

Are we sure this is actually 4 cores and not a reporting error? AFAICT with some surface Googling Apple doesn't sell the M2 with cores disabled does it? Also 4 cores 8 threads is suspicious given that AFAIU the M2 doesn't have SMT. So you'd have 4 big and 4 little cores for 8 total. (at which point I think that part is fair. This is a chip to chip, not an uarch to uarch comparison)

So there are two parts to this: the app producing the image in the application window and then the windowing system combining multiple windows together to form the final image you see on screen.

The former gets done in process (using e.g. GL/vulkan) and then that final image gets passed onto the windowing system which is a separate process and could run outside the container.

As an aside, with accelerated graphics you mostly pass a file descriptor to the GPU memory containing the image, rather than mucking around with traditional shared memory.

The problem with containers and graphics drivers is that those drivers have an userspace component. This depends on the hardware (e.g. AMD vs. Intel vs. NVidia all have different drivers of course) and in the case of NVidia this has to be exactly matched with the kernel version (this is less of an issue with VMs, but then you need something like SR-IOV which isn't quite on consumer HW, or do dedicated PCIE throughput which doesn't allow the host to use it).

So version management becomes a major pita, from shipping drivers too old to support the hardware to having a driver that doesn't match the kernel. In the cloud this is mostly solved by using VMs and hardware with SR-IOV. (and a fixed HW vendor so you know which set of drivers to include)

A random attempt:

Typically the application wants to draw stuff on the GPU. To do this it calls into the GPU driver, which builds a big memory buffer in some implementation-defined format that instructs the GPU what to do, and then the driver instructs the GPU to execute that.

However, applications these days want to do some of the work to determine which commands to do on the GPU (e.g. culling).

So the work here is to allow the application to create a memory buffer on the GPU with commands using a standardized format and then the driver has to convert that into the implementation-defined format on the GPU. This copies a lot of the complexity of the driver from the CPU to something running on the GPU.

There have been exploits and there will probably be more in the future, see e.g. https://googleprojectzero.blogspot.com/2020/09/attacking-qua...

I think the keyword might be an 8k executable, not 8k of code. If I compile the example with clang on my box (linux x86_64) I get a 17K executable, for which the .text section (containing pretty much the runnable code)is 0x291 (661) bytes with the debug build and 0x255 (597) bytes with -O3.

If I dig into the .text segment of the optimized executable, only 235 bytes belong to the main function (others are stuff like __libc_csu_init and register_tm_clones). Looking at the assembly the loop would be about 123 bytes.

So lots of overhead, but I wouldn't say it is in the nested loop.