On 06/10/2026 18:35, Adrián Larumbe wrote: > On 2026-10-05 17:05:14+01:00, Steven Price wrote: >> On 05/10/2026 16:37, Boris Brezillon wrote: >> >>> On Mon, 5 Oct 2026 16:06:02 +0100 >>> Steven Price <[email protected]> wrote: >>> >>> >>> Hm, I'd say it's actually impossible because every unmap operation is >>> followed by a flush+inval of the GPU L2 and LSC, so for this stale >>> clean line to exist on the GPU side when a physical page is GPU-mapped >>> again, it would take a bug in the unmap logic or in the MMU HW, I >>> think. Am I missing something? >> >> Ah, yes that's true :) Although there's no need for us to do an >> invalidate on the unmap path... > > Does that mean the panfrost_mmu_flush_range() we do at the end of > panfrost_mmu_unmap() > is unnecessary? Is it because, as you said in a previous message, cache lines > for > BOs referenced in a CS are always invalidates before anything else is > executed?
Sorry, I wasn't very clear on the wording here - we don't need an *invalidate* but we do need a *clean*. Midgard/Bifrost hardware doesn't really give us much control over cache operations - we tend to just clean everything and blow away the cache (because the GPU's caches are "small" it's not worth the complexity). > If we keep the invalidate at the end of the mmu path, then there would be no > need > to mention that all counters being enabled is the ultimate reason why no > initial > flush/invalidate is needed in the perfcnt enable path. Yes I think relying on all counters being enabled is a bad design. We can justify the change based on the existing flushes/invalidates we're doing. >>>> >>> >>> I suppose speculation pre-populating the caches with stale data would be >>> covered by the flush+inval we do after a map operation (this is >>> currently done in the unlock path regardless of the VM op, so both map >>> and unmap get it). I don't know, maybe the goal is to relax the flushing >>> policy around VM modifications in the future, but if things stay as >>> they are now, we can assume that a fresh BO being GPU-mapped guarantees >>> that no cacheline points to it until the first GPU access. But maybe >>> I'm missing something else... >> >> I have to admit I'm coming from experience on CPUs - there speculation >> means a CPU can load a cache line at basically any point. So the >> argument that a line cannot be in a cache almost never holds. GPUs (at >> least Mali GPUs) haven't quite got to the stage of CPUs. >> >> Thanks, >> Steve > >
