Jump to content

2,089 posts in this topic

Recommended Posts

Thats my terminaloutput:

 

DEVICE 0:
    Name: AMD Radeon RX 480
    Metal version: 2+
    Registry ID: 0x4E6
    Max Threads Per Thread group: MTLSize(width: 1024, height: 1024, depth: 1024)
    Max Thread group Memory Length: 32768
    Recommended Max Working Set Size: 0x0
    Depth 24 Stencil 8 Pixel Format Supported: true
    Programmable Sample Positions Supported: true
    Read-Write Texture Support: MTLReadWriteTextureTier
    Headless: false
    Is Low Power: false
    Removable: false

 

Made with Sapphire RADEON RX480 Nitro OC

Share this post


Link to post
Share on other sites
Advertisement
8 minutes ago, Mork vom Ork said:

YES, it is.

Good.

I'm going to implement this code

EDIT

After your edit the name is not exactly the same Lol (AMD Radeon RX 480)

Edited by vector sigma

Share this post


Link to post
Share on other sites

DEVICE 0:

Name: Intel Iris Pro Graphics

Metal version: 2+

Registry ID: 0x3D5

Max Threads Per Thread group: MTLSize(width: 512, height: 512, depth: 512)

Max Thread group Memory Length: 32768

Recommended Max Working Set Size: 0x60000000

Depth 24 Stencil 8 Pixel Format Supported: false

Programmable Sample Positions Supported: true

Read-Write Texture Support: MTLReadWriteTextureTier

Headless: false

Is Low Power: true

Removable: false

 

 

Intel HD Graphics 4400:

 

  Chipset Model: Intel HD Graphics 4400

  Type: GPU

  Bus: Built-In

  VRAM (Dynamic, Max): 1536 MB

  Vendor: Intel

  Device ID: 0x0412

  Revision ID: 0x0009

  Metal: Supported, feature set macOS GPUFamily1 v3

Share this post


Link to post
Share on other sites
16 hours ago, vector sigma said:

 

Slice's use a fake and really its card doesn't support metal, as well for the Alpha22's "MSI VN240GT-MD1G" (NVidia GT 240). I can keep this as a success?

To me return this:


DEVICE 0:
	Name: Intel HD Graphics 4000
	Metal version: 2+
	Registry ID: 0x3BF
	Max Threads Per Thread group: MTLSize(width: 512, height: 512, depth: 512)
	Max Thread group Memory Length: 32768
	Recommended Max Working Set Size: 0x60000000
	Depth 24 Stencil 8 Pixel Format Supported: false
	Programmable Sample Positions Supported: true
	Read-Write Texture Support: MTLReadWriteTextureTier
	Headless: false
	Is Low Power: true
	Removable: false

Any supported card to test with?

this is the code:


import Foundation
import Metal

if #available(OSX 10.11, *) {
  let metal = MTLCopyAllDevices()
  if metal.count > 0 {
    for i in 0..<metal.count {
      print("DEVICE \(i):")
      print("\tName: \(metal[i].name)")
      if #available(OSX 10.13, *) {
        print("\tMetal version: 2+")
        print("\tRegistry ID: \(String(format: "0x%X", metal[i].registryID))")
      } else {
        print("\tMetal version: 1")
      }
      print("\tMax Threads Per Thread group: \(metal[i].maxThreadsPerThreadgroup)")
      if #available(OSX 10.13, *) {
        print("\tMax Thread group Memory Length: \(metal[i].maxThreadgroupMemoryLength)")
      }
      if #available(OSX 10.12, *) {
        print("\tRecommended Max Working Set Size: \(String(format: "0x%X", metal[i].recommendedMaxWorkingSetSize))")
      }
      print("\tDepth 24 Stencil 8 Pixel Format Supported: \(metal[i].isDepth24Stencil8PixelFormatSupported)")
      if #available(OSX 10.13, *) {
        print("\tProgrammable Sample Positions Supported: \(metal[i].areProgrammableSamplePositionsSupported)")
      }
      if #available(OSX 10.13, *) {
        print("\tRead-Write Texture Support: \(metal[i].readWriteTextureSupport)")
      }
      print("\tHeadless: \(metal[i].isHeadless)")
      print("\tIs Low Power: \(metal[i].isLowPower)")
      if #available(OSX 10.13, *) {
        print("\tRemovable: \(metal[i].isRemovable)\n")
      } else {
        // Fallback on earlier versions
      }
    }
  } else {
    print("no devices found that support Metal")
  }
} else {
  print("This OS doesn't support Metal, 10.11 + required!")
}

 

