pocak

In the post about the texture unit, that ROM table for mip level address offsets seems to use quite a bit of space. Have you considered making the mip base addresses a part of the texture spec instead?

Right, I had the article's bunny test program on my mind, which looks like it has only one pass.

In OpenGL, the driver would have to scan the following commands to see if it can discard the depth data. If it doesn't see the depth buffer get cleared, it has to be conservative and save the data. I assume mobile GPU drivers in general do make the effort to do this optimization, as the bandwidth savings are significant.

In Vulkan, the application explicitly specifies which attachment (i.e. stencil, depth, color buffer) must be persisted at the end of a render pass, and which need not. So that maps nicely to the "final render flush program".

The quote is about Metal, though, which I'm not familiar with, but a sibling comment points out it's similar to Vulkan in this aspect.

So that leaves me wondering: did Rosenzweig happen to only try Metal apps that always use MTLStoreAction.store in passes that overflow the TVB, or is the Metal driver skipping a useful optimization, or neither? E.g. because the hardware has another control for this?

I don't understand why the programs are the same. The partial render store program has to write out both the color and the depth buffer, while the final render store should only write out color and throw away depth.

In the article, cost is cpu time, and benefit is file size reduction multiplied by number of times watched.

Linux allocates page tables lazily, and fills them lazily. The only upfront work is to mark the virtual address range as valid and associated with the file. I'd expect mapping giant files to be fast enough to not need windowing.

Only one row at a time has voltage applied to it. In one update, the image is scanned out multiple times, so it appears as if all pixels were changing simultaneously (and perhaps they do, if the electrodes have significant capacitance.)

With fewer rows to update, each row gets a push more often, flipping the grains faster.

Took me a while to get past the home screen. I kept clicking 'paint' at the bottom and 'no' at the top.

Thread migration only costs on the order of 100 microseconds, including the effect of cold caches. If you keep the AVX thread on the big core for at least 100 milliseconds at a time, you only lose ~0.2% performance.

It works by applying a low-pass filter on the camera's motion, so a sudden kick turns into a slow, low amplitude bob.

Perhaps you just need to increase the smoothing parameter. I found the default of 10 way too low, and needed around 50-100 for my very shaky 50 fps home videos.

If you give two threads on one core to one VM, the VM could attack the hypervisor. It could have one thread run the TLB probe loop while the other does something that's handled by the hypervisor.

Are newer Ryzen 1000 series CPUs still made with the B1 die?

I thought steppings were for fixing errata, and once a new revision is qualified, the old one is no longer manufactured.