On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst wrote: > Hey, > > On 2023-03-06 16:23, Souza, Jose wrote: > > On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote: > >> As a fallback if we decide not to merge the frontbuffer tracking, allow > >> i915 to keep its own implementation, and do the right thing in Xe. > >> > >> The frontbuffer tracking for Xe is still done per-fb, while i915 can > >> keep doing the weird intel_frontbuffer + i915_active thing without > >> blocking Xe. > > Please also disable PSR and FBC with this or at least add a way for users to disable those features. > > Without frontbuffer tracker those two features will break in some cases. > > FBC and PSR work completely as expected. I don't remove frontbuffer > tracking; I only remove the GEM parts. > > Explicit invalidation using pageflip or CPU rendering + DirtyFB continue > to work, as I validated on my laptop with FBC. Neither of which are relevant to the removal of the gem hooks. Like I already said ~10 times in the last meeting, we need a proper testcase. Here's a rough idea what it should do: prepare a batch with 1. spinner 2. something that clobbers the fb Then 1. grab reference crc 2. execbuffer 3. dirtyfb 4. wait long enough for fbc to recompress 5. terminate spinner 6. gem_sync 7. grab crc and compare with reference No idea what the current status of PSR+CRC is, so not sure whether we can actually test PSR or not. -- Ville Syrjälä Intel