Yes, success. With Intel HD4000 I have same result as you.

Share this post


Link to post
Share on other sites
8 hours ago, bronxteck said:

DEVICE 0:

Name: Intel Iris Pro Graphics

Metal version: 2+

Registry ID: 0x3D5

Max Threads Per Thread group: MTLSize(width: 512, height: 512, depth: 512)

Max Thread group Memory Length: 32768

Recommended Max Working Set Size: 0x60000000

Depth 24 Stencil 8 Pixel Format Supported: false

Programmable Sample Positions Supported: true

Read-Write Texture Support: MTLReadWriteTextureTier

Headless: false

Is Low Power: true

Removable: false

 

 

Intel HD Graphics 4400:

 

  Chipset Model: Intel HD Graphics 4400

  Type: GPU

  Bus: Built-In

  VRAM (Dynamic, Max): 1536 MB

  Vendor: Intel

  Device ID: 0x0412

  Revision ID: 0x0009

  Metal: Supported, feature set macOS GPUFamily1 v3

Another problem: the "registryID" property of Metal framenwork is only available in 10.13, and for what I saw from your log above names mismatch:

Intel Iris Pro Graphics vs Intel HD Graphics 4400

This way..... I can't be sure if listed card are the same. Solutions:

 

  1. Print this only in 10.13 +
  2. Print this as a separate log, so not among existing GPU information.

 

please, vote ..(or give a better solution).

Share this post


Link to post
Share on other sites

ciao vector e' un po' che non ci si sente :)

 

 

NVARCH =GP100  value(where come from?)

 

 

HWMonitorSMC2 v2.1.4 GM

VIDEO CARD 1:
	Model:				NVIDIA TITAN Xp COLLECTORS EDITION
	Vendor ID:				de 10 00 00 (NVidia)
	Device ID:				02 1b 00 00
	Revision ID:			a1 00 00 00
	Subsystem Vendor ID:		de 10 00 00
	Subsystem ID:			10 00 00 00
	class-code:				00 00 03 00
	IOName:				display
	pcidebug:				1:0:0
	built-in:				00
	compatible:			pci10de,123epci10de,1b02pciclass,030000GFX0
	acpi-path:				IOACPIPlane:/_SB/PCI0@0/BR3A@30000/GFX0@0
	hda-gfx:				onboard-2
	rm_board_number:		00 00 00 00
	NVDA,noEFI:			true
	NVArch:					GP100
	rom-revision:				VBIOS 86.02.4c.00.01
	NVCLASS:				NVDA
	NVCAP			05 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 0e 00 00 00 00
	pci-aspm-default:				0x0
	VRAM,totalMB			ff 2f 00 00
	device_type:			NVDA,Parent
	NVDA,accel-loaded		01 00 00 00
	vbios-revision			01 00 4c 02 86
	vNVDA,Features			00 08 00 00
	IONVRAMProperty			true
	NVDAinitgl_created		yes
	IOPCIMSIMode			true
	NVDAType				Web
	Additional Properties:
		AAPL,slot-name:  	PCI Slot-1
		AAPL,ndrv-dev:   	1

my GFX chipset is GP102

https://videocardz.net/gpu/nvidia-gp102/

 

Edited by fabiosun
some adjustment

Share this post


Link to post
Share on other sites
6 hours ago, vector sigma said:
  • Print this only in 10.13 +
  • Print this as a separate log, so not among existing GPU information.

that was from 10.13.5 beta the machine is a haswell HD4400. i have to use rehabman fakepcid and lilu with intelgraphics fixup. i do not know where iris pro is being generated from i also have only inject intel true in clover config no other graphics info in clover.

Share this post


Link to post
Share on other sites
6 hours ago, vector sigma said:

