Marking this as draft for now, because I was a bit uncertain about whether this was the ideal way to do this, and would also still like to double check everything.
Description
Adds calls into platform and ruby for each rendering-related function in screen, and adds the usesSoftwareRendering variable to allow for the future use of a fully ruby-implemented render path.
Motivation / Context
ares currently creates completed guest frames on the CPU, including rendering certain kinds of padding, scaling, and effects, before sending them to the video backend to be post-processed, composited and displayed.
It ought to be more efficient to perform as much of this work as possible directly in the video backend. Certain effects, particularly things like color bleed, could be more efficiently parallelized there (not to mention scaling and other compositing).
ares has expressed interest in moving further with this approach, with the emulation thread essentially just outputting a video signal, with the video backend entirely responsible for assembling this signal into frames. While I think this PR does not quite directly enable this approach[^1], it begins moving in that direction by allowing the GPU to perform tasks that were previously software-rendered.
[^1]: I have not looked at this super closely yet. It seems like this may require changes to scanline()? It might also be that with ruby having a reference to the screen instance, it can already directly index into pixels to get granular scanline data timed with e.g. host display presents.
The end goal of that work would be to make ares's rendering more efficient, as well as (potentially, maybe) lowering frame latency.
A side benefit of this PR is that the video backend can be informed about the state of screen to correct for things like line doubling, interlace mode changes, and other scaling effects while the software-rendering path is still used (https://github.com/ares-emulator/ares/pull/1508).
Marking this as draft for now, because I was a bit uncertain about whether this was the ideal way to do this, and would also still like to double check everything.
Description
Adds calls into
platformandrubyfor each rendering-related function inscreen, and adds theusesSoftwareRenderingvariable to allow for the future use of a fullyruby-implemented render path.Motivation / Context
ares currently creates completed guest frames on the CPU, including rendering certain kinds of padding, scaling, and effects, before sending them to the video backend to be post-processed, composited and displayed.
It ought to be more efficient to perform as much of this work as possible directly in the video backend. Certain effects, particularly things like color bleed, could be more efficiently parallelized there (not to mention scaling and other compositing).
ares has expressed interest in moving further with this approach, with the emulation thread essentially just outputting a video signal, with the video backend entirely responsible for assembling this signal into frames. While I think this PR does not quite directly enable this approach[^1], it begins moving in that direction by allowing the GPU to perform tasks that were previously software-rendered.
[^1]: I have not looked at this super closely yet. It seems like this may require changes to
scanline()? It might also be that withrubyhaving a reference to thescreeninstance, it can already directly index intopixelsto get granular scanline data timed with e.g. host display presents.The end goal of that work would be to make ares's rendering more efficient, as well as (potentially, maybe) lowering frame latency.
A side benefit of this PR is that the video backend can be informed about the state of
screento correct for things like line doubling, interlace mode changes, and other scaling effects while the software-rendering path is still used (https://github.com/ares-emulator/ares/pull/1508).