Land offthread rendering #12

Closed
taisel opened this Issue Jan 19, 2016 · 5 comments

Comments

Projects
None yet
1 participant
@taisel
Owner

taisel commented Jan 19, 2016

We already run the emulator in a webworker if your browser supports sharedarraybuffer. We'll just spawn another webworker controlled by the emulator core inside first webworker, to render graphics. This really needs to land for performance reasons, we can always pull out if it doesn't give an improvement.

Basically if we land this chunk of code, it'll purposefully start rendering at the start of a scanline, and run in parallel to the core emulation. We're exploiting the undefined-ness of mid-scanline rendering to offthread this, even for scanline-by-scanline interrupts.

@taisel taisel added the enhancement label Jan 19, 2016

@taisel taisel self-assigned this Jan 19, 2016

@taisel

This comment has been minimized.

Show comment
Hide comment
@taisel

taisel Jan 19, 2016

Owner

I already have this feature planned out, so I'll code monkey it.

Owner

taisel commented Jan 19, 2016

I already have this feature planned out, so I'll code monkey it.

@taisel

This comment has been minimized.

Show comment
Hide comment
@taisel

taisel Jan 21, 2016

Owner

The renderer the graphics proxy holds a reference to will be replaced by a shim that contains two fifo ring buffers. They will proxy commands to the webworker and the framebuffer result back to the core thread. The graphics renderer webworker will only thread block/futexWait if the outbound framebuffer ring buffer is full, while the core thread will block/futexWait while the command buffer is full. I/O and VRAM writes will be pushed onto the fifo command buffer unprocessed, with a correspond ID sequence prior to the (optional) data.

Owner

taisel commented Jan 21, 2016

The renderer the graphics proxy holds a reference to will be replaced by a shim that contains two fifo ring buffers. They will proxy commands to the webworker and the framebuffer result back to the core thread. The graphics renderer webworker will only thread block/futexWait if the outbound framebuffer ring buffer is full, while the core thread will block/futexWait while the command buffer is full. I/O and VRAM writes will be pushed onto the fifo command buffer unprocessed, with a correspond ID sequence prior to the (optional) data.

@taisel

This comment has been minimized.

Show comment
Hide comment
@taisel

taisel Jan 21, 2016

Owner

There will be a separate VRAM copy inside the core emulation thread, so it doesn't have to block on R/W of VRAM.

Owner

taisel commented Jan 21, 2016

There will be a separate VRAM copy inside the core emulation thread, so it doesn't have to block on R/W of VRAM.

@taisel

This comment has been minimized.

Show comment
Hide comment
@taisel

This comment has been minimized.

Show comment
Hide comment
Owner

taisel commented Jan 24, 2016

#22

@taisel taisel closed this Jan 24, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment