Better problems detection
25 views
Skip to first unread message
Ivan Popelyshev
Nov 18, 2020, 1:50:35 PM11/18/20
to WebGL Dev List
My original question from WebGL 18-11-2020 meetup, Ken asked me to post it here.
Hello from PixiJS!
Are there any new special options for compatibility purposes? Like failIfMajorPerformanceCaveat or powerPreference. For app with big userbase its critical to have control or at least analyze what's wrong with user machine.
Extra:
Hello from PixiJS!
Are there any new special options for compatibility purposes? Like failIfMajorPerformanceCaveat or powerPreference. For app with big userbase its critical to have control or at least analyze what's wrong with user machine.
Extra:
It would be awesome if we could at least ask user permission to share size of available memory/videomemory. I'm porting big flash online game that has like 500 megapixels of content, uses runtime atlases for rasterized objects, huge amount of vector graphics. For now I track the "texImage2D" fail.
Jeff Gilbert
Nov 18, 2020, 2:48:04 PM11/18/20
to webgl-d...@googlegroups.com
Great question!
Can you expand on what you're looking for when you say "analyze what's
wrong with user machine"?
For failIfMajorPerformanceCaveat, the context creation failure message
ought to contain actionable info that you can pass to the user, though
slightly stripped down for privacy. If us browsers are falling short
of what you need there, we'd love to work with you to fix it!
--
I think that querying available gpu memory is really gated at the more
general web-platform standards level, where it's not (yet?) possible
to query available system memory. (On e.g. Android, this is the same
number!)
Unfortunately I think that is a bigger decision than WebGL can make
alone. If we can think of some strong reasoning and unmet use-cases, I
think WebGL would be happy to participate in that higher level
discussion.
You *can* probe if you know how much space you want to test for. You
can either make an allocation of that size (maybe a bufferData(size)?)
or slowly add e.g. 100MB at a time and measure allocation time to
check whether you start swapping too much. (yes, the gpu can swap!) As
a warning we have definitely seen exceedingly slow allocations that
*eventually* succeed for sudden one-shot large allocations.
It's great that you're tracking texImage2D failures already! I just
don't have anything much better to offer you any time soon though, I'm
afraid!
> --
> You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/cfe500eb-f8fc-4588-b40d-0cf81147a3a2n%40googlegroups.com.
Can you expand on what you're looking for when you say "analyze what's
wrong with user machine"?
For failIfMajorPerformanceCaveat, the context creation failure message
ought to contain actionable info that you can pass to the user, though
slightly stripped down for privacy. If us browsers are falling short
of what you need there, we'd love to work with you to fix it!
--
I think that querying available gpu memory is really gated at the more
general web-platform standards level, where it's not (yet?) possible
to query available system memory. (On e.g. Android, this is the same
number!)
Unfortunately I think that is a bigger decision than WebGL can make
alone. If we can think of some strong reasoning and unmet use-cases, I
think WebGL would be happy to participate in that higher level
discussion.
You *can* probe if you know how much space you want to test for. You
can either make an allocation of that size (maybe a bufferData(size)?)
or slowly add e.g. 100MB at a time and measure allocation time to
check whether you start swapping too much. (yes, the gpu can swap!) As
a warning we have definitely seen exceedingly slow allocations that
*eventually* succeed for sudden one-shot large allocations.
It's great that you're tracking texImage2D failures already! I just
don't have anything much better to offer you any time soon though, I'm
afraid!
> You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/cfe500eb-f8fc-4588-b40d-0cf81147a3a2n%40googlegroups.com.
Ken Russell
Nov 20, 2020, 8:19:09 PM11/20/20
to WebGL Dev List
Please also see "Estimate a per-pixel VRAM Budget" in the WebGL Best Practices document. The recommendation is to test your WebGL application on a few devices, and determine a fixed bytes-per-pixel requirement for your application to help it scale from mobile devices to powerful desktops.
-Ken
To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAOztSJ1g-LB83duC5%3DPeowPKqeigxE4EmkUdGStAL%2B_gwP3cDA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages