Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
[Sammelthread]Offizieller AMD RX 9070 (XT) Overclocking und Modding Thread
How to do it software was explained by me. I2C with soldering wires was indeed older idea. But I have explained how to do it software, I posted on 2nd of May 2025 here:
This way people don't have to solder anymore, they can temporary or permanently alter their RDNA3 and RDNA4 power levels, + other modifications (VID etc, current limit etc).
I also have no problem with others replicating my work, I encourage it. I was just expecting common sense that is all.
It is also not "my behavior", I came with good intentions and your friend bullied and ridiculed me, for not knowing as much as he does. I cannot accept such behavior, I do not care who you are or how famous you are in the overclocking world. He was wrong on my project and I didn't want to accept it, sorry.
Again, everyone can build as many tools using this idea, I was just expecting common sense, that is all.
Beitrag automatisch zusammengeführt:
Actually just so you don't think I don't like sharing, here is something you all might be interested in, the full MP2868A register list, ALL of them, with explanations for every single bit.
Datenschutzhinweis für Youtube
An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.
Youtube Videos ab jetzt direkt anzeigen
If you follow the description of video, you will run into a list of interesting dumps. With small modifications you can get to full register list. You should be able to figure it out.
Ja, war echt eine gute Idee von dir. In igors Forum hattest du ja auch gleichgesinnte gefunden.
Das hast du dir aber dann ganz schnell mit Beschimpfungen und fehlender Kritikfähigkeit verscherzt.
Und wenn du genau hinschaust, nimmt das RebelsTool andere Register für die Power.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ja, war echt eine gute Idee von dir. In igors Forum hattest du ja auch gleichgesinnte gefunden.
Das hast du dir aber dann ganz schnell mit Beschimpfungen und fehlender Kritikfähigkeit verscherzt.
Und wenn du genau hinschaust, nimmt das RebelsTool andere Register für die Power.
If I bring something to the table, you keep your criticism to yourself. That's common sense I think. I was friendly with all of you until some of you started acting weird towards me.
As for power altering, there's offset and there's also scaling, which I recently added to my script after I ran into the full register list for MP2868A, there's more ways to do it. But this is besides the point anyway, this isn't about what registers or this nonsense, I just offered the full register list (with a bit of work you get to it), it is about common sense courtesy. My work is open, else it would be a binary with no clue how it does what.
If you build based on someone else's idea, the least bit you can do is mention it, don't you think? Without the "how" you cannot make your tool anyway.
Beitrag automatisch zusammengeführt:
In the resource I shared you will also be able to get full register list with explanation for each of them, in detail, also for MP2856 and MP2857, so both RDNA3 and RDNA4, full VR register list, you can fully reprogram every single aspect of it (most likely), via I2C. RDNA4 still a mystery with saving page 0x02 mods. Must be some special command, like 0x15 is for pages 0/1. What should be EEPROM pages are 0x0000 on all registers.
Block read of 3 bytes reveals one more byte, but doesn't seem related. Per-phase current also is a bit strange, might require block read for more data, there's third byte there as well, changing with load.
Das habe ich nur am Rande mitbekommen, aber hast einigen so auf die Füße getreten, das du aus Igors Forum gelöscht und gebannt wurdest.
Das muss man erstmal schaffen.
Das habe ich nur am Rande mitbekommen, aber hast einigen so auf die Füße getreten, das du aus Igors Forum gelöscht und gebannt wurdest.
Das muss man erstmal schaffen.
🤭 Nobody banned me. I asked Mr. Wallossek to delete my user name and close my account because I didn't want to be associated with that forum, he can attest to that. I left that place because I felt unwelcome there, no reason for me to go somewhere where I am not appreciated. Not sure who told you I was banned. There was someone there who wanted to ban me, but he didn't manage to, but in the end I fulfilled his wish.
I think you got it all wrong.
🤭 Nobody banned me. I asked Mr. Wallossek to delete my user name and close my account because I didn't want to be associated with that forum, he can attest to that. I left that place because I felt unwelcome there, no reason for me to go somewhere where I am not appreciated. Not sure who told you I was banned. There was someone there who wanted to ban me, but he didn't manage to, but in the end I fulfilled his wish.
I think you got it all wrong.
Yes, took a few emails to convince Mr. Wallossek to do it, because normally they cannot, so he offered the solution to add my name to the "naughty list" of words, so it gets masked with **** 😁. That was still me, I insisted my name is not visible there, initially he didn't want to do it but he managed to come up with this solution, which I appreciated.
As for power altering, there's offset and there's also scaling, which I recently added to my script after I ran into the full register list for MP2868A, there's more ways to do it.
I made a recent update that added power limit scaling instead of an offset, so now you can have accurate readings in HWinfo if you add the same multiplier for the sensors. With power offset you had no reported power if it was under the offset value. For example with 100W offset, any power draw under 100W shows as 0W in HWinfo.
But with scaling it shows from lowest level, no gap in reporting.
You can use any tool that fits your needs, I do not insist people use mine. If anyone else has more/better options use that, I just wanted to share the idea with everyone.
As for the other discussion, that's related to tribal politics from another forum, and there is apparently more than one person trying to pass my idea as their own, without giving me any credit for it. Strange times.
Scribd is the source for 300M+ user uploaded documents and specialty resources.
www.scribd.com
From it I was able to figure out which register offsets power for RDNA4, since VR is similar to it. That was after I figured out TBP is a composite value made up from GPU Core + SoC Input Power sensors, which was a clue the data comes from VRs, so it can be altered, when everyone was saying it cannot be done for RDNA4 because it has current measuring chips at connector, it's not VR reporting anymore.
And I was able to do that after I found MP2856 Linux kernel driver, which offered more clues + monitoring. I shared all of these resources. Even if you find some new register that does something, you wouldn't have found it without the key work I did. I had to open a few doors so you can "find" another way of doing it.
For you to find "another way" you needed me to show you how to access the VR from Linux, how to permanently save mods, full RDNA3 register list with names, which you can use as clues for other register functions that can enable power limit increase.
The registers you looked at didn't come from nowhere. Same for the full list I posted few posts back. After you see their names yes, not so hard finding something that works, if you are willing to test different values in different registers (this time you have software which shows full details on every register).
I tell you PIN_IIN_SYS_OFFSET offsets the power level, if you test IIN_CONFIG register yes, most likely you will find another way of doing it. There would be no IIN_CONFIG register for you to test if I didn't show you the whole thing, isn't it? You suddenly having an idea after I show it and explain it to you is kind of sus lol.
But finding new functions/registers/etc is fine, even building more tools is fine. But this is the second person from the same group "of friends" trying to pass my ideas as their own, without a single mention of my project, like they came up with them themselves, instead of their "ideas" being fully based on the work that I did, that is my problem. Their "ideas" wouldn't be possible without the numerous key steps I spoon fed them, based on that yes, you find "different ways".
This is not only about "I told you about i2c-tools and SMU 0 on Linux", this is about numerous key points where my work enabled the next step in the process, I built upon it for months, so in the end we have a RDNA4 solution. Then you use it to simply test a few other registers from what I worked so hard to find/figure out, and pass your findings as your own work, or even worse, repackaging my information and passing it as your EVC2 XML contribution, that is insane.
With power offset you had no reported power if it was under the offset value. For example with 100W offset, any power draw under 100W shows as 0W in HWinfo.
I increased TPB to 410W via your "rdna4.sh" script (not the one wilth "old"):
(btw, the card should have a stock TBP of 330W.)
And it confirms the offset:
But HWinfo is reading values <69W at idle, too:
I confirmed via power monitoring at the wall socket that the limit is increased, so I believe its already the "new scaling" rather than the "old offset"?
As for the other discussion, that's related to tribal politics from another forum, and there is apparently more than one person trying to pass my idea as their own, without giving me any credit for it. Strange times.
Besides that I think one should respect and give credit to other peoples work (and of course I have my own subjective opinion), I try to stay neutral as I do not have the technical knowledge to join the discussion.
But I will check out OCN, too.
I increased TPB to 410W via your "rdna4.sh" script (not the one wilth "old"): Anhang anzeigen 1178861
(btw, the card should have a stock TBP of 330W.)
And it confirms the offset: Anhang anzeigen 1178862
But HWinfo is reading values <69W at idle, too: Anhang anzeigen 1178863
I confirmed via power monitoring at the wall socket that the limit is increased, so I believe its already the "new scaling" rather than the "old offset"?
Besides that I think one should respect and give credit to other peoples work (and of course I have my own subjective opinion), I try to stay neutral as I do not have the technical knowledge to join the discussion.
But I will check out OCN, too.
If you get the latest one you can add a power scaling user preset in the script file. You can calculate the factor by dividing your wished power limit to your actual one. If you have 363W limit and want ~435W you 435/363=~1.2, so you set 1.2 as scaling factor for TBP.
You can also run it with -m and get to the menu, which is interactive. Both offset and scaling methods work fine. The offset one can be permanently saved, the scaling one cannot, it goes away on power off.
As for the other discussion yeah, I felt like I should mention the fact that at least a passing mention somewhere at the bottom would have been appropriate, even if the author doesn't like me.
Well, after the fact it's kind of hard to believe. What made you think of a register anyway? Did you have this random idea all of a sudden? Just like that? Out of nowhere, people using EVC2, and you thought
What if, I use Linux, I install I2C tools, somehow SMU 0 is accessible with no reason whatsoever for this thought I'm now having, and not only that, maybe I somehow find a full list of register names for RDNA3 VRs, and based on it I get some ideas of what other registers I could modify so I get another different way of increasing the RDNA4 power limit, which would also for some reason be fully different than the method anyone else might have come up before me.
Who has an idea like that, out of nowhere? Strange idea no? After years of no ideas, you suddenly have this idea. Somehow right after I give you a lot of details about everything. The mind boggles.
Glad I could help, enjoy it!
If anyone wants more options I would consider adding them to my script. MP2868A has a new SVI3 VID offset register, seems pretty similar in behavior to the classic VID one. Another interesting one is VID trim register, seems to exhibit slightly different behavior to VID offset, has some 63-64mV max offset, +/-. Since we now have full register details for RDNA4 we can modify almost anything.
PWM frequency can be changed, it's 560KHz/500KHz set on both VRs, at least on mine. GFX/SoC are 560KHz. Will try to go a bit up/down see what happens.
Well, after the fact it's kind of hard to believe. What made you think of a register anyway? Did you have this random idea all of a sudden? Just like that? Out of nowhere, people using EVC2, and you thought
Who has an idea like that, out of nowhere? Strange idea no? After years of no ideas, you suddenly have this idea. Somehow right after I give you a lot of details about everything. The mind boggles.
I will say again, I'm not looking for that, I was just expecting a small mention somewhere at the end, that's it. Minimum common sense, nothing else. Even if we don't get along on other things, we can avoid awkward situations like this, that is why it is the mature thing to do. But also thank you. I also hope you get what I am trying to say.
I will say again, I'm not looking for that, I was just expecting a small mention somewhere at the end, that's it. Minimum common sense, nothing else. Even if we don't get along on other things, we can avoid awkward situations like this, that is why it is the mature thing to do. But also thank you. I also hope you get what I am trying to say.
I had a look at how your version of the tool behaves and I have a few observations. After changing the power level, the tool leaves the VR in a non-ideal state. So running the tool, choosing the more power option, and quitting the tool, leaves the VR in question on page 0x02.
The proper way of doing writes to the VR memory is always ending with switching back to page 0. This can also be seen in the MP2856 Linux kernel driver:
Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.
github.com
C:
static int mp2856_probe(struct i2c_client *client)
{
struct pmbus_driver_info *info;
struct mp2856_data *data;
enum chips chip_id;
int ret;
data = devm_kzalloc(&client->dev, sizeof(struct mp2856_data),
GFP_KERNEL);
if (!data)
return -ENOMEM;
chip_id = (kernel_ulong_t)i2c_get_match_data(client);
memcpy(data->max_phases, mp2856_max_phases[chip_id],
sizeof(data->max_phases));
memcpy(&data->info, &mp2856_info, sizeof(*info));
info = &data->info;
/* Identify multiphase configuration. */
ret = mp2856_identify_multiphase_rail1(client, data);
if (ret < 0)
return ret;
if (mp2856_is_rail2_active(client)) {
ret = mp2856_identify_multiphase_rail2(client, data);
if (ret < 0)
return ret;
} else {
/* rail2 is not active */
info->pages = 1;
}
/* Obtain current sense gain of power stage. */
ret = mp2856_current_sense_gain_get(client, data);
if (ret)
return ret;
/* Identify vout format. */
ret = mp2856_identify_vout_format(client, data);
if (ret)
return ret;
/* set the device to page 0 */
i2c_smbus_write_byte_data(client, PMBUS_PAGE, 0);
return pmbus_do_probe(client, info);
}
More specifically at the end of the function:
C:
/* set the device to page 0 */
i2c_smbus_write_byte_data(client, PMBUS_PAGE, 0);
This is so other processes/tools have lower chances of writing data to the wrong page. Even if they should always switch to the correct page at first, it is ideal any process writing to VR switches back to default page 0 after it's done reading/writing.
Second observation, I didn't find the source code for this tool. Ideally everyone sees what it does. Especially since let's be real, there is not much "intellectual property" in there anyway. So best it's transparent. Binary files make sense to include libraries, but ideally you also post the source-code for your tool.
When I decided to share this project I was quite clear this is open and accessible for everyone. I am saying this for the record here, I wish you would publish the source code so everyone knows what it does.
The registers you modify are easily seen by comparing data dumps of before and after, and they are publicly accessible from the software and in the data dumps from the Youtube video I linked in this post:
@hellm Gekauft bei https://www.pccomponentes.it/ am 28. November 2025
www.hardwareluxx.de
So there are no more secrets and mystery registers to protect anyway. And it is customary to share the code for your tools on Linux, as compared to Windows. Unless you have some super secret magic sauce that does something special, it's best everyone sees your tool doesn't do anything else but what you claim it does. It also helps the community contribute or point out eventual issues that you might have missed.
edit: If you already published the source-code for it and I somehow missed it, I am sorry and please point me in the right direction by providing a link to it.
I had a look at how your version of the tool behaves and I have a few observations. After changing the power level, the tool leaves the VR in a non-ideal state. So running the tool, choosing the more power option, and quitting the tool, leaves the VR in question on page 0x02.
The proper way of doing writes to the VR memory is always ending with switching back to page 0. This can also be seen in the MP2856 Linux kernel driver:
Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.
github.com
C:
static int mp2856_probe(struct i2c_client *client)
{
struct pmbus_driver_info *info;
struct mp2856_data *data;
enum chips chip_id;
int ret;
data = devm_kzalloc(&client->dev, sizeof(struct mp2856_data),
GFP_KERNEL);
if (!data)
return -ENOMEM;
chip_id = (kernel_ulong_t)i2c_get_match_data(client);
memcpy(data->max_phases, mp2856_max_phases[chip_id],
sizeof(data->max_phases));
memcpy(&data->info, &mp2856_info, sizeof(*info));
info = &data->info;
/* Identify multiphase configuration. */
ret = mp2856_identify_multiphase_rail1(client, data);
if (ret < 0)
return ret;
if (mp2856_is_rail2_active(client)) {
ret = mp2856_identify_multiphase_rail2(client, data);
if (ret < 0)
return ret;
} else {
/* rail2 is not active */
info->pages = 1;
}
/* Obtain current sense gain of power stage. */
ret = mp2856_current_sense_gain_get(client, data);
if (ret)
return ret;
/* Identify vout format. */
ret = mp2856_identify_vout_format(client, data);
if (ret)
return ret;
/* set the device to page 0 */
i2c_smbus_write_byte_data(client, PMBUS_PAGE, 0);
return pmbus_do_probe(client, info);
}
More specifically at the end of the function:
C:
/* set the device to page 0 */
i2c_smbus_write_byte_data(client, PMBUS_PAGE, 0);
This is so other processes/tools have lower chances of writing data to the wrong page. Even if they should always switch to the correct page at first, it is ideal any process writing to VR switches back to default page 0 after it's done reading/writing.
Second observation, I didn't find the source code for this tool. Ideally everyone sees what it does. Especially since let's be real, there is not much "intellectual property" in there anyway. So best it's transparent. Binary files make sense to include libraries, but ideally you also post the source-code for your tool.
When I decided to share this project I was quite clear this is open and accessible for everyone. I am saying this for the record here, I wish you would publish the source code so everyone knows what it does.
The registers you modify are easily seen by comparing data dumps of before and after, and they are publicly accessible from the software and in the data dumps from the Youtube video I linked in this post:
@hellm Gekauft bei https://www.pccomponentes.it/ am 28. November 2025
www.hardwareluxx.de
So there are no more secrets and mystery registers to protect anyway. And it is customary to share the code for your tools on Linux, as compared to Windows. Unless you have some super secret magic sauce that does something special, it's best everyone sees your tool doesn't do anything else but what you claim it does. It also helps the community contribute or point out eventual issues that you might have missed.
edit: If you already published the source-code for it and I somehow missed it, I am sorry and please point me in the right direction by providing a link to it.
But that's not a problem. Okay, let's play it through. The worst case scenario would be if the user then set commands manually without selecting the page.
Very unlikely, but there's room for improvement. : )
But while we're at it, please revise the “Set Defaults/Reset Defaults” in your script. I lost all the offsets that the AIB had stored because of this.
But that's not a problem. Okay, let's play it through. The worst case scenario would be if the user then set commands manually without selecting the page.
Very unlikely, but there's room for improvement. : )
But while we're at it, please revise the “Set Defaults/Reset Defaults” in your script. I lost all the offsets that the AIB had stored because of this.
I recommend running the script once in this mode to check the GFX_VID. Some GPUs have a factory +5mV offset for some reason. For example, Buildzoid’s 9070 has a +5mV offset on GFX. Note this value, as you may need to add it back if you restore to factory settings after making permanent modifications. The script sets 0mV VID offsets for all four rails. Therefore, if your GPU has a factory offset, you’ll need to re-apply it to maintain the stock configuration.
I am quite clear this is your duty before saving any offset. If you ignore the instructions then it is something like this:
If it was a surprise, you didn't pay attention or you got the script from somewhere/someone else. I made sure it's known.
But I agree that it would be better if I remove this issue completely, I will try to at some point, it's better in the end for the random user.
As for your version, I didn't imply people are in risk of having their GPUs bricked by it, I was just saying it's not proper. There is danger and there is proper. You do things proper so you make sure it cannot happen under any circumstance. You do not do things "leave it like because it works like that". That is not proper.
There can be a situation where someone, especially around these parts of the OC world, uses the script for more power, then issues i2c-tools command to write another modification, something that your tool does not offer, but wants to change, doesn't pay attention and writes to page 2 instead of page 0 or 1, who knows what can happen. That is why it's best you always go back to page 0, that is proper. But again, I did not imply your tool breaks GPUs or something like that, it was a friendly recommendation based on my experience in this subject.
Edit: But if you know your factory offset value, just apply it and issue a permanent save, and it's stock condition.
I am quite clear this is your duty before saving any offset. If you ignore the instructions then it is something like this: Anhang anzeigen 1179383
If it was a surprise, you didn't pay attention or you got the script from somewhere/someone else. I made sure it's known.
But I agree that it would be better if I remove this issue completely, I will try to at some point, it's better in the end for the random user.
As for your version, I didn't imply people are in risk of having their GPUs bricked by it, I was just saying it's not proper. There is danger and there is proper. You do things proper so you make sure it cannot happen under any circumstance. You do not do things "leave it like because it works like that". That is not proper.
There can be a situation where someone, especially around these parts of the OC world, uses the script for more power, then issues i2c-tools command to write another modification, something that your tool does not offer, but wants to change, doesn't pay attention and writes to page 2 instead of page 0 or 1, who knows what can happen. That is why it's best you always go back to page 0, that is proper. But again, I did not imply your tool breaks GPUs or something like that, it was a friendly recommendation based on my experience in this subject.
Edit: But if you know your factory offset value, just apply it and issue a permanent save, and it's stock condition.
Again, I do say exactly that in the instructions, you must read the instructions before using my tool.
Note this value, as you may need to add it back if you restore to factory settings after making permanent modifications. The script sets 0mV VID offsets for all four rails.
I say specifically it writes 0 for VID on all 4 rails, when you restore to factory settings. I cannot accommodate more than English language atm, don't think I will write instructions in other languages. But I try to be clear in English at least.
Edit: From all RDNA4 reports so far, all GPUs have 0 VID set from factory on VDDCI/SoC/VRAM rails, and most have 0 on GFX as well. Some come with 5mV VID GFX offset from factory. So for most factory is 0mV. That is why I recommend noting the original GFX VID, so if you want to restore to factory, you make an extra step to add it back and permanently save it. It's pretty reasonable.
Did you lose your offset? Or do you know what offset your GPU came with? If you know you have 5mV, you didn't lose it, just add it back and do a permanent save with it applied. For me this is not complicated to understand.
Also for me VID offset is advanced use, I don't recommend beginners to add VID, just power limit increase. If you do not know what VID is you shouldn't use before doing some research. I added maximum limits to possible VID offset, in my tool, but even with safety limits you shouldn't use it if you do not understand what it is/what it does.
Beginners can use power limit increase, that is good for most cases, for gaming etc.
Again, I do say exactly that in the instructions, you must read the instructions before using my tool.
I say specifically it writes 0 for VID on all 4 rails, when you restore to factory settings. I cannot accommodate more than English language atm, don't think I will write instructions in other languages. But I try to be clear in English at least.
How do you even know this? The statement makes no sense. If you know it's lost, you know what it is, so it cannot be lost because you can permanently save the AIB offset after.
If you don't know what it is, you cannot know it's lost. Logically speaking. No?
It is like you knowingly put your keys under the mattress and complain you cannot find your keys. Weird. Even if you know you put them there.
You know who's ego is hurt, and why you claim this tool is your creation. Because he was too incapable of doing such a thing himself for years, then I come along and post this:
Seit AMD mit den Adrenalin-Treibern ab 2020 die Verwendung der SoftPowerPlayTables und damit indirekt auch des MorePowerTools massiv eingeschränkt hat, trauert die Community um den einstigen Übertaktungs-oder Untervoltungs-Bonus, der die Navi-Karten wie eine Radeon RX 5700 (XT) zumindest etwas...
www.igorslab.de
Invites me there without me knowing he's from Igor's company, then gets angry because he's too slow to come up with developments for RDNA4, I move too fast, then he starts contradicting me with inventions that have been proven false in the end, all because he was probably jelous or felt incapable or something I do not know, not my problem anyway, I solve RDNA4 power increase, besides RDNA3, and then you magically release your own script that you somehow made without help at all, no recognition on who told you how?
And you use these silly excuses with "I lost my VID offset, I do not know what it was but I know I lost it" and you took inspiration "from publicly available data"?
This is not ego, this is healthy standing up for myself when a company is trying to pass my work as their work to give value to them. I did not receive any offer to join you, I did not receive anything from you, and you take value from my work to give value to your company, and you do not even have the common sense and decency of mentioning my work for it? You take it all for yourselves? After years of your "programmers" failing to come up with RDNA3/4 hacks? You magically know how after talking to me? But it's "publicly available data"? This is not ego, this is you having no shame, and your programmer's ego who failed to come up with a solution for years, and passes my work as his work now.
This is crazy.
Seit AMD mit den Adrenalin-Treibern ab 2020 die Verwendung der SoftPowerPlayTables und damit indirekt auch des MorePowerTools massiv eingeschränkt hat, trauert die Community um den einstigen Übertaktungs-oder Untervoltungs-Bonus, der die Navi-Karten wie eine Radeon RX 5700 (XT) zumindest etwas...
www.igorslab.de
Here I explain my suspicion it's possible on RDNA4 as well. You cannot know RDNA4 power altering is even possible from VR, without my work. Most of you said it's not possible because it has current measuring chips at connector, not from VR anymore, I proved it's still posible from VR by making connections in monitoring data, that VR reported power together make up TBP value, so it's still possible.
You cannot know you can use VR registers on RDNA4 to alter data without my work. You need my idea of using i2c-tools, then you need more of my work only to know you can even alter power via VR data altering, and only then you can find "new special registers" that are different to the ones I found. You need most of my work for your tool to even work. Even if you use "a different register" for it.
Seit AMD mit den Adrenalin-Treibern ab 2020 die Verwendung der SoftPowerPlayTables und damit indirekt auch des MorePowerTools massiv eingeschränkt hat, trauert die Community um den einstigen Übertaktungs-oder Untervoltungs-Bonus, der die Navi-Karten wie eine Radeon RX 5700 (XT) zumindest etwas...
www.igorslab.de
These are key factors I discovered myself, that you now used. This was not your intellectual work, it was mine, you assisted to my work.
Seit AMD mit den Adrenalin-Treibern ab 2020 die Verwendung der SoftPowerPlayTables und damit indirekt auch des MorePowerTools massiv eingeschränkt hat, trauert die Community um den einstigen Übertaktungs-oder Untervoltungs-Bonus, der die Navi-Karten wie eine Radeon RX 5700 (XT) zumindest etwas...
www.igorslab.de
These are all things I have worked for, that you now used to pass your silly new registers as "your work", but it wouldn't be possible without my developments. You need more steps from my work to arrive at "register" discussion for RDNA4. It couldn't be done without using the information I gave you, that I worked for it, not you. You are not capable enough to make these connections, sorry I have to say it like this but this is my assessment of your skills, you are not of that caliber. You come from a time when everything was open, just use ADL/ADLX documented framework. That is fine, but do not pass my work as yours, you are not at that level, sorry but it's true.
This is not right, what you did is not correct, and it's based on the weakness of a single individual, he dragged you on this path, by doubling down on him feeling ... something. Instead of him accepting who's doing what, he started on this path, and it's bringing shame to all of your community now.
And above all, my work is now indirectly used to bring value to a company. I do not consent to this, for the record. I have received no offer, nothing in return for my work, I do not consent my work be used like this, above all without recognition, the minimum common sense.
Excuse me what? That is your error, why wouldn't you read the instructions? What a strange thing to say.
Also I still don't understand what you said. What do you mean by:
How do you even know this? The statement makes no sense. If you know it's lost, you know what it is, so it cannot be lost because you can permanently save the AIB offset after.
If you don't know what it is, you cannot know it's lost. Logically speaking. No?
It is like you knowingly put your keys under the mattress and complain you cannot find your keys. Weird. Even if you know you put them there.
I have explained myself, I won't trouble you here anymore, it was my right to present my side of the story. I wanted to explain how I see things from my perspective, just so it's clear, and also for the record.
github.com
www.hardwareluxx.de
www.igorslab.de
