From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL) Date: Tue, 26 May 2015 09:30:54 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0375817432==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 5CF886E61F for ; Tue, 26 May 2015 02:30:54 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0375817432== Content-Type: multipart/alternative; boundary="1432632654.043dc610.24781"; charset="UTF-8" --1432632654.043dc610.24781 Date: Tue, 26 May 2015 09:30:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://bugs.freedesktop.org/show_bug.cgi?id=3D90537 --- Comment #20 from Michel D=C3=A4nzer --- (In reply to Christian K=C3=B6nig from comment #19) > > We are using kernel 4.0.3 >=20 > 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=C3=B6nig from comment #18) > I'm working on that problem for years now, tracking VA ranges per GEM han= dle > isn't really doable either (e.g. without breaking backward compatibility). How would it break backwards compatibility? I'm not sure how not tracking t= he VA ranges per GEM handle could ever work as expected with several GEM handl= es referencing the same BO. Anyway, if you think the Mesa patch is the best we can do for now, there wo= uld at least need to be a way for userspace to know it's safe to unmap the VA range, e.g. an info query. --=20 You are receiving this mail because: You are the assignee for the bug. --1432632654.043dc610.24781 Date: Tue, 26 May 2015 09:30:54 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Commen= t # 20 on bug 90537<= /a> from Michel D=C3=A4nzer 
(In reply to Christian K=C3=B6nig from comment #19)
> > We are using kernel 4.0.3
>=20
> 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=C3=B6nig from comment #18)
> I'm working on that problem for years now, track=
ing VA ranges per GEM handle
> isn't really doable either (e.g. without breaking backward compatibili=
ty).

How would it break backwards compatibility? I'm not sure how not tracking t=
he
VA ranges per GEM handle could ever work as expected with several GEM handl=
es
referencing the same BO.

Anyway, if you think the Mesa patch is the best we can do for now, there wo=
uld
at least need to be a way for userspace to know it's safe to unmap the VA
range, e.g. an info query.

You are receiving this mail because: =20=20=20=20=20=20
  • You are the assignee for the bug.
--1432632654.043dc610.24781-- --===============0375817432== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0375817432==--