<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#c23">Comment # 23</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:deathsimple@vodafone.de" title="Christian König <deathsimple@vodafone.de>"> Christian König</a> <pre>(In reply to Michel Dänzer from <a href="show_bug.cgi?id=90537#c20">comment #20</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.... > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>