On Wed, 2 Sep 2026 16:43:34 +0100 Adrián Larumbe <[email protected]> wrote:
> On 01.09.2026 15:32, Boris Brezillon wrote: > > On Fri, 28 Aug 2026 21:56:53 +0100 > > Adrián Larumbe <[email protected]> wrote: > > > > > The GPU cache flush/invalidate operation is unnecessary, because at > > > present > > > all counters are always enabled for all sessions, and there are no plans > > > to > > > expand the uAPI so as to let UM select specific counter groups. > > > > > > If the above was ever implemented, then different counter groups being > > > selected between sessions might leave stale data in the GPU caches, so > > > the flush/invalidate would have to be reintroduced. > > > > This explanation confuses me. To me, the reason we don't need a > > cache-flush has nothing to do with the fact we always enable all > > counters, it's just that, either the perfcnt buffer has been freshly > > allocated/mapped and the cache has no entry pointing to it, or it's > > been written already, and the flush should have happened after the > > dump. For the case where the enable happens after a RESET (which you > > introduce in one of the remaining commits, I guess), there's no flush > > needed either, because the RESET clears all the caches. > > This is something I wrote after a chat with Steven about whether removing > this flush/invalidate was fine. > If memory serves me right, he expressed his concern that flushing GPU caches > after a sample might write > disabled counter data into system memory, but in that case UM should know > better, and I guess reading off > disabled counter data is seen as undefined behaviour in the TRM. That's still 'after a SAMPLE' though. I see no reason why one would want to flush things at enable time. To me, the ENABLE step is just about resetting the internal counters and activating the counting. Those values are not written directly to memory, the SAMPLE operation is what transfer those internal counters to the piece of memory you've provided, and that's when you want the FLUSH to happen, I think.
