5 ms·
// Copy the Entire Framebuffer to itself, // to fix the missing pixels. // Not sure why this works. That has big lack of proper cache flushing energy. A
by monocasa 4y ago
// Copy the Entire Framebuffer to itself,
// to fix the missing pixels.
// Not sure why this works.
That has big lack of proper cache flushing energy. ARM-A device support tends to be where you need to get really intentional about managing your memory hierarchy. Smaller cores tend to have simple enough (or no) caches that they don't tend to get in your way much except for knife edge bugs. Bigger systems like x86 just tend to push the cache coherency out even to IO devices. ARM-A class SoCs are that sweet spot of a ton of caches between the CPU and main memory, but simple enough peripherals and fabric that only the CPU cores are coherent.
- pixelfarmer 4y agoExactly. The artifacts shown are stereotypical caching issues: Always same length (cache line size) and earlier written entries are more likely to be fully committed than later written ones but it is (seemingly) random in overall.
- jancsika 4y agoSo is copying the thing to itself the only solution in the interim in order to force the thing to copy itself correctly into the thing?
- Veserv 4y agoYou manually flush the addresses of the framebuffer via a cache maintenance instruction. The internet tells me the phone has a A53 which should be ARMv8, so probably a loop of DC CIVAC (Data Cache Clean and Invalidate by Virtual Address to Coherency) instructions over the framebuffer. Though the buffer might be large enough to not even fit in the cache, so it might be more efficient to just flush the entire cache.
- aidenn0 4y agoOr just map the FB as WT.
- ajross 4y agoNo, ARM has cache management hardware (and a memory ordering model which you need to understand on the OOO cores). You just have to use it.
- monocasa 4y agoNot only is copying it over itself not the only solution (all you need to do is issue the right sequence of cache flushes over the affected area, so first CPU cache flush instructions, and then maybe an additional set of MMIO based cache flushes depending on how your L2 and/or L3 work), but copying over itself isn't even enough to be correct. They lucked out that it seems to work, but it's kind of by chance. That cache is more than in the right to still not flush some lines even with this big copy.
- jbirer 4y agoYep, and I am not comfortable using software developed by people who don't know about this. Almost the entire ARMv8 TRM constantly mentions cache considerations.
- fexecve 4y agoWell, I am. Hacky workarounds like this might be ugly and slow, but modern chips are really fast, and I don't expect an RTOS graphics display to be the fastest thing in the world.
- numpad0 4y agoCoherency bugs crash systems which trigger a reboot if device is engineered right. If anything the correct way of it is marginally slower.
- pixelfarmer 4y agoLet me tell you one thing: Even modern chips are not fast enough to pull stupid stunts like that. This is topped off with a horrible routine which manually copies the whole thing bytewise (= 1/4th of a pixel per loop). Using SIMD (I think it is called ASIMD or something) you can transfer like 16 pixels in 32bpp per loop, just to give you an idea (i.e. 64x the amount of data). Or to say it differently: 1440x720x32bpp is about 4MiB of memory which needs to be read and then written again, per frame. With 60FPS that is 8MiB*60FPS = 480MiB/s of data you shovel around for no reason. Add that loop overhead from this 1/4th of a pixel per loop routine and your awesome fast modern chip is being kept busy with garbage, eating your battery while doing so. Now you want to avoid updating the whole screen all the time, but there is obviously a more fundamental issue and this should be fixed properly instead of keeping the CPU busy with nonsense. Also keep in mind that this also may lock or delay other data transfers in the system, depending on the system + bus arbitration settings etc.
- fexecve 4y agoThat's true, battery consumption is an issue.
- pengaru 4y agoEven my x86 ThinkPad has had iGPU driver bugs surrounding LLC flushing with linux kernel updates over the years. They'd manifest with cache-line sized graphics noise/artifacts particularly when showing fullscreen animations.
- monocasa 4y agoThat one I have under good authority is a hardware bug. PCI devices are supposed to be cache coherent, but Intel got a little too cute when integrating their iGPU into the uncore (and northbridge before it) at a level that looks like PCI to software but is their internal interconnects in actuality.