Another problem: the "registryID" property of Metal framenwork is only available in 10.13, and for what I saw from your log above names mismatch:

Intel Iris Pro Graphics vs Intel HD Graphics 4400

This way..... I can't be sure if listed card are the same. Solutions:

 

  1. Print this only in 10.13 +
  2. Print this as a separate log, so not among existing GPU information.

 

please, vote ..(or give a better solution).

 Print only in 10.13+ because older systems don't use metal.

Share this post


Link to post
Share on other sites
27 minutes ago, bronxteck said:

i also have only inject intel true in clover config no other graphics info in clover.

8086 0412 is an HD4600, so that you are deceiving the OS since your is an unsupported HD4400

 

27 minutes ago, bronxteck said:

i do not know where iris pro is being generated from

Metal.framenwork is an Apple API, the name comes from Apple! Unfortunately this is the result of your hacking....

7 minutes ago, Slice said:

 Print only in 10.13+ because older systems don't use metal.

ok then.

Edited by vector sigma
spelling

Share this post


Link to post
Share on other sites
1 hour ago, vector sigma said:

Hi fabiosun, GP100 comes from your ioreg (is your ioreg):

GP100.thumb.png.4823fe3026a7f0080625f0eaacc75611.png

.. but don't tell me why.

 

 

Ok 

Maybe I know why

I thought you read data directly from GFX instead of using ioreg which is probably wrong due data passed by Nvidia driver..which supports GP102 but maybe named it GP100

Thank you for your answer and efforts

 

Share this post


Link to post
Share on other sites

I thought about answering a question I saw in my inbox, but it's not here :shock:....

Ok,

@Slice and all, rev 142 contains a modification made by Slice in (r141) where He added a new Nuvoton chip (NTC 6681) in W836x.kext, in HWMonitorSMC2.app I added the ability to read Metal abilities and the Performances Statistics of the GPU(s).

Metal stuff is printed only in 10.13 due to the fact that only in the last OS (so starting from High Sierra) is present the registry ID that allow me to ensure that the log print properties for the same GPU and its accelerator since the card name is not enough as demostrated here in the above posts.

 

All is committed but attached you can find my compilation. Should be intresting for me to see a log from NVidia and AMD cards.

 

 

HWSensors-3_r142.dmg

 

Edited by vector sigma
typo

Share this post


Link to post
Share on other sites

@ vector sigma

Yes I remove the message because I'm wrong, I have a patch DSDT for the Fan

Edited by chris1111

Share this post


Link to post
Share on other sites
4 minutes ago, chris1111 said:

Yes I remove the message because I'm wrong, I have a patch DSDT for the Fan

You can customize ACPIMonitor.kext->Contents->Info.plist->IOKitPersonalities->ACPI Monitoring Plugin to show what have you done with your ACPI tables.. Anyway I've not even tried this my self :D

Edited by vector sigma

Share this post


Link to post
Share on other sites
1 minute ago, vector sigma said:

You can customize ACPIMonitor.kext->Contents->Info.plist->IOKitPersonalities->ACPI Monitoring Plugin to show what have you done with your ACPI tables.. Anyway I've not even tried this my self :D

I will try and report

thank you

Share this post


Link to post
Share on other sites

Ok @vector sigma as you told me to post here. today i wanted to test your HWsensor and download DMG file and from extension folder i copy and paste these kext to my EFI/Clover/Kext/other folder : ACPIMonitor.kext - F718x.kext - FakeSMC.kext - GeforceSensor.kext - IntelCPUMonitor.kext - ITEIT87x.kext - NVClockX.kext - PC8739x.kext - W836x.kext - X3100.kext 

And reboot the system but when the loading screen comes up its restart - I go with -v for boot and when i try to see whats cause it it restart again very fast.

 

My hack is :

z97x-u3d-bk 

cpu : i5 4th gen

macOS : 10.13.4

32 gb RAM

clover 4449

GPU ASUS GT 640 2GB

 

I use hwsensor 6.14 right now

Edited by arminmacx

Share this post


Link to post
Share on other sites
12 minutes ago, arminmacx said:

