Am 23.02.24 um 17:43 schrieb Michel Dänzer:
On 2024-02-23 11:04, Michel Dänzer wrote:
On 2024-02-23 10:34, Christian König wrote:
Am 23.02.24 um 09:11 schrieb Michel Dänzer:
On 2024-02-23 08:06, Christian König wrote:
Am 22.02.24 um 18:28 schrieb Michel Dänzer:
From: Michel Dänzer <mdaen...@redhat.com>
Pinning the BO storage to VRAM for scanout would make it inaccessible
to non-P2P dma-buf importers.
Thinking more about it I don't think we can do this.
Using the BO in a ping/pong fashion for scanout and DMA-buf is actually valid,
you just can't do both at the same time.
And if I'm not completely mistaken we actually have use cases for this at the
moment,
Those use cases don't have P2P & CONFIG_DMABUF_MOVE_NOTIFY?
Nope, we are basically talking about unit tests and examples for inter device
operations.
Sounds like the "no user-space regressions" rule might not apply then.
To clarify what I mean by that:
"We can't fix this issue, because it would break some unit tests and examples" is similar
to saying "We can't fix this KMS bug, because there are IGT tests expecting the buggy
behaviour". In practice, the latter do get fixed, along with the IGT tests.
The problem here is that this is not a bug, but intentional behavior.
Exporting BOs and using them in scanout in a ping/pong fashion is
perfectly valid.
We have use cases which depend on this behavior and I'm not going to
break those to fix your use case.
So as far as I can see this approach here is a no-go.
Regards,
Christian.
