From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 80419] XCOM: Enemy Unknown Causes lockup Date: Wed, 30 Dec 2015 22:44:14 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1422597170==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 4FA9E6E143 for ; Wed, 30 Dec 2015 14:44:14 -0800 (PST) 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 --===============1422597170== Content-Type: multipart/alternative; boundary="1451515454.Dd4b3.3722"; charset="UTF-8" --1451515454.Dd4b3.3722 Date: Wed, 30 Dec 2015 22:44:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #95 from Jose Fonseca --- (In reply to Roland Scheidegger from comment #94) > Created attachment 120734 [details] [review] > apitrace patch for honoring range in DrawRangeElementsX commands > > So you'd want something like this (totally untested) patch for apitrace? > Makes sense I guess that the specified range not only means the supplied > indices have to be inside that range, but it also works the other way round > (driver can rely on the specified range being accessible) - otherwise the > driver would still need to scan the actual index buffer. (Albeit since for > this app the ranges seem to be pretty bogus who knows if the memory inside > the specified range but not used in the actual indices is really always > accessible.) Yes, this does indeed make sense. For VBOs, the start/end range is a hint (the OpenGL shouldn't crash if the start/end range goes beyond the VBO size), but for user memory arrays, there's no reliable way to know where user memory is supposed to stop -- the start/end range is it. > I am actually wondering if it would be legal if the memory isn't accessible > below the start value (apitrace surely couldn't handle that)... I don't think it's worth worrying about that. -- You are receiving this mail because: You are the assignee for the bug. --1451515454.Dd4b3.3722 Date: Wed, 30 Dec 2015 22:44:14 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 95 on bug 80419 from
(In reply to Roland Scheidegger from comment #94)
> Created attachment 120734 [details] [review] [review]
> apitrace patch for honoring range in DrawRangeElementsX commands
> 
> So you'd want something like this (totally untested) patch for apitrace?
> Makes sense I guess that the specified range not only means the supplied
> indices have to be inside that range, but it also works the other way round
> (driver can rely on the specified range being accessible) - otherwise the
> driver would still need to scan the actual index buffer. (Albeit since for
> this app the ranges seem to be pretty bogus who knows if the memory inside
> the specified range but not used in the actual indices is really always
> accessible.)

Yes, this does indeed make sense.

For VBOs, the start/end range is a hint (the OpenGL shouldn't crash if the
start/end range goes beyond the VBO size), but for user memory arrays, there's
no reliable way to know where user memory is supposed to stop -- the start/end
range is it.

> I am actually wondering if it would be legal if the memory isn't accessible
> below the start value (apitrace surely couldn't handle that)...

I don't think it's worth worrying about that.


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