Open setsunati opened 5 years ago
Lurkki14
commented
5 years ago CPU overclocking shouldn't be too hard to add, but I'm not going to work on it until I get AMD overclocking working. Also I'm not sure if overclocking RAM is possible outside the BIOS.
Zuccace
commented
5 years ago I'd suggest to add frequency adjustments if not overklocking before diving into CPU overcloking, it it's not too hard to add.
I'm eagerly waiting this, because it would be nice to have one place to control power/overclocking in one place.
murlakatamenka
commented
5 years ago I'm saying my no against this suggestion. Let's have a utility that does just one job (deals with GPUs) and does it well. Reference GPU OC utility MSI Afterburner has nothing to do with CPUs/RAM besides monitoring.
Unlike GPUs, CPUs can be overclocked from BIOS which is always a preferred way. If it's not enough there is, for example https://github.com/r4m0n/ZenStates-Linux to OC AMD Ryzen CPUs (works just fine with a simple systemd service in my case). I guess there are utilities for Intel as well.
Zuccace
commented
5 years ago Unlike GPUs, CPUs can be overclocked from BIOS which is always a preferred way. Yes. GPU side is a priority.
I'de be more than happy just to have cpupower frontend incorporated.
pallaswept
commented
1 year ago Edit: Please excuse my accidental necro of this thread! The issues list was so short (that's a good thing!) that I didn't notice how old it was until just now. My bad, apologies!
I'm not sure if overclocking RAM is possible outside the BIOS.
There exist tools on windows for this, both to change timing directly at runtime, and to modify the BIOS settings for permanent changes... That being said, they are highly vendor- and model-specific and as a result, even across multiple tools, there exist a fair number of limitations.... and because of the massive maintenance burden required to make it work everywhere, I really feel I should encourage that it be an entirely separate project.... Unless you have a bunch of free time, free hardware, and dev friends to help. It's a huge job.
Let's have a utility that does just one job (deals with GPUs) and does it well
This, 10000 times. The Unix philosophy is to be ignored at one's peril. Far smarter ladies and gentlemen than any of us, found out that this is the right way, by making the mistakes required to know the wrong way, many decades ago. It would be unwise not to benefit from their learning it the hard way, by doing it the hard way and learning first-hand what they already taught us.
The correct approach to having the convenience of....
Basically easy overclock everything from a single GUI program.
....Is that the single GUI program utilises libraries from several tools, each made for ONE specific task, and that GUI's ONE specific task, is to put a single GUI in front of those other, individual singular libraries. That way, you have a really great GPU OC lib, made by a GPU expert, and a really great CPU OC lib, made by a CPU expert, and a really great RAM OC lib, made by a RAM OC expert, and a really great UI, made by a UI expert. An app trying to be all of these things at once is a gargantuan undertaking, and an individual being an expert at everything isn't a reality. Even in the commercial space, sub-contractors are called in for their specialities, because not even a whole team of people can do everything.
I must confess a bias in making this opinion heard, and that is that I'd really like to see this project succeed (the reason I popped by this evening was to check the latest commits as I am packaging it for openSUSE to try to help it gain traction), given that it is now the ONLY maintained GPU overclocking GUI on linux, and I'd be dismayed to see it become overburdened to the point of its own death, by trying to be an all-singing, all-dancing wonder app.
From a technical perspective, you really shouldn't be overclocking everything at the same place and time, anyway. A successful and fully stable overclock of each component is a pre-requisite to overclocking the next one. You should be expecting a period of several days and reboots, all the while utilising several separate and task-specific stress-testing utilities, between overclocking each of these components. That being taken into account, the value of a single-GUI app for all of these proposes, is somewhat diminished.
I don't mean to be a 'negative nelly' here, and I'm not trying to stomp out the idea of integration of related tools, it's a nice idea! It would be cool to get there at some point... but I just want to make sure it's done right, and by this I mean to say I especially want to make sure it doesn't kill this app.
Lurkki14
commented
1 year ago An app trying to be all of these things at once is a gargantuan undertaking
I would argue not, since:
The hard part is just having all the different hardware to test with.
pallaswept
commented
1 year ago The amount of code required may not even be that much, eg. the whole code to support Nvidia GPUs is just around 750 lines
It's not the GPU code that concerns me, it's the CPU and RAM code detracting from time, money and effort you have to provide the GPU support.
Even if there were a lot of different libraries needed for each piece of hardware,
How many different combinations of motherboard, chipset and BIOS/UEFI do you suppose there are?
building each plugin is optional
Writing them in the first place is the part that creates a load on you.
The hard part is just having all the different hardware to test with.
Which is why I said
Unless you have a bunch of free time, free hardware,
For commercial endeavours, suppliers will often provide their hardware for development purposes. For FOSS, they're rarely so generous. I hope you're wealthy enough to buy one of every motherboard and its matching CPU and memory, that would be nice for you. Otherwise, there's some more of that burden I wish not to be laid upon you..
I think this will make Tuxclocker even better if we can overclock not only GPU but also CPU and RAM. Basically easy overclock everything from a single GUI program.