Plans for v1.0.0

[FlyGoat]

I’m excited to share that our project has just hit its 5-year milestone! As part of our ongoing development, I'm planning to release v1.0.0 soon, which will include significant improvements to the codebase. I'd love to get your feedback on the following potential updates:

• Migration to the Meson build system: This would help us avoid the complexities and frustrations often encountered with CMake. (A prototype is already available on the meson branch.)
• Logging callbacks for libryzenadj: This aims to eliminate reliance on stdout/stderr in the library, providing a cleaner and more efficient logging mechanism.
• Extensible API for adding new parameters and PMTable entries: This is still in the design phase, so I'm eager to hear your thoughts and suggestions!

Please use this issue as a function wish list as well.

Thanks

[Erruar]

Hello, FlyGoat!

Congratulations on reaching the 5-year milestone for our project! I’m excited about the upcoming release of v1.0.0 and the potential improvements you've proposed. Below, I've structured my feedback on each area, along with some additional suggestions that could enhance functionality further.

Feedback on Proposed Updates

1. Migration to the Meson Build System

   • Switching to Meson would indeed help streamline the build process and could simplify maintenance compared to CMake. Given that you’ve already started a prototype on the meson branch, I think it would be worthwhile to proceed with this transition to reduce the build complexity.

2. Logging Callbacks for libryzenadj

   • Introducing logging callbacks is a solid approach to make logging more efficient and remove the reliance on stdout/stderr. This would provide cleaner integration, especially in embedded systems or applications where logging needs to be controlled more granularly.

3. Extensible API for New Parameters and PM Table Entries

   • An extensible API for adding parameters and Power Management (PM) Table entries sounds promising. I’d love to see more details on the design as it develops, as I have some specific API-related suggestions below that might align well with this direction.

Suggested Enhancements to libryzenadj

To build on the extensible API you mentioned, here are a few API functions and modifications that could enhance libryzenadj for broader use cases and improved functionality:

1. Enhanced SMU Command Support

   • Add a command function:

     void SendSMUCommand(uint mailbox[], uint command, uint arguments[]);

     • Parameters:
       • mailbox[]: Contains three uint values – CMD, ARG, RSP – for structured command data.
       • command: A single uint command to execute.
       • arguments[]: Array of six uint values for additional arguments.
     • This addition would provide more flexible SMU (System Management Unit) command handling and extend compatibility with other functions that might rely on SMU commands.

2. PM Table Retrieval Functions

   • Add functions for Power Management Table retrieval:

     float[] GetPMTable(RyzenAccess ryzenAccess);
     float GetPMTableIndex(uint tableIndex, RyzenAccess ryzenAccess);

     • Description: These functions would allow more direct access to specific PM Table data (by index or as an entire set) for better monitoring, including desktop CPUs.

3. PM Table Metadata Access

   • Add metadata retrieval functions:

     int GetPMTableSize(RyzenAccess ryzenAccess);
     uint GetPMTableVersion(RyzenAccess ryzenAccess);

     • Purpose: Provides access to PM Table size and version for compatibility checks and adjustments based on specific PM Table versions.

4. Validation Check for RyzenAccess

   • Implement a check to ensure ryzenAccess is not zero before initializing the PM Table.
     • Reason: A null or zero ryzenAccess value is currently causing DLL crashes. Adding this validation would improve stability and avoid runtime errors.

5. Unified Adjustment Command

   • Add a universal function to adjust parameters:

     int ryzenadj_set(const char *param, int value);

     • Details: This command would streamline the parameter adjustment process by accepting a single string argument (param) and a value. It simplifies code by reducing multiple adjustment calls to a single, generalized function.

Additional Suggestions

6. Broader Platform Compatibility
   • Enable Desktop Support: Given that many commands used on laptops are similar or identical for desktop Ryzen CPUs, extending ryzenadj functionality to support desktop CPUs could broaden our user base.
   • Structured Command Lists by CPU Generation: To improve usability, it would be helpful to organize and present command lists based on CPU generation. This way, only relevant commands for the detected CPU model would be shown, simplifying the user experience.

---

Let me know what you think of these suggestions, and feel free to reach out if you'd like any clarification. Looking forward to seeing how the new release shapes up!

Best regards,
Serzhik Sakurajima