Okay. I was just following your lead. You moved to showcase the cons of a fixed clock. You moved to showcase the pros of a variable clock.
Your argument was that you can extract more out of variable clocks than you could out of fixed clocks.
I went to agree with variable clocks are indeed great as you said they were, but variable boost clocks are based on thermal requirements or power requirements, not game code requirements.
I went on to agree that fixed clocks are indeed less efficient because it cannot capture the whole range effectively.
But you did not bother to discuss how variable clocks on PS5 works. Because it doesn't operate on thermal requirements.
Then I went to showcase how gamecode altering variable clocks will differ from how thermal output affects variable clocks, and if gamecode load is altering the clockspeeds, how developers are now stuck between choosing to maximize their load and reduce clock speed, or reduce their load and keep clockspeed high.
Or if you wanted to overburden your compute pipeline and cause your clockspeed to drop, then your fixed function pipeline would suffer from a clockspeed drop, thus any budgeting there would fall out. And so the developer is going to have to make a decision on where they want to put their budget because it can't be both. The developer is incapable of maximizing one aspect of the pipeline heavily without impacting another. And thus, like fixed clocks, it still suffers from inefficiency from fixing, just differently.
