[Success] AMD RX6000 Series working in macOS

[Delon2541]

That level of FPS output is about on par with what I would expect from a much older AMD dGPU (RX470/480) at High or Ultra settings in WoW.

Other than Shaneee's GPU AMD Kernel Patch are you using any other AMD related booster SSDT's, Kexts, fake ID's or boot arguments?

Are you dual booting Windows 10 or 11, have you tried playing the game in Windows to see what FPS you can achieve in WoW on Windows?

nothing like that in regards to amd booster ssdts, kexts nor fake ids. Boot argusments are just -redcode and amgmod=pikera.
I even found out about some framebuffer stuff today for 6900 cards and applied it to device properties ATY,Carswell but that didnt increased performance. All in all the card is being detected as 6900. Even saw in ioregistry that it loads 6900.kext, geekbench 5 shows 200k metal score and in wow its on 70-80fps when set to be on Metal and drops even more when I start to move. When I check activity monitor, cpu is at 270% but GPU at 6-8% like it would be doing nothing. Maybe some acceleration is not working as it should?

 

[Edhawk]

The correct boot argument is agdpmod=pikera.

Using the ATY,Carswell DeviceProperties with your RX6900 is probably the best method for configuring the card.

It sounds like the sensors are not being read correctly in your system. A CPU can’t work at 270%, that is a physical impossibility.

 

[Delon2541]

The correct boot argument is agdpmod=pikera.

Using the ATY,Carswell DeviceProperties with your RX6900 is probably the best method for configuring the card.

It sounds like the sensors are not being read correctly in your system. A CPU can’t work at 270%, that is a physical impossibility.

I see, yes I have that correctly in the config.plist just typed it from head hence the bad wording of pikera boot arg.
Should I still leave this boot arg in the config.plist when I already spoofed the device and it is being correctly recognised? Or it should always be there even after spoof.
Will try to install Big Sur today to see how it performs on that, noticed that there were some issues in Monterey 12.3
but those should be solved with the Carswell device property
Will also try to look for some sensor kexts for the amd ryzen 7 5800x

 

[Edhawk]

Yes keep the boot argument. The pikera boot argument is essential for your Navi GPU to work with macOS.

 

[c-o-pr]

The correct boot argument is agdpmod=pikera.

Using the ATY,Carswell DeviceProperties with your RX6900 is probably the best method for configuring the card.

It sounds like the sensors are not being read correctly in your system. A CPU can’t work at 270%, that is a physical impossibility.

It's a case of percents-of-what: For example, Activity Monitor can report CPU load relative to a core (not a chip or HW thread) so if you see a readout of a process using 270% that means 2.7 cores of load.

 

[Edhawk]

That is a mangled and incorrect way to use percentages.

The CPU can only provide 100% when running at it’s maximum, with all cores/threads running at 100%. So the sensor saying the CPU is working at 270% is just nonsense. If it said 2.7 cores/threads were working at 100% that would be better, or gave that as a percentage of the CPU max, i.e. on a 6-core CPU 2.7 cores would be equivalent to 45% of the CPU’s maximum output.

 

[c-o-pr]

That is a mangled and incorrect way to use percentages. The CPU can only provide 100% when running...

You are overlooking the possible meanings of the term "CPU" with respect to the unit of the measure.

What is a CPU? Is it the whole mac? A package that goes in a socket on a board? A die in a package?

Consider Activity Monitor, which regards the relative unit of measure of CPU utilization to be a core. The reason for this becomes obvious when we examine the system structure and try to define it any other way.

A core is a primary and distinct program execution device that can be scheduled to do work on behalf of a process. This makes it a natural unit convenient to the measure of processing workloads, while leaving out irrelevant packaging details of particular HW.

We can imagine that if all Macs had the same number of processors, we might normalize 100% to the Mac. But Macs have different numbers of processors, internally processes are scheduled by cores, and CPU utilization is a purely internal measure of Mac utilization, not a benchmark (by which an by which we compare different Macs).

But for the sake of argument, let's try to give your view regarding percentages the benefit of the doubt: Might we be more comfortable imposing some reference Mac (say the local Mac) as 100%?

Consider Activity Monitor as the sensor, so to speak. By definition it very usefully reports "process" activity. To be clear this is related to but not the same as "processor" activity. Processes may or may not span processors or cores. Internally there are various HW and programmatic boundaries that enable distribution of a process across multiple processing units and a program has to be specifically designed to run on multiple cores at once. Knowing such details, we can see that normalizing 100% process utilization to the totality of cores leads to confusion not clarity: The operator looking at the sensor readout, which is per-process, will need to divide the reported utilization by the total number of cores in the Mac to grok the utilization. E.g., imagine an 8-core Mac where Activity Monitor reports a process is consuming 12.5% of the CPU. Does it seem obvious to any reader of this stat that the processes is fully utilizing a core. No. Moreover, I have to communicate the per-Mac core count to allow comprehension of the stat in any other context.

Ok but just to continue for the benefit of the doubt, let's replace Activity Monitor with some other more general CPU sensor: one that just reports processor utilization per socket or die or something generic about the HW packaging. Is that helpful? Now we've decoupled the utilization measure from any comprehension of the internal programmatic details of process execution. You could convey processor utilization as momentary package power expressed as a percent of total power and just leave it up to the user to apply some enormous equation to work backwards from power consumption to a program's behavior! Does that make sense? For what purpose?

So it's truly just a matter a of percent-of-what, where normalizing "CPU" to something other than a core makes the CPU utilization report less grokkable.

 

[Edhawk]

Nice write up and good to read your thoughts on the matter. But, and there is a big but!

Since my A-Level days (early 1980's) when I studied Pure Maths, Maths & Statistics & Computer Science I have understood what Percentage means and stands for. This also includes understanding what a CPU (Central Processing Unit) is, even if they have changed dramatically since that time.

As a measure, 100% stands for the whole unit, in this case a CPU. It doesn't stand for a single core or thread, but is a measure of the Utilisation of the whole unit. As can be seen in this screenshot showing the Utilisation of the CPU in the CFL Hack I am currently using.

HWMonitorSMC2 showing 13% utilisation of the CPU.

This is a correct use of the Percentage function, where the percentage of the whole CPU in use is reported.

The person(s) who setup the monitoring kext/app or whatever @Delon2541 is using has simply set it up wrong. The developers have misconstrued the Percentage function, and obviously don't understand that the CPU cannot be utilised more than 100%. It is simply impossible.

 

[UtterDisbelief]

Nice write up and good to read your thoughts on the matter. But, and there is a big but!

Since my A-Level days (early 1980's) when I studied Pure Maths, Maths & Statistics & Computer Science I have understood what Percentage means and stands for. This also includes understanding what a CPU (Central Processing Unit) is, even if they have changed dramatically since that time.

As a measure, 100% stands for the whole unit, in this case a CPU. It doesn't stand for a single core or thread, but is a measure of the Utilisation of the whole unit. As can be seen in this screenshot showing the Utilisation of the CPU in the CFL Hack I am currently using.

View attachment 559947 HWMonitorSMC2 showing 13% utilisation of the CPU.

This is a correct use of the Percentage function, where the percentage of the whole CPU in use is reported.

The person(s) who setup the monitoring kext/app or whatever @Delon2541 is using has simply set it up wrong. The developers have misconstrued the Percentage function, and obviously don't understand that the CPU cannot be utilised more than 100%. It is simply impossible.

Hi. Don't get me started on Percentage's sibling - Percentile !!!! That one I really dislike!

 

[c-o-pr]

I agree 200%!