pbkit: Factor out functionality to facilitate maintenance

[abaire]

Starts breaking up pbkit.c into more manageable chunks. Also adopts a clang-format based on the one used in winapi, adjusted to stay relatively similar with the existing pbkit code.

In followup PRs, I plan to follow a suggestion that @JayFoxRox once made wrt. reducing the amount of automation that pbkit provides by default. E.g., rather than allocating framebuffers directly, provide a forward-looking init that allows the pbkit user to manage their own buffers. We can retain a shim layer on top of the raw interface to avoid breaking existing usages. This will provide users with more flexibility (in particular my own use in nxdk_pgraph_tests, which currently requires patches to pbkit to change the automatic allocations and expose more functionality).

[thrimbor]

I'm torn on this one - they're not bad changes, but I plan to remove almost all of these functions.

My goal is to have all higher-level functionality stripped from pbkit, no drawing, no clearing, no matrix transpositions, no handling of surfaces or buffers. The only thing I want it to do is initialize and shutdown the GPU and handle the main pushbuffer. Even the current push functions I want to remove, because by trying to be convenient to use they actually stand in the way of being able to construct pushbuffer commands as constant expressions at compile time.
I have some plans for a new layer on top of what would remain of pbkit (in terms of code it's currently not much more than a few experiments for a swapchain API and a name, xlg, for Xbox low-level graphics), which then provides buffer management, compile time construction of pushbuffer commands from constant expressions, tile management, and swapchain configuration (so something between Vulkan, the libgcm API and the low-level parts of the Xbox's DX8).

[abaire]

That seems entirely reasonable to me and aligned with what I was thinking as well. Selfishly I'd want to retain the raw pushbuffer interactions, since they're extremely useful in reversing nv2a commands, but definitely agree that the overall user interface for "real" application uses of pbkit is extremely challenging to use.

I'm fine dropping this, at this point I have my own workarounds/extensions of the current pbkit implementation that are sufficient for the pgraph tests, I'll just continue to maintain that patchset.

What's your timeline for xlg? I'd be interested in taking a look at some point to avoid coding myself into a corner that will make it hard to adopt down the line.

[mborgerson]

Imo we should accept the incremental improvement and can deprecate, remove, or replace bits later

[mborgerson]

Should we have a pbkit specific format spec or eventually migrate to use "common" nxdk style? My preference is the latter

[abaire]

Very strongly agreed.

In this case my selfish goal was to avoid having to manually reformat a bunch of my code that I planned to upstream after this, so I opted to minimize the restyle to simplify the PR.

[abaire]

Imo we should accept the incremental improvement and can deprecate, remove, or replace bits later

I think it's a matter of timing. It sounds like @thrimbor has work in progress that overlaps with the followups I was thinking of pursuing, so I'm less inclined to dup that effort by digging into more significant pbkit refactors.

I have some extensions in the pgraph tests that I was going to upstream on top of this, but I worry investing more in extending today's implementation may encourage users to create more complicated dependencies making it harder to deprecate and replace pbkit.

[thrimbor]

Giving it a second thought after some sleep, I agree, we should go ahead with upstreaming what you have. My own stuff isn't nearly ready, and I can't reliably tell when I'll be able to work on it more, it wouldn't make sense to make your life harder because of this.

As for the formatting, what makes most sense imho is to (at some convenient point in the git history) have a big reformatting commit to adopt the nxdk codestyle, and add the commit hash to .git-blame-ignore-revs. Whether that happens now isn't of much importance to me, but long-term I think it's best to use one style for all our code.