Open Bug 1294771 Opened 8 years ago Updated 2 years ago

Investigate Intel blocklist versions

Categories

(Core :: Graphics, task, P3)

Unspecified
Windows
task

Tracking

()

Tracking Status
platform-rel --- -
firefox51 --- affected

People

(Reporter: milan, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [gfx-noted][platform-rel-Intel])

We usually blocklist based on the full version of the driver; for the case of Intel, that version is OS specific, and we may end up blocking too much. See bug 1293028 for one example of this. We need to look at all the Intel blocklist entries we have in the code and decide if they should be converted to the "build id" version, like in bug 1293028.
Peter, it would be really good if Ethan can find time to look at this, as he seems to understand the underlying issues.
Flags: needinfo?(howareyou322)
Keywords: feature
Whiteboard: [gfx-noted]
Blocks: 1294721
(In reply to Milan Sreckovic [:milan] from comment #0) > We usually blocklist based on the full version of the driver; for the case > of Intel, that version is OS specific, and we may end up blocking too much. > See bug 1293028 for one example of this. > > We need to look at all the Intel blocklist entries we have in the code and > decide if they should be converted to the "build id" version, like in bug > 1293028. Right, it's worth to investigate the Intel blocklist entries to see if some of them should use build id instead of whole version, it might be hard to judge for some since we use those entries for a while. I'll try.
Assignee: nobody → ethlin
Flags: needinfo?(howareyou322)
After reviewing current Intel blocklist, I divided the blocklist entries to the following categories: 1. Blocking certain driver version for all windows This is the most dangerous way. We may block too much. Or totally no use for some windows platforms. 2. Blocking certain driver version for certain windows version Basically it's correct and most of our blocklist entries are this type. But considering there is another format of Intel driver, which is 15.x.x.[build id]. We still have chance to block wrong. 3. Blocking all Intel driver for certain/all windows There should be no problem for this type.
(In reply to Ethan Lin[:ethlin] from comment #3) > After reviewing current Intel blocklist, I divided the blocklist entries to > the following categories: > 1. Blocking certain driver version for all windows > This is the most dangerous way. We may block too much. Or totally no use > for some windows platforms. > > 2. Blocking certain driver version for certain windows version > Basically it's correct and most of our blocklist entries are this type. > But considering there is another format of Intel driver, which is > 15.x.x.[build id]. We still have chance to block wrong. > > 3. Blocking all Intel driver for certain/all windows > There should be no problem for this type. I think the first type has higher priority. There is only one entry[1] belongs to the first type. I'll open a bug and fix it by using build id to do the check. For the second type, we can fix them progressively. I'll file bug for each entry or each group. Try to convert them to build id method and do some test to make sure it works well. Milan, what do you think? [1] https://dxr.mozilla.org/mozilla-central/source/widget/windows/GfxInfo.cpp#1057
Flags: needinfo?(milan)
Thanks for looking at this! We have more places where we do #1 (e.g., https://dxr.mozilla.org/mozilla-central/source/browser/app/blocklist.xml#3587). I'm less worried about blocking too much, than blocking too little, so we would want to investigate each of #1 in turn and make sure we understand what we were trying to block. Probably replace all #1 until we just have #2 types. And, agreed, we investigate #2 one by one. There is the equivalent thing for Nvidia (bug 638936) and AMD (I imagine?)
Flags: needinfo?(milan)
Depends on: 1295899
Depends on: 1295902
Depends on: 1299757
platform-rel: --- → ?
Whiteboard: [gfx-noted] → [gfx-noted][platform-rel-Intel]
platform-rel: ? → -
Priority: -- → P3
Type: defect → task

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: demo99 → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.