<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)" href="https://bugs.freedesktop.org/show_bug.cgi?id=90537#c24">Comment # 24</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)" href="https://bugs.freedesktop.org/show_bug.cgi?id=90537">bug 90537</a> from <a class="email" href="mailto:michel@daenzer.net" title="Michel Dänzer <michel@daenzer.net>"> Michel Dänzer</a> <pre>(In reply to Christian König from <a href="show_bug.cgi?id=90537#c23">comment #23</a>) > > How would it break backwards compatibility? > > You would need to allow multiple mappings into the same address space per BO. > > Which is exactly what I've did for amdgpu, but IIRC that would break the > userspace interface because you won't return the mapped address any more > when you try to map it multiple times.... What would that break? It could result in the same BO having several representations in userspace, but (why) is that a problem? > > I'm not sure how not tracking the VA ranges per GEM handle could ever work > > as expected with several GEM handles referencing the same BO. > > Actually it can indeed never work correctly. What we just do all the time is > trying to avoid the case that several GEM handles reference the same BO very > hard. I'm afraid we can't always avoid that though, e.g. when sharing BOs between glamor and the Xorg driver.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>