Support SW Vsync and combine it with HW Vsync

RESOLVED DUPLICATE of bug 1102631

Status

defect
P2
normal
RESOLVED DUPLICATE of bug 1102631
5 years ago
9 months ago

People

(Reporter: boris, Assigned: boris)

Tracking

({perf})

unspecified
2.1 S3 (29aug)
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [c=uniformity p= s= u=])

Attachments

(1 attachment, 8 obsolete attachments)

We should implement a SW Vsync for those platforms which don't support hardware composer. This SW Vsync will simulate the Vsync events (60Hz) as the hardware composer does.
Assignee: nobody → boris.chiou
Summary: Support SW Vsync and notify to gecko → Support SW Vsync and combine it with HW Vsync
OS: Gonk (Firefox OS) → All
Hardware: x86_64 → All
Use nanosleep to implement SW Vsync Timer
Use nanosleep to implement SW Vsync Timer
Attachment #8466144 - Attachment is obsolete: true
We have an internal 60fps clock that's used for compositing when there's no hardware source. Why not use that?
Blocks: Silk
Keywords: perf
Whiteboard: [c=uniformity p= s= u=]
(In reply to Michael Wu [:mwu] from comment #3)
> We have an internal 60fps clock that's used for compositing when there's no
> hardware source. Why not use that?

Compositor usually spends much time for composing. If we don't use a specific thread to do this, it's hard to get a precise 60fps timer.
Flags: needinfo?(hshih)
(In reply to Boris Chiou [:boris] from comment #5)
> (In reply to Michael Wu [:mwu] from comment #3)
> > We have an internal 60fps clock that's used for compositing when there's no
> > hardware source. Why not use that?
> 
> Compositor usually spends much time for composing. If we don't use a
> specific thread to do this, it's hard to get a precise 60fps timer.

If the only sink of this vsync signal is the compositor, then it doesn't _need_ the external SW signal, since as long as it's busy it can't handle the next composition anyway, regardless of when or where the vsync signal was generated.

On top of that, a thread is not with zero overhead and so are events.

However, an external (to the compositor) SW vsync source could help with few things IMO:

1. Most importantly - unified architecture. The compositor will drop its 60hz code and instead the only vsync generation would reside at one place at the code which could control the rate, HW/SW, etc.

2. If we want to simulate faster refresh frequency for testing (to swamp the compositor for instance), then a single source of vsync would be easier to handle.

3. If there are other consumers for vsync, such as the refresh driver, then an external to the compositor source would be easier to handle.

Regardless of the above,

- The SW vsync signal will need to be error corrected based on actual timestamps. Fixed intervals or fixed rate events would most probably drift (we've seen this at the windows desktop firefox 60hz "emulation" at the refresh driver).

- Most monitors refresh at 59.94 hz and not 60, if you care enough.
(In reply to Avi Halachmi (:avih) from comment #6)
> 1. Most importantly - unified architecture. The compositor will drop its
> 60hz code and instead the only vsync generation would reside at one place at
> the code which could control the rate, HW/SW, etc.
> 

This makes sense if we can get rid of the 60hz clock in both the compositor and refresh driver. Right now, a lot of the code seems to be Gonk specific.
Priority: -- → P2
Target Milestone: --- → 2.1 S3 (29aug)
Status: NEW → ASSIGNED
1. Use nanosleep to implement SW Vsync Timer
2. Add soft vsync timer support for PlatformVsyncTimer
3. Add SetPriority() to PlatformVsyncTimer (Default nice value is -2)
4. Add FrameUniformityForceSWVsync pref
Attachment #8483326 - Attachment is obsolete: true
From discussing with Avih, we should "tie the new vsync dispatcher to the same pref which defines the rate now - layout.frame_rate, where -1 is the default (vsync or fixed 60hz), 0 is asap, and positive is an explicit refresh rate for firefox" for the software vsync timer. We need both custom rates / as fast as possible as it is used for talos performance tests.
Depends on: 1102631
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1102631
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.