<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#c20">Comment # 20</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#c19">comment #19</a>) > > We are using kernel 4.0.3 > > Strange, that kernel should work perfectly fine. I suspect the problem of that Tahiti user might not be directly related to the patch. Or maybe he's experiencing the problematic aspects of unmapping the VA range for all GEM handles... (In reply to Christian König from <a href="show_bug.cgi?id=90537#c18">comment #18</a>) > I'm working on that problem for years now, tracking VA ranges per GEM handle > isn't really doable either (e.g. without breaking backward compatibility). How would it break backwards compatibility? 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. Anyway, if you think the Mesa patch is the best we can do for now, there would at least need to be a way for userspace to know it's safe to unmap the VA range, e.g. an info query.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>