Meeting minutes
<atsushi> previous minutes: https://
Provide GPU timing info to content #5
bajones: were going to carry on from tpac
… The 7th point is about stabilisation planes which is hardware specific, do we have someone from hololens or magic leap to talk about whether they still need this support.
everyone: silence
yonet: I don't think they are here
bajones: we'll ignore that issue then
… so this will mostly be a discussion about timing measurement
<yonet> https://
<bajones> https://
Need a way to determine whether rendering is falling below target frame rate #6
bajones: This issue is about finding a meaningful metric that is accessible accross all platforms and developers will be able to make use of
… we do have somethign that comes close, which is Klaus's viewport stats from the viewport scaling
bajones: this is probably less like producing a number, instead there will be some heuristic which will report to you that if you made your viewport smaller you are likely to reach the perf target
… maybe klaus can tell us whether this is performing well for anyone, but does seem to be a good approach.
… to take a piece of the api and treat it as a knob which can be turned up or down
klausw: this is currently being used for model viewer where it is working well. It's mainly for the use case where you get close to a complex model it automatically drops resolution to maintain framerate
… i've been usign GPU usage as a guide, <1 is good since not using all GPU ==1 means you are saturating GPU, this is a metric that could be useful if other platforms are willing ot expose it.
… having a rough estimate for whether you are gpu bound sounds useful.
bajones: my assessment of this issue is that I am not seeing a tonne of numbers we could expose to help developers but I think approaches like the viewport scaling is a good pattern to follow.
<bajones> https://
ada: gpusaturation number potentially very fingerprinting sensitive
cabanier: there is also the foveation parameter
… which will let the render spend less time around the periphery.
… shouldn't this be a useful thing for all WebGL things not just WebXR
bajones: i agree if it's a platform wide metric the platform should probably be the one to do them
klausw: perhaps termporal granularity will make it not as useful
… some apps will want a way to set the preference for how they want the app to tradeoff resolution vs responsiveness.
<Zakim> ada, you wanted to see if we can find out why they haven't been done already
<bajones> Ada can you mute again?
ada: we should ask WebGL people why perf metrics haven't been implemented yet, what are the blockers.
jgilbert: In WebGL we've been expecting users to monitor their render times and compare it to RAF to do perf themselves.
… knobs are handy for people with simple experiences but for advanced ones we should provide numerical feedback to be more useful
bajones: it's important to do these things in a privcy preserving manner, we tell users to measure their RAF timings to see if they are missing it. FOr VR deices users may not know what timings they need to hit, since different devices run a different frame rates, sometimes even inside the same device.
… it would be great to tell users when they are reachign and when they are missing framerate
… we could tell them, "you need to reach 72hz"
… i do recall the only consistent number we could get is how many frames the compositor missed i.e. You only supplied 2 of the last 5 frames
… this feels like somethign that could be surfaced without much privacy concern
… since you can get there any way with hacks
<yonet> klausw+
<Zakim> klausw, you wanted to say a device might think it's perfectly hitting 60fps though the actual framerate is 120fps
klausw: i like the idea of the dropped frame counter but then we need a signal to know to increase the complexity again
… when the device is being under utilised.
jgilbert: i wanted to mention for missed frame times with variable refresh rate they don't get missed
bajones: you don't get Variable Refresh Rate in XR. They might try at 90 but if they fail they will lock at 60
cabanier: the magic leap is a Variable Rate device since it will invent frames using the depth buffer
… if it is swap chain based and the frame is still resolving complex things may happen to give poor performance
bajones: we want to see if we should do this here or push for something for the whole platform
… we could do something faster here, and there is a higher privacy barrier for using it so has fewer privacy concerns but a platofmr wide one could benefit everyone. Even then WebXR content though may need a specific use case.
… we could build something here and if it works present it to the wider web, i am not sure the best approach for doing that.
… for timing info it's probably best exposed on the XR frame.
jgilbert: brandon has a good point that we need to spererate desktop vs headset. An alternative would be getting target frame time during the raf callback.
bajones: i believe RequestIdleCallback gives you idle time
… something like this could be equivalent
… it would be a fine line to walk i.e. you have 8ms doesn't tell the frame rate but would be related.
klausw: we need to also make it clear to developers that this includes render time and JS time
jgilbert: we don't even know those numbers in the useragents today
… telling the user what the framerate is might give the best bang for the buck
<yonet> https://
Add support for an optional stabilization plane #7
ada: topic stabilisation planes
bajones: this was an old issue and priorities may have changed is this something we still want to think about?
Lachlan: i'm not sure whether it is in OpenXR
RafaelCintron: the one we have been encouraged to use is the depth buffer stabilisatiing
bajones: since we have a prefered way of capturing depth ifnromation perhaps we should shut this issue down and refer to that.
alexturn: for the hololens 2 submitting a depth frame is the most recommended way to do it, for developers to implement this writing a homemade version is practically impossible.
… So definitely just submitting the depth buffer is the way to go.
cabanier: people are running into VM issues where WebXR is creating issues by creating lots of garbage and causing problems with garbage collection
bajones: can you publish the graphs of those objects so we can look as a group?
… it would be great to take them back to the interface wizards who tell us to ignore GC and show how it is causing us problems, and we can move more GC friendly APIs in the future. Manish's work at alternative APIs is a godo example. Or we can take it back to the browser developer to see if they can fix it.
jgilbert: the audio groups have been looking at these kinds of issues.
<klausw> dynamic viewport scaling: https://
klausw: does anyone have any intent to implement dynamic viewport scaling?
alexturn: for the GC stuff I would be curious to see the profiles to see if they come from the medium objects which last a while since most objects should last exactly one frame then be cleaned up
ada: what is gen zero?
alexturn: the GC is designed to efficiently clear stuff which is short lived and stays in gen 0, gen 1 is for longer lasting stuff.
<ada> s/^/alexturn:/
bajones: if Gen 0 isn't pulling the weight here we need to know why.
<atsushi> s|s/^/alexturn:/||