1184784 - Add additional hardware platform datapoints to FHR collection to support video game initiative

Status: RESOLVED INVALID

(Toolkit :: Telemetry, defect)

Description

[Andre Vrignaud [:andre] [Seattle - PST]]

Requested FHR Hardware Data Points

Note: Examples from Valve PC Hardware survey, but we are seeking equivalent data from PC and Mobile platforms whenever possible. 

CPU:
    Everything in system.cpu captured by Telemetry.
    CPU clock speed
    Number of physical cores and hyper-threads
Cache sizes (of L1, L2, L3), enough to distinguish Celerons from i7s

Memory:
    system.memoryMB from Telemetry.
    “Total Virtual Memory” as reported in crash reports.

GPU:
    Everything in system.gfx captured by Telemetry.
    Is WebGL enabled?  (Using the same query function we use to actually enable WebGL)
If OpenGL is supported:
    OpenGL Version (GL_VERSION): 4.5
    OpenGL Vendor (GL_VENDOR)
    OpenGL Renderer (GL_RENDERER)
    OpenGL Extensions (GL_EXTENSIONS)
On mobile:
    EGL Version
    EGL Extensions
    OpenGL ES 2 support (the OpenGL chunk above)
    OpenGL ES 3 support (will need to try eglCreateContext with EGL_CONTEXT_CLIENT_VERSION == 3, and if it works, pull out the GL info above from that context as well -- so we may end up with two sets of GL info for a given device, one for ES2 and one for ES3)
On desktop:
        PCI VendorID:  0x10de
        PCI DeviceID:  0x17c8

Operating System:
    Everything in system.os captured by Telemetry.
    Not clear, but want system.os.name to cover all OSes, not just Windows
    FF locale

Input:
Has attached mouse?
Has enabled touch input?  (As determined by touch API)
Has attached game controller?  (As determined by gamepad API)

Storage:
    Total drive size and free space on the drive containing the profile dir (appropriately quantized for anonymization). Need for mobile as well.

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

This is a good laundry list of "everything" - is there a priority/urgency for some of the items vs. the others?  For example, is the "physical cores vs. hyperthreads" as important as "graphics vendorID".  Perhaps a two buckets of "will use this data now" and "think we will be able to use this data" or an order?

Comment 2

[Andre Vrignaud [:andre] [Seattle - PST]]

Hi Milan,

Unfortunately we sort of need all of it to get a picture of what the hardware (both PC and mobile) our potential audience of web gamers has. Goal is to get to point where we can deliver our own web gamer version of Valve's Hardware survey (http://store.steampowered.com/hwsurvey)

Can say that the three "Input" items are less important, but will need them to tell the full picture. 

I've asked Luke and Vlad to chime in on whether any of the items remaining are of higher priority for them, if that helps you sort the work order.

Comment 3

[Luke Wagner [:luke]]

I suppose, on desktop, we can mostly assume mouse input so the "Input" subsection isn't necessary.  Everything else seems necessary to get a holistic picture of what type of games our user base can run.

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

The FHR specific work is a bit of a deadend as of 41 (going to Beta next week), I'd like to understand if we can avoid doing it.  As of 41, the opt-out pieces of telemetry will effectively replace FHR.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

One thing that we somehow didn't include in the original list:

Displays
- Number of displays
- Main display resolution
- Main display physical size (if we can get it)
- Resolution of display with the most pixels (if N > 1)
- Physical size of display with the most pixels (if N > 1)

