<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Am 26.02.24 um 17:27 schrieb Michel Dänzer: <blockquote type="cite" cite="mid:298c5ccd-d39c-4036-8ad6-624f635bc08c@daenzer.net"> <pre class="moz-quote-pre" wrap="">On 2024-02-26 16:58, Christian König wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Am 23.02.24 um 17:43 schrieb Michel Dänzer: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">On 2024-02-23 11:04, Michel Dänzer wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">On 2024-02-23 10:34, Christian König wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Am 23.02.24 um 09:11 schrieb Michel Dänzer: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">On 2024-02-23 08:06, Christian König wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Am 22.02.24 um 18:28 schrieb Michel Dänzer: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">From: Michel Dänzer <a class="moz-txt-link-rfc2396E" href="mailto:mdaenzer@redhat.com"><mdaenzer@redhat.com></a> Pinning the BO storage to VRAM for scanout would make it inaccessible to non-P2P dma-buf importers. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">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, </pre> </blockquote> <pre class="moz-quote-pre" wrap="">Those use cases don't have P2P & CONFIG_DMABUF_MOVE_NOTIFY? </pre> </blockquote> <pre class="moz-quote-pre" wrap="">Nope, we are basically talking about unit tests and examples for inter device operations. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">Sounds like the "no user-space regressions" rule might not apply then. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> The problem with the status quo is that it requires amdgpu-specific knowledge and worst-case pessimization in user space.</pre> </blockquote> Yeah, I'm perfectly aware of that. But that approach here really doesn't seems to be valid. <blockquote type="cite" cite="mid:298c5ccd-d39c-4036-8ad6-624f635bc08c@daenzer.net"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">We have use cases which depend on this behavior and I'm not going to break those to fix your use case. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> It's not "my" use case, it's a Wayland compositor trying to make use of BO sharing and scanout without always pessimizing for the worst case. That's surely more of a real-world use case than unit tests and examples. </pre> </blockquote> I've looked a bit deeper into this and we have told customers for the last ~10 years or so that this is how it is supposed to work and that they can use this approach. So this is much more than unit tests and examples, we are changing existing behavior which is clearly not a bug but intentional and have a very high chance to break valid use cases. My question is why has it worked so far? I mean we are not doing this since yesterday and the problem only shows up now? While I see the use case something is still missing in that picture. Christian. </body> </html>