You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are various issues regarding gpu support, as there are a lot of things that need to be done. There exist the amazing freegnm written by @pipehuffer. That includes all components needed for basic rendering and is an excellent candidate for this. It being in C makes it a little more verbose to program compared to using c++, so I believe OpenOrbis should implement a wrapper around that API. I can think of several options
freegnm is integrated into OpenOrbis and reworked into a more C++ like API
freegnm is kept as an external dependency and OpenOrbis simply provides a wrapper
Nothing of the above
I'm personally fond of first option as its most convenient and together with a potential cmake toolchain will make prototyping samples and hardware tests much faster. I would like to work on this but I'm not sure if any existing work of that sort exists already and what opinions maintainers have about it
The text was updated successfully, but these errors were encountered:
Forking freegnm then gradually port it to C++ and remove any unneeded functionality (taking over it instead of integrating it as a dependency)
Writing a new library focused on PS4 usage only from scratch
The latter may look like more work, but may make sense because:
It could be implemented it in C++
It could focus only on 3D graphics on the PS4, thus making it simpler, unlike freegnm (which tries to implement that along with (half-broken) tools and emulation utility).
Development would be handled by the OpenOrbis people instead of one (1) random dude
For PS4 specifically, I think we definitely need at minimum
Command buffer classes for gfx and compute queues. These can just be lightweight wrappers over emitting raw pm4 packets
Utilities for managing image/buffer/sampler sharps (probably wrapper classes as well) and some system to manage binding them to a shader (where to copy them in the table shader fetches)
GpuAddress library for computing surface bounds on allocated memory
A shader compiler + a format for loading shaders (should it consume gcn assembly, use a language like spirv/slang or both?)
Freegnm does seem to partially cover these so could be used as starting point probably
There are various issues regarding gpu support, as there are a lot of things that need to be done. There exist the amazing freegnm written by @pipehuffer. That includes all components needed for basic rendering and is an excellent candidate for this. It being in C makes it a little more verbose to program compared to using c++, so I believe OpenOrbis should implement a wrapper around that API. I can think of several options
I'm personally fond of first option as its most convenient and together with a potential cmake toolchain will make prototyping samples and hardware tests much faster. I would like to work on this but I'm not sure if any existing work of that sort exists already and what opinions maintainers have about it
The text was updated successfully, but these errors were encountered: