Closed Bug 1259536 Opened 4 years ago Closed 3 years ago

[Meta] Get telemetry for *why* WebGL fails when it does

Categories

(Core :: Canvas: WebGL, defect)

Unspecified
All
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
firefox48 --- affected

People

(Reporter: milan, Unassigned)

References

(Depends on 1 open bug, Blocks 3 open bugs)

Details

(Keywords: meta, Whiteboard: [gfx-noted])

It would help to understand if it's our blocklisting or some other reason WebGL context creation may fail.
Assignee: nobody → jmuizelaar
Assignee: jmuizelaar → bgirard
I'm exploring the data we have in 'toolkit/components/telemetry/docs/environment.rst' and seeing how we can query this data:
toolkit/components/telemetry/docs/environment.rst

Looks like we already collect quite a bit of this data through the gfx.features.* fields.
I think it make sense to use the SQL queries.

I had a look and the longitudinal table only exposes a subset of the graphics telemetry ping data. I also believe that we will want to perhaps add a few fields to the telemetry ping while we're at it to make sure we can answer all the queries we want.

:rvitillo once I add the missing fields are there any reason why we can't include all the graphics field in the longitudinal table? Or at least one of the table?
Flags: needinfo?(rvitillo)
(In reply to Benoit Girard (:BenWa) from comment #3)
> :rvitillo once I add the missing fields are there any reason why we can't
> include all the graphics field in the longitudinal table? Or at least one of
> the table?

It would be great if once you add new fields you could also update the gfx schema in [1], which is currently incomplete. The schema will be used for validation and for development of derived datasets. 

Once the changes have landed, you should file a Bug to add the new fields to the longitudinal dataset and put me in CC. 

[1] https://github.com/mozilla-services/mozilla-pipeline-schemas/blob/master/telemetry/main.schema.json#L371
Flags: needinfo?(rvitillo)
Alright I did a bit more digging today.

I'm now convinced the sql/redash is (almost[0]) exactly what we need. From what I was told:
* It's faster to query than spark (if I understood correctly)
* It supports pivot table which is exactly what we need to break down say 'webgl failure causes' into obvious populations.
* If the field you need isn't available in the pivot table you can add it to the query and re-generate it.
* It's easy to edit/fork a query/dashboard. This way we can break things down further if we need them.

We're still missing important failure causes for WebGL in telemetry. Going to file a bug to get better WebGL feature status into the telemetry ping which will depend on bug 1254899.

[0] Something like crash-stats super search is the main thing that missing IMO. Basically just saves you from having to hand edit SQL yourself.
Depends on: 1262008
Summary: Get telemetry for *why* WebGL fails when it does → [Meta] Get telemetry for *why* WebGL fails when it does
Depends on: 1262011
Depends on: 1263249
Depends on: 1266846
Duplicate of this bug: 1248462
Depends on: 1271133
Depends on: 1272808
Depends on: 1276732
Depends on: 1272819
Depends on: 1272821
Depends on: 1274046
Blocks: 1274012
Blocks: 1275987
Depends on: 1278302
Assignee: bgirard → nobody
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Whiteboard: [gfx-noted]
You need to log in before you can comment on or make changes to this bug.