On 2023-03-06 21:58, Ville Syrjälä wrote:
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.
This test doesn't make sense. DirtyFB should simply not return before
execbuffer finishes.
~Maarten
