mdrejhon
commented
4 years ago Expected Call-Blocking Behaviours Injected To Emulator Modules
For those people who ask questions about call-blocking behaviours:
Whomever implements this GitHub item don't have to worry about whomever implements beamraced outputs (#6984 or #10757). This information is only provided to provide call-blocking-behaviour understandings, for emulation sync programming.
Handler of retro_set_raster_poll is permitted to block briefly (sub refresh)
Be noted, return from retro_set_raster_poll may be erratic delays (at the microsecond timescales) because the handler (whomever implements #6984 or #10757) may block return for raster interrupt beam racing synchronization purposes.
The module that handles retro_set_raster_poll may be synchronizing to a hardware-based raster, for example, or a refresh cycle interval (e.g. beamracing a 60Hz output to a 360Hz display in segments), as there are multiple hardware-based and software-based beam raced output approaches.
So if it is doing 600-frameslice beam racing, and if it about 1/10th refresh ahead of schedule, it might suddenly decide to block for 1/10th of a refresh cycle, before returning.
This is no different from the existing retro_set_video_refresh which can block for 1 full refresh cycle.
Instead of retro_set_video_refresh blocking for 1 refresh cycle, the combined 200 calls to retro_set_raster_poll for a 200-scanline emulator might potentially have a total sum blockage of one emulator refresh cycle. Basically it's just retro_set_video_refresh blockages fragmented into many tiny pieces.
Expected call blockage of retro_set_raster_poll is balanced
For those wondering how beamraced output handlers will handle it, examples of situations that may be experienced. Whomever later writes the retro_set_raster_poll handler MAY be permitted to do sub-refresh delays, as absolutely necessary for beamraced synchronization
For a 240-pixel-tall emulator frame buffer,
- retro_set_raster_poll creates 240 potential blockages of up to 1/240th of a emulator refresh duration _(Example: beam racing to a NVIDIA VRWorks front buffer)
- retro_set_raster_poll creates 10 potential blockages of up to 10/240th of an emulator refresh duration, and 190 immediate zero-delay "returns;" (Example use case: VSYNC OFF frameslice beam racing in #6984)
- retro_set_raster_poll creates no blockages (240 immediate returns;) (Example use case: beam racing not supported by emulator module)
- Other situation, whether consistent blockage per scanline, or batched processing (like frameslice approaches), etc.
The remainder of blocking will occur in retro_set_video_refresh (the normal VSYNC ON blocking behaviour) for whatever retro_set_raster_poll didn't block. It will then just continue to merrily run at correct emulator refresh rates.
For perfect output beamracing, all display output will have been automatically done inside the retro_set_raster_poll with the final afterwards retro_set_video_refresh being NOP (an immediate return;)
Emulator module doesn't have to worry about how output is beamraced
The bottom line is the emulator module shouldn't have to care whether the output display was refreshed via retro_set_raster_poll, or via retro_set_video_refresh, or even both.
It is possible that the beamraced module (which this github item doesn't have to worry about) may automatically switch processing workload balance between retro_set_raster_poll and retro_set_video_refresh ...
For example, a screen being rotated might automatically temporarily disable beamraced sync (if output display scanout direction is not in sync with emulator scanout direction).
Most displays are always sequential scanout, even LCDs, iPads, OLEDs, as seen in high speed videos, www.blurbusters.com/scanout ... which the beamraced handler may or may not piggyback off (#6984 does, but #10757 doesn't necessarily).
hizzlekizzle
UPDATE December 2023: Bounty Requirements Reduction
Completing #10758 qualifies for the full bounty published at #6984 ... See latest comment https://github.com/libretro/RetroArch/issues/10758#issuecomment-1839907540
Original
We need a very simple per-raster callback function called "retro_set_raster_poll" whose arguments are identical to "retro_set_video_refresh".
Once the centralized hook is done, all emulator modules can just chain it to retro_set_video_refresh by default. This will be default behavior, for beamrace-unaware backwards compatibility
This API is a prerequisite for multiple GitHub items:
6984 aka Add Beam Racing/Scanline Sync to RetroArch (aka Lagless VSYNC)
10757 aka (BFIv3) Emulate a CRT Electron Gun Via Rolling-Scan BFI
Either or both may be implemented at some time in the future. Having this feature trailblazed will help.
Stage 1: Start with dummy hooking all emulator modules
Initially, retro_set_raster_poll would just do nothing .... It would never be used. Just add the hook, and make sure that there are do-nothing hooks compatible in all emulator module header files.
Stage 2: Make at least one module support beamraced output
I would pick the NES module since from a quick glance, that module seems to only need potentially maybe just only 10 to 20 lines of modifications to support retro_set_raster_poll (to beam race its output to whomever programs future beamraced outputs within #6984 or #10757).
By having one emulator module already support beamraced output capability, this would make it much easier for develoeprs to begin implementing any kind of beamraced outputs
Behavior for emulator modules that choose to support beamraced outputs,
You wouldn't have to worry about it, that's the responsibility of whomever programs the handling of retro_set_raster_poll -- the only responsibility for emulator module maintainers is to simply call it when an emulated raster is complete (one pixel row completed into emulator frame buffer).
How many calls per emulator refresh cycle?
This allows supporting beamraced outputs in a simple & cross-platform way.