You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Posting this here because I figure if we do this we'd want to just expand the current device memory spec, but happy to move this conversation elsewhere if we think that'd be better.
The issue
Getting device memory was a big step in the right direction for us! It'll allow us to stop shipping heavy JS to clients that cannot handle it.
However, there are still cases where a device might have enough memory but would be CPU constrained and we would end up shipping a CPU-intensive function when we could have served a lighter version.
Similarly, memory info isn't enough to know whether we should ship something that might be GPU-intensive. Right now, we can get basic information about the GPU by spinning up a WebGL context and asking for the WEBGL_debug_renderer_info, but on older devices, spinning up a WebGL context can be expensive and cause the page to freeze for several seconds.
Finally, while knowing memory info is good, we need to know the CPU clock speed and GPU info to help us paint the full picture of what the critical path looks like across various device types and how the device performs on different hardware tiers.
The solution
For CPU information, we can expose the CPU clock speed in the same way that we expose device memory (with some level of fuzzing). Clock speed, device memory and hardwareConcurrency are enough to paint a full picture about the device's processing capabilities.
For the GPU info, let's expose the same info that WEBGL_debug_renderer_info already exposes but not require a WebGL context to get spun up.
Privacy/Security
For GPU info, there are no new big security or privacy issues to think through. We'd be exposing info that's already available but in a more performant way.
For CPU info we can do some level of fuzzing to help things here.
What about ARM's big.LITTLE?
ARM's big.LITTLE architecture allows the CPU to have two different clock speeds and to switch between them based on current usage. Maybe to start, we expose the frequency info for the CPU that's currently in use and post an event if the configuration changes? Happy to discuss this more, I'm not sure if I know enough about this.
The text was updated successfully, but these errors were encountered:
@yoavweiss, this doesn't seem to have picked up steam so I'm not sure if it's worth it to bring this up again. Happy to talk about it if we have extra time, but I would keep this as a low pri item on the schedule.
Posting this here because I figure if we do this we'd want to just expand the current device memory spec, but happy to move this conversation elsewhere if we think that'd be better.
The issue
Getting device memory was a big step in the right direction for us! It'll allow us to stop shipping heavy JS to clients that cannot handle it.
However, there are still cases where a device might have enough memory but would be CPU constrained and we would end up shipping a CPU-intensive function when we could have served a lighter version.
Similarly, memory info isn't enough to know whether we should ship something that might be GPU-intensive. Right now, we can get basic information about the GPU by spinning up a WebGL context and asking for the WEBGL_debug_renderer_info, but on older devices, spinning up a WebGL context can be expensive and cause the page to freeze for several seconds.
Finally, while knowing memory info is good, we need to know the CPU clock speed and GPU info to help us paint the full picture of what the critical path looks like across various device types and how the device performs on different hardware tiers.
The solution
For CPU information, we can expose the CPU clock speed in the same way that we expose device memory (with some level of fuzzing). Clock speed, device memory and hardwareConcurrency are enough to paint a full picture about the device's processing capabilities.
For the GPU info, let's expose the same info that WEBGL_debug_renderer_info already exposes but not require a WebGL context to get spun up.
Privacy/Security
For GPU info, there are no new big security or privacy issues to think through. We'd be exposing info that's already available but in a more performant way.
For CPU info we can do some level of fuzzing to help things here.
What about ARM's big.LITTLE?
ARM's big.LITTLE architecture allows the CPU to have two different clock speeds and to switch between them based on current usage. Maybe to start, we expose the frequency info for the CPU that's currently in use and post an event if the configuration changes? Happy to discuss this more, I'm not sure if I know enough about this.
The text was updated successfully, but these errors were encountered: