Reading AMD GPU's busy-percentage

[BayouGuru67]

Okay, so as of now I know of 2 ways to get an AMD GPU's busy-percentage or utilization percentage, if you will. They are:

1. Calling the data from the external program radeontop. I do not like this method because I do not like calling another program, especially one with so many features and options every half second just to give me a single number. It just feels very inefficient when I know the info is already present and available on the system via other methods. Speaking of which...

2. ${exec 'cat /sys/class/drm/card1/device/gpu_busy_percent'} This is the method I am currently using from within a lua in my cpu conky, which also has the GPU usage, frequencies, etc. in it.

I am now fairly certain there is a 3rd way using the i2c command, but I do not understand the syntax of it well enough to make it work to suit my needs. The command documentation says:

${i2c (dev) type n (factor offset)}
I2C sensor from sysfs (Linux 2.6). Parameter dev may be omitted if you have only one I2C device. Parameter type is either in or vol meaning voltage; fan meaning fan; temp meaning temperature. Parameter n is number of the sensor. See /sys/bus/i2c/devices/ on your local computer. The optional arguments factor and offset allow precalculation of the raw input, which is being modified as follows: input = input * factor + offset. Note that they have to be given as decimal values (i.e. contain at least one decimal place).

My GPU info is available via i2c bus 5, and the gpu utilization is specifically located at:
"/sys/bus/i2c/devices/i2c-5/gpu_busy_percent"

I may be on a fool's errand here, as the closest I have managed to getting it to work is using the command "${i2c 5 gpu_busy_percent 0 1}" which results in the error

conky: can't open '/sys/bus/i2c/devices/5/gpu_busy_percent0_input': No such file or directory
please check your device or remove this var from conky

So it seems that conky automatically puts the _input in there even if "in" is not specified, which of course breaks the command for my purposes.

I wonder if perhaps it may be possible to update conky itself to make the i2c command a bit more flexible/useful so as to be able to do this internally without having to cat the data via exec? Perhaps by allowing gpu_busy...(or other data field type definitions) instead of just the 4 predefined types and having conky NOT append _input and NOT require the sensor number if the sensor type specified is something other than those 4 predefined types? This would open up a whole world of additional data on AMD GPU's and other devices as well.

This would enable a command such as ${i2c 5 gpu_busy_percent}' '${i2c 5 gpu_busy_percent n}' or '${i2c 5 gpu_busy_percent n 1} where "n" would actually be an n for none, which would tell conky not to insert a number after the gpu_busy... sensor type designation, and use a factor of 1 for displaying that data. I included that 1 (which would be unneeded for a factor of 1) because I know some of the data in that directory will need to be refactored or offset for proper usage/display, so I think the addition of the "n" for none option to the sensor number options in conky would make the coding modifications easier and still allow for refactoring or offsets of the other data. After this change, the i2c command would still work as before, but would also support the other data types and would not assume the command formatting for those non-predefined data types other than to treat those inputs as numbers if they are numeric in nature (it could also be tied to the end of the type, where if the end of the type is "speed" "width" "percent" "total" "used" or"clk" and/or treats the data as strings if anything other than 0-9 are present in the data. Alternatively, the n could be used to signify that the data being retrieved is a numeric value versus an s for a string or textual data field.

FYI, that directory contains a LOT of very interesting and informative files, with none of them being named fan, temp, input or voltage. Some of the more interesting data files I might want to utilize at some point are named as follows:

board_info
current_link_speed
current_link_width
device
gpu_busy_percent
irq
max_link_speed
max_link_width
mem_busy_percent
mem_info_gtt_total
mem_info_gtt_used
mem_info_preempt_used
mem_info_vis_vram_total
mem_info_vis_vram_used
device/mem_info_vram_total
mem_info_vram_used
power_dpm_state
power_state
pp_cur_state
pp_dpm_mclk
pp_dpm_pcie
pp_dpm_sclk
pp_force_state
pp_mclk_od
pp_num_states
pp_od_clk_voltage
pp_power_profile_mode
pp_sclk_od
pp_table
subsystem_device
subsystem_vendor
thermal_throttling_logging
uevent
vbios_version
vendor

Your thoughts?