taisel/IodineGBA

Gfx thread should skip rendering lines if it knows it’s too far behind
in the command queue now.

It shouldn’t, but it requires a store to the dummy value we use…

Also yeah, firefox has broken futexes

- Allow command buffer to increase in size dynamically without stalling
the emulation thread.

- Stall emulation thread if the gfx thread is behind on a scan line
counter too much.

- gfx thread’s timer is matched at the same rate the core emulation
thread runs at.

- Thread wait seems broken in firefox nighty, so we added some
workarounds…

We delayed rendering until an i/o or data change for single threaded
rendering, but it’s optimal to render when given a render scanline
command immediately when doing off thread, since the thread is already
dedicated to graphics (And the cache coherency trick no longer applies).

Land it!

need to verify that though……..

Will allow shimming and is cleaner in api terms.

Also I still am trying to figure out what the best command buffer queue
size will turn out to be.

Seems that our best bet is to forward the shared memory frame buffer
references from the core emulation thread to the worker thread rather
than create another copy operation that could defer graphics from being
on screen for another 16 ms.

We re-added some memory fencing earlier. Then I thought back on the
original design and realized the staleness fits within some constraints
with the designated buffering scheme. Go back to minimal fencing
paradigm to avoid stalling the bus on user’s computers.

Make counters slightly less stale when viewed by opposing threads.
Didn’t want to do this as it adds overhead.