dma-buf feedback: who should decide when to re-allocate?
Recently @rmader started some discussions regarding the dma-buf feedback spec:
I'm writing this to try to summarize the problem and so that we can centralize the discussion.
At the moment, there are two approaches being used on main compositors that implement dma-buf feedback. Please correct me if I'm wrong, but this is what I think we have now:
KWin and Weston
-
Assumes that dma-buf feedback should be sent only if the client is using buffers that were allocated with sub-optimal parameters. In such case, the assumption is that when clients receive feedback they should pick parameters from it and re-allocate their buffers.
-
This implies that the compositor should know if re-allocation is going to benefit the client or not.
-
If a client's surface is already eligible for direct scanout, the compositor won't modify the feedback to add a scanout tranche. A scanout tranche is added only if the client's surface is not eligible for direct scanout because of its fb format/modifier.
Mutter and Sway
-
Assumes it should send the feedback whenever the optimal parameters for allocation change, and the client may benefit from reallocation based on these newest parameters. But it is responsibility of the client to decide if re-allocation should happen or not.
-
It is a more transparent approach. If compositor is able to direct scanout from the surface (independently of its current fb format/modifier), the scanout tranches are added. If the compositor is not able to direct scanout from the surface, them scanout tranches are removed.
Sentences from spec
The sentences from the spec that are slightly in conflict and can allow these two interpretations (as pointed out by @rmader here)
The parameters are sent once when this object is created and whenever they change.
Compositors should not re-send the parameters if re-allocating the buffers would not result in a more optimal configuration.
What is the correct interpretation?
Before deciding to rephrase things in the spec, we should decide what is the correct interpretation. At the moment I believe that Mutter and Sway are doing the right thing. As pointed out by @jadahl here, the client should know better when reallocation is necessary or not.
For some reason the client may want to stick to the format/modifier that it is already using, even if that makes it not eligible for scanout. Then it should not react when it receives feedback from the compositor.
Or it may want to change to another format/modifier from another scanout tranche for some reason, even when it is already using a format/modifier pair that makes it eligible for scanout. But if the compositor hides the scanout tranches, that won't happen.
The only downside of the approach that Mutter and Sway use is that clients have to implement the logic to trigger re-allocation and avoid unnecessarily doing so. A possible solution: keep track of the parameters that they've used to allocate buffers the latest time, and compare with whatever they choose to use from the newest feedback. I don't know how hard this would be for some clients, but it still seems that this is the best direction to go.
Let me know what you think. Thanks!