Tbh i dont think it will overload the connector nor anything else. I dont really have a clue on why it wont happen but i cant imagine that a pwm header on a pcb can draw so much voltage that it fries something.
I havent tested it yet, i will report it i fry my card.
So, I used a sacrificial 7950 and it held out well. The fury X has been modded with the new cooler and is currently awaiting stress tests.
First results show temps up to 72°C - which isn’t amazing but at least the GPU is working.
All the best for your project.
It is planned to remove all these links when all class device directories live in /sys/devices.
So my tiny, badly written script isn’t even working now, since there has been changes to the whole /sys/device // /sys/device SysFS tree.
In order to proceed with reliably OCing the card I need to know how to actually set the correct values in the correct and lasting way
so the next time there is a change in SysFS it doesn’t break the script. Mostly because I want the script to work on as many cards as possible
which means that it needs to “ship&run” on most systems people have. Meaning:
i) robust way of OCing without crashing
ii)robust way of giving people access to gather more data on exact OCing values
The whole BIOS thing:
The idea behind this is, that the V64 BIOS when modded to have no powerlimit and no templimit pushes the V56 to its maximum performance.
That being sad that also means that you CANNOT RUN A MODDED V64 BIOS ON A STOCK V56. You fry that little thing in no time.
So maybe I can write up a little how-to and call it a day, since I DONT WANT PEOPLE TO FUCK UP THEIR CARDS and modding & flashing a BIOS is
a good show stopper for people who don’t really know what they are doing.
b) get the V64 BIOS (modded) unto the V56
i) get hold of a V64 BIOS
ii) mod that BIOS for fully utilisation (from linux)
iii) flash that BIOS unto the card (from linux)
My perception is that I need to put some time into figuring out how to mod & flash the BIOS and also how to extract that because right now I don’t have a V64 BIOS.
Then I can try to mod that and flash that which should be basically extracting it but in reverse. If I have that done I need my script to be working or I just
have a beast of a V56 without any chance of pushing it to its maximum performance. Working on both things seems to be the right way, so when I get frustrated
with one topic I can switch to the other and get frustrated there. Dual-Switch Frustration so to speak
Now to the (for me) most boring part:
i) reliable metrics for most-used / most-requested / most-viewed / established benchmarks
ii) frametimes: since @anon46267848 and @Adubs explained frametimes to me I want to focus on those & fps since those seem to be the most easily interpretable metrics
iii) generating some nifty graphs for the metrics / benchmarks
To be completely honest: When I read reviews and/or benchmarks I mostly skip through them and only look and my resolution or 4K and than look and the $/fps
for the best value. But making sure that fps and therefore frametimes are the best things to look for I want to emphasise on those two for the benchmarks
between stock V56 and fully modded V56.
And I don’t really wanna spend a couple of hours of my freetime on watching some benchmarks running, although gathering some quantifiable fps/frametimes
is very interesting and I think that getting frametimes metrics in regard of OCing and tweaking the particular values and their interaction.
I’ll continue my work on this since now I got some fruits of my work and I can play Rocket League without booting into WinX which makes so goddamn happy.
It will take some time and work and blood, sweat & tears to get this to a level of sophistication that I’m satisfied with. But what I would need YOUR HELP with is
figuring out what kind of benchmark is the best for representing the performance improvement and also for a “virgin” V64 BIOS.
That’s all for now, I’ll post updates when I have something to show.
Thank all of you who are interested in this thread.
There could be tools for midifying, already, but i doubt that since RX Vega, AMD made those fully Secure-Boot compliant meaning vBios Signature Check in Hardware. Hence when you flash a modifyed vbios, you should get a “Error 43” in windows Device manager. I have no clue how that would express itself in Linux.
The way to OC above limits without changing the VBIOS is as far as i know tweaking the PowerPlayTables.
GamersNexus used that in a few videos to get their Vega 56 to beat some other card.
They failed a bit at explaining how they did that.
But you know how to search for things right ?
If you need to figure out how to parse and modify the VBIOS, you can take a look at the sources of the AMD Linux Driver.