From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 80419] XCOM: Enemy Unknown Causes lockup
Date: Fri, 05 Feb 2016 14:43:23 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1463477452=="
Return-path:
Received: from culpepper.freedesktop.org (unknown [131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id D2CA06EA0B
for ; Fri, 5 Feb 2016 06:43:23 -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
--===============1463477452==
Content-Type: multipart/alternative; boundary="14546834036.4EbB50C9.16502";
charset="UTF-8"
--14546834036.4EbB50C9.16502
Date: Fri, 5 Feb 2016 14:43:23 +0000
MIME-Version: 1.0
Content-Type: text/plain
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #113 from Nicolai Hähnle ---
Perhaps it does, and that would be bad, but the particular apitrace crash was
basically the following:
1) XCOM uses DrawRangeElements with an unnecessarily large range.
2) During tracing, apitrace scans the index/elements array to determine the
range of vertices that is really being used.
3) Apitrace only stores this range of vertices.
4) During playback, apitrace would send the same range via DrawRangeElements,
but provide vertex data only for the range that was determined to be really
used.
5) The driver, on the other hand, relies on the entire range to be there and
tries to upload it to the card. This is where the crash happened (and it also
explains what I said before about XCOM being slightly inefficient here)
--
You are receiving this mail because:
You are the assignee for the bug.
--14546834036.4EbB50C9.16502
Date: Fri, 5 Feb 2016 14:43:23 +0000
MIME-Version: 1.0
Content-Type: text/html
Comment # 113
on bug 80419
from Nicolai Hähnle
Perhaps it does, and that would be bad, but the particular apitrace crash was
basically the following:
1) XCOM uses DrawRangeElements with an unnecessarily large range.
2) During tracing, apitrace scans the index/elements array to determine the
range of vertices that is really being used.
3) Apitrace only stores this range of vertices.
4) During playback, apitrace would send the same range via DrawRangeElements,
but provide vertex data only for the range that was determined to be really
used.
5) The driver, on the other hand, relies on the entire range to be there and
tries to upload it to the card. This is where the crash happened (and it also
explains what I said before about XCOM being slightly inefficient here)
You are receiving this mail because:
- You are the assignee for the bug.
--14546834036.4EbB50C9.16502--
--===============1463477452==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0
cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK
--===============1463477452==--