[GSP] Fine grained control over GSPGPU state

[kynex7510]

I built a library which is a custom implementation of the GX subsystem. The reason for this is to support both userland and baremetal homebrew with a unified interface, as this library will be used by my opengl implementation.

For what concerns the userland part, this library completely relies on GSP callbacks to collect interrupts, and the integration works nice, with no conflicts with libctru's own GX implementation (so long applications stick to one or the other). The only part where I had to diverge and fork libctru is the initialization, as to work, my library needs access to GSP shared memory, in particular to the command queue. There is currently no way to access GSP shared memory directly from libctru, and I believe this is fair, because I'm sure libctru was designed for tight integration with Citro3D, and flexibility on that regard wasn't really a requirement.

With the current code, the changes I need for my library to work correctly are minimal: a function to expose the GSP shared memory pointer (gspSharedMem in gspgpu.c), and another to expose the thread ID gspThreadId in gspgpu.c). However, I'm aware there's an ongoing (done, perhaps?) rewrite of the libctru graphics system, which is why this is an issue, and not a pull request.

Therefore, I'm asking you to consider implementing a flexible way of handling GSP internal state, perhaps by being able to register one particular GX implementation, akin to how an application can set event callbacks right now, so for example, a library like Citro3D would use libctru's default implementation, while an external library like mine could be used by my opengl implementation.

[fincs]

However, I'm aware there's an ongoing (done, perhaps?) rewrite of the libctru graphics system, which is why this is an issue, and not a pull request.

There are indeed planned updates to the entire graphics system (affecting libctru and citro3d), which we hope to be able to roll out soon.

Therefore, I'm asking you to consider implementing a flexible way of handling GSP internal state, perhaps by being able to register one particular GX implementation, akin to how an application can set event callbacks right now, so for example, a library like Citro3D would use libctru's default implementation, while an external library like mine could be used by my opengl implementation.

The approach we followed for above is kind of the opposite: GX has now been redesigned and rewritten to be more general purpose, to both make it easier to support non-citro3d downstream users (such as your opengl implementation), as well as porting the GX layer to a non-GSP-sysmodule backend (although we presently do not have plans to support non-NATIVE_FIRM homebrew).

And also, before embarking on big projects involving homebrew infrastructure, it'd be a good idea to contact us first before doing any work, as there can be significant overlap. We can always be reached through the devkitPro forums and through email. If this is not done, there's always the risk of building on top of code that is planned to be removed or significantly changed, which inevitably causes endless support issues both for you (dealing with breakage) and for us (dealing with unhappy homebrewers who can't compile code with latest tools).

[kynex7510]

Thanks for the quick reply and the head up, I will wait for the changes to see how to proceed.