On 2023-03-09 12:04, Hogander, Jouni wrote:
On Mon, 2023-03-06 at 22:58 +0200, 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.
CRC calculation doesn't work with PSR currently. PSR is disabled if CRC
capture is requested.
Are we supposed to support frontbuffer rendering using GPU?
No other driver does that. It's fine if DirtyFB hangs instead until the
job it waits on completes.
~Maarten