(In reply to Milan Sreckovic [:milan] from comment #1)
> This is a good laundry list of "everything" - is there a priority/urgency
> for some of the items vs. the others?  For example, is the "physical cores
> vs. hyperthreads" as important as "graphics vendorID".  Perhaps a two
> buckets of "will use this data now" and "think we will be able to use this
> data" or an order?

The majority of this work is either relatively trivial to collect, or we already collect it in various places and it just needs to be centralized:

CPU - this is just a pile of cpuid instructions.  Various info for some of the more complex pieces (e.g. cache) at: https://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/, http://trac.wildfiregames.com/browser/ps/trunk/source/lib/sysdep/arch/x86_x64/topology.cpp, https://software.intel.com/en-us/forums/topic/287414, etc.

GPU - we already collect all of this, or have the means to do so; for example, we query GL_VENDOR, we just don't query and report GL_EXTENSIONS

Memory - I believe we already capture all of this.

Storage - I don't think we query this, but it should be trivial at least to get started

Displays - We actually have a lot of this in nsIScreen already; might be able to just get it all from nsIScreenManager.

Input - tricky to actually get it right; for example, I suspect Windows will report a mouse is available even if all you have is a touchscreen Surface tablet; likewise, I suspect it will report touch input is available even if all you have is just a tablet (like a Wacom) connected to the system.  So the utility here might be limited, but we can always refine this going forward.  But getting some basic values should be easy.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

The WebGL stuff would be intrusive, right?  I don't think we can get all that info without actually making a webgl canvas.

Comment 7

[Andre Vrignaud [:andre] [Seattle - PST]]

(In reply to Milan Sreckovic [:milan] from comment #4)
> The FHR specific work is a bit of a deadend as of 41 (going to Beta next
> week), I'd like to understand if we can avoid doing it.  As of 41, the
> opt-out pieces of telemetry will effectively replace FHR.


One question and one possible problem:

Question: will telemetry have all of the requested data collected on a regular, consistent opt-out basis as of 41? Key is to make sure we get all of the data such that we can regularly (monthly) publish a view of it, and track changes over time.

Problem: if the answer to above is yes, then the problem is likely timing. If you are saying that we would have to wait until November or so to use telemetry data from 41, that's too late. :( We need this data in September forward, to tell the platform story to publishers; truth be told, wish we had it now.

Comment 8

[Benjamin Smedberg]

Didn't we already cover this in the email thread? Some (most) of the data is already present in the base dataset of UT which is opt-out. 41 will ship on 22-Sep. You aren't going to get anything earlier than that, and any enhancements tracked in this bug will likely be either in 42 (3-Nov) or 43 (15-Dec).

Comment 9

[Andre Vrignaud [:andre] [Seattle - PST]]

Ok, chatted with Rebecca and understand better what's going on — apologies if I didn't fully grok it before. 

So, to answer Milan's question, no, I don't want to randomize folks to do throwaway FHR work. It sounds like the right path is to use UT going forward, and I will try to find some other (external) data sources to bridge the gap until hopefully FF 42/November.

The one thing we should get crisp on is what items from the list of data points we need are opt-out "today" (in 41/the base dataset of UT), and what, if any, remaining items might need to be added to that special opt-out list for 42+. Just want to make sure no data points fall on the ground and somehow become/stay opt-*in*, which could cause issues in our reporting.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

If you look at about:telemetry environment section, all of that stuff should be opt-out, and that's where most of the new things would go into, I imagine.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to avrignaud from comment #0)
> ...
> 
> Memory:
>     system.memoryMB from Telemetry.
>     “Total Virtual Memory” as reported in crash reports.
> 

We want virtual memory, meaning the result on Windows will most likely be 2/3/4GB when running 32-bit Firefox.  We don't care about the maximum page file size?

Comment 12

[Luke Wagner [:luke]]

(In reply to Milan Sreckovic [:milan] from comment #11)
I'm not aware of page file size being a limitation in practice for games since they try to stay in RAM to avoid the massive paging perf hits and since consoles don't have paging anyway.  I'd be interested to hear otherwise, though.

Comment 13

[Benjamin Smedberg]

For user that actually run out of memory in Firefox, one of the primary reasons is that they have a misconfigured page file (page file disabled or set to something ridiculously low).

But that may not be directly related to gaming questions.

Comment 14

[Luke Wagner [:luke]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #13)
Interesting; any indication what is the reason for the misconfigured page file?  I assume a very small % of users actually mess with that setting directly.

Comment 15

[Benjamin Smedberg]

No understanding of root cause, no.

Comment 16

[Luke Wagner [:luke]]

Well, throwing in page file size couldn't hurt.  I guess we could use it to discount machines with low system.memoryMB and low page file size since tiny memory spikes would OOM the browser.

Comment 17

[Milan Sreckovic [:milan] (needinfo for best results)]

Bug 1128472 brings family, model, stepping, cores, cache, cpu speed, virtual memory max, vendor. (Current wip patch is for Windows and Mac only, and misses virtual mem for Mac, vendor for Windows.)

Comment 18

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: WebGL support, render, language, vendor, supported extensions.

Comment 19

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Milan Sreckovic [:milan] from comment #18)
> Created attachment 8655661 [details] [diff] [review]
> WebGL support, render, language, vendor, supported extensions.

This simple patch does get the information, but at the price of creating a GL context.  A suggestion is to complicate it a bit, but have it with less side effects, by moving the data collection into a separate content process (when in the e10s scenario), and update the info lazily (but before the telemetry gets sent.)

Comment 20

[Georg Fritzsche [:gfritzsche]]

Milan, is this still something you're looking to add or can this be closed?

Comment 21

[Kartikaya Gupta (email:[e-mail])]

Milan isn't at mozilla any more. Redirecting needinfo to original reporter to see if this is something that's still needed? Given the age of the bug it sounds like probably not.

Comment 22

[Andre Vrignaud [:andre] [Seattle - PST]]

This is to support the Firefox Hardware Report initiative, managed by Rebecca Weiss (NIed). I believe that continuing to extend the FHR is valuable for both Mozilla and the web (Firefox org uses regularly), and would encourage us to finally do this work. But Rebecca should comment on where FHR development work fits on her team's current priorities.

Comment 23

[[e-mail]]

Heather Crince is now the product owner of the Public Data Report which has subsumed the Hardware Report.  I'll redirect to her.  We can see if this fits into the next version of the PDR.

Comment 24

[Chris H-C :chutten]

Please reopen if we find that this is still needed. Or, better yet, file bugs in the respective components where the collections would be implemented.