Ok @vector sigma as you told me to post here. today i wanted to test your HWsensor and download DMG file and from extension folder i copy and paste these kext to my EFI/Clover/Kext/other folder : ACPIMonitor.kext - F718x.kext - FakeSMC.kext - GeforceSensor.kext - IntelCPUMonitor.kext - ITEIT87x.kext - NVClockX.kext - PC8739x.kext - W836x.kext - X3100.kext 

And reboot the system but when the loading screen comes up its restart - I go with -v for boot and when i try to see whats cause it it restart again very fast.

 

My hack is :

z98x-ud3h-bk 

cpu : i5 4th gen

macOS : 10.13.4

32 gb RAM

clover 4449

 

I use hwsensor 6.14 right now

You should not install every kexts Lol.

Example:

NVClockX.kext conflict with GeforceSensor.kext (they are for different classes of the NVidia cards)

You have an i5, so surely you don't have the Intel X3100 (so why installing the X3100.kext ?)

Or you have an ITEI87x chip, or Windbond836x or else (so why installing PC8739x.kext - W836x.kext - ITEIT87x.kex at same time???)

ACPIMonitor.kext  is only for who have edited its DSDT/SSDT to work with and is not an easy task.

 

Is normal that you have kernel panics, cannot be otherwise. So I suggest to use the FakeSMC.kext provided (but please don't mix stuff that comes with other projects) and install only PlugIns for your motherboard!

 

P.S. In the Download section were available also the .pkg where is clear what all kexts are for.

Edited by vector sigma

Share this post


Link to post
Share on other sites
18 minutes ago, vector sigma said:

You should not install every kexts Lol.

Example:

NVClockX.kext conflict with GeforceSensor.kext (they are for different classes of the NVidia cards)

You have an i5, so surely you don't have the Intel X3100 (so why installing the X3100.kext ?)

Or you have an ITEI87x chip, or Windbond836x or else (so why installing PC8739x.kext - W836x.kext - ITEIT87x.kex at same time???)

ACPIMonitor.kext  is only for who have edited its DSDT/SSDT to work with and is not an easy task.

 

Is normal that you have kernel panics, cannot be otherwise. So I suggest to use the FakeSMC.kext provided (but please don't mix stuff that comes with other projects) and install only PlugIns for your motherboard!

 

P.S. In the Download section were available also the .pkg where is clear what all kexts are for.

thanks for clarify it. as i have DSDT i use APCIMonitor and i didnt know X3100 is not needed and nvCLOCKX is conflicting with geforce. 

so i only need geforce.kext - fakesmc - Intelcpu.kext - apci.kext - ITEIT87x.kext (my mobo is gigabyte) right?

do i need PC8739x.kext too

 

BTW as im always use hwsensor 6.14 and always use dmg and never had problem i thought its like that and i just exclude AMD kexts

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By kevin_1351
      tl;dr: VirtualSMC causes me a flood of log messages and correlated cpu spikes. FakeSMC doesn't.
       
      Hi, I have almost finalized my Huawei Matebook X Pro Opencore setup and everything is working very well besides wifi/bt ofc (which is about to change).
       
      However, I noticed how the cpu usage sometimes went up a little and when looking at the Console I could see a never-ending flood of:
      default 14:05:05.983292+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:05.982975+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:05.982996+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.985932+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.985949+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.986134+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:39.426574+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:39.426729+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:39.426585+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431085+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431097+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431246+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:42.433068+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:42.433227+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:42.433078+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434453+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434465+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434622+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:44.436155+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:44.436166+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0  
      As you can see, multiple of these per second. Another guy with the same computer is also having this issue and posted a dsdt change to fix it. This fix didn't solve anything though
      He tried to limit the Notify call by implementing a state change requirement before calling Notify.
       
      Here is the original acpi:
      Scope (_SB) { Device (LID) { Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Method (_LID, 0, NotSerialized) // _LID: Lid Status { Local0 = One Local0 = ^^PCI0.LPCB.EC0.RPIN (0x05, 0x06) If ((Local0 == 0x55)) { Local0 = Zero } Else { Local0 = One } ^^PCI0.GFX0.CLID = Local0 Return (Local0) } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0B) } } } Scope (_SB.PCI0.LPCB.EC0) { Method (_Q81, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF { Local0 = ^^^^LID._LID () If ((Local0 == Zero)) { ADBG ("LID-OFF") SGOV (0x02030009, Zero) SGOV (0x02060000, Zero) } Else { ADBG ("LID-ON") SGOV (0x02030009, One) SGOV (0x02060000, One) Notify (ALSD, 0x80) // Status Change } Notify (LID, 0x80) // Status Change } } Which he changed to: 
      Scope (_SB) { Device (LID) { Name (_OLD, One) // assuming everything else.. the lid should start open? Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Method (_LID, 0, NotSerialized) // _LID: Lid Status { Local0 = One Local0 = ^^PCI0.LPCB.EC0.RPIN (0x05, 0x06) If ((Local0 == 0x55)) { Local0 = Zero } Else { Local0 = One } Return (Local0) } } Device (PNLF) { Name (_HID, EisaId ("APP0002")) // _HID: Hardware ID Name (_CID, "backlight") // _CID: Compatible ID Name (_UID, 0x0A) // _UID: Unique ID Name (_STA, 0x0B) // _STA: Status } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0B) } } } Scope (_SB.PCI0.LPCB.EC0) { Method (_Q81, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF { Local0 = ^^^^LID._LID () If ((Local0 == Zero)) { ADBG ("LID-OFF") SGOV (0x02030009, Zero) SGOV (0x02060000, Zero) } Else { ADBG ("LID-ON") SGOV (0x02030009, One) SGOV (0x02060000, One) Notify (ALSD, 0x80) // Status Change } If ((^^^^LID._OLD != Local0)) { Notify (LID, 0x80) // Status Change ^^^^LID._OLD = Local0 } } } Besides me not seeing any reason to declare _OLD in LID. The idea itself shouldn't be too bad right? Well, as I said, his fix didn't work.
       
      In fact, to prove that Method _Q81 doesn't have anything to do with the issue at all, I created a Clover/Opencore patch to change _Q81 to XQ81. This resulted in my lid not working at all of course, but the log flooding still persisted!
      So _Q81 doesn't have anything to do with the issue afaik.
       
      Now, further Google searches led me to a chinese post where he tied the issue to VirtualSMC. And indeed, by migrating to FakeSMC the issue is no more.
       
      Unfortunately, I'm very fond of VirtualSMC for various reasons. So I would very much like to keep it. If not I'd have to implement the old way of doing Battery monitoring etcetc. Which isn't very elegant and update proof as it requires DSDT patching.
       
      So, I do believe that the issue may very well be in the DSDT code, perhaps in the ambient light part. I'm not very skilled at this and just started studying the ACPI spec 3 days ago.
       
      Could someone please help me out? Thanks a lot in advance
       
       
      origin.zip
      OC.zip
    • By Slice
      Guys,
      Don't mix 6.18 and 3.41.
       
      There are three different projects for monitoring temperatures, voltages, fans speed and other hardware parameters:
      Initially it was FakeSMC with plugins for producing SMC keys for hardware parameters for different hardware. But sometimes ago Kozlek separated own version of FakeSMC and producing new set of plugins while I stay with good working version 3. So..
      1. FakeSMC v3 with Hardware Sensors3  which I still supported.
      2. FakeSMC v6 (rev1800) by Kozlek and supported by Rehabman. AFAIK both are abandoned and the project is not supported. Or may be maintained by coauthors.
      3. New VirtualSMC by vit9696 with own set of sensors kexts. It depends on Lilu.kext. The project is in active development.
      All three project have incompatible interfaces sensors<->SMC so they are incompatible with each other.
       
      There are applications for monitoring hardware parameters and they commonly depends on these projects.
      1. iStat, iStatMenu, iStatPro compatible with real Macs because they use SMC keys just like those presents in real Macs.
      2. HWMonitorSMC by Navi (initial codes from Kozlek)  used in my HWSensors3.
      3. HWMonitor by Kozlek with graphics like in IntelPowerGadget used in his HWSensors version.
      4. HWMonitorSMC2 by Vector_Sigma tends to be universal supporting all project. It also may use sensors information produces by Apple graphics and by IntelPowerGadget.
       
      Let us discuss here differences and common ideas for this projects.
       
×