rpcs3 icon indicating copy to clipboard operation
rpcs3 copied to clipboard

[Task] Multi-context support

Open kd-11 opened this issue 4 months ago • 1 comments

Task schedule for multi-context support in RSX. This work-plan may get modified over time, but it is important to keep my thoughts on the architecture in a tracker so I don't forget.

The new arch has 4 tiers:

  1. Hardware - These are the functional units (nv4097, nv308a, etc) and their methods.
  2. Firmware - This is everything that drives the hardware units. It includes most current "thread state" objects, caches including the texture cache, program caches, etc.
  3. Renderers - These are the actual host renderers and will be decoupled from the RSX thread. They can bind to firmware contexts and drive data to the host GPU writing to firmware context objects (e.g textures, buffers, etc).
  4. Pseudo-userland - This is what drives the FW to get work through the system. One good example of this right now is the capture playback thread and the VM guests. They should create and manage contexts to work with. VSH emulation will be migrated to this layer from it's current scattered implementation.
  • [ ] Move the hardware bits out of RSX shared code. They are distinct logical units and really have no business being stuffed all over.
  • [ ] Separate savable context pieces from unsavable one. Split register state between HW and FW and have it dynamically allocated.
  • [ ] Separate the "thread" into logical pieces. This was already done before but I gave up before making too much progress. The FIFO management component and the ZCULL management component were decoupled from the thread pump. We need to also split off the GRAPH component and the DISPLAY component into separate bits and wire everything up neatly.
  • [ ] Decouple the backends from the RSX thread. They should just be another functional component. Drop "GSRender" completely. This will also move a lot of the "logic" of the backends to the RSX thread itself as it now functions as a broker between the units.
  • [ ] Split the texture cache into manageable components. It is a megatemplate right now with thousands of lines of heavily-templated C++ code that does all kinds of random things. A rough outline would be to split the actual texture cache from the texture decoder unit and the blit engine unit.
  • [ ] Move ownership of the core state objects and caches to the FW context. We should be able to load and execute multiple contexts at this point.
  • [ ] Update the lv2 driver to manage the context changes. This will likely happen slowly with each update upto this point.
  • [ ] Centralize all the native UI stuff under a VSH emulation thread. This should render to it's own virtual FW context and composite onto the display output.
  • [ ] FW context crash recovery (for device lost situations). Since the thread is a separate thing now from the renderer, we should be able to reboot a renderer and inherit partial context.

kd-11 avatar Apr 10 '24 20:04 kd-11

My estimate is 20 story points.

Megamouse avatar Apr 10 '24 20:04 Megamouse