Contribute
Register

IGPU shows 7Gb of VRAM

Status
Not open for further replies.
@iLikeHackintosh,

Biggest issue I can see is that you are not using a Headless FrameBuffer, so MacOS is creating display/connector frame Buffers attached to the driver (identified below between the two red lines) which are causing assertions as they attempt to attach to monitors that are not there as you can see below.

Screenshot 2019-12-15 at 17.23.15.png
You can see the assertions as multiple entries against the Intel Accelerator which are timing out (the entires in red)

This is what a properly configured headless IGPU looks like on my system, as you can see only the driver is attached, there are no display or connector frame buffers.

Screenshot 2019-12-15 at 17.35.12.png

When using a iMac SMBIOS with a dGPU then the IGPU must be configured as Headless.

Cheers
Jay
 

Thank you @jaymonkey!

If you follow my posts, then you can see, that headeless or not, the memory size value is worng on any case.

I switched AMD off and switched to the Intel graphics only. Thats where I figured out the that the reading is wrong. Headless configuration has nothing do to with this value.

Also, another user has VirtualSMC in use and he has the same issue:

Seems that this 7GB is 100% bug as it occurs on other comps too:

#10,226
 
Actually issue solved. As my system has a lot of RAM, 64GB, it shares a total of 7,5 GB for the AGP memory as fa I understand now. That’s from were the confusion comes.

 
Last edited:
Thanks for doing those tests and reporting your findings ......
I think we all agree that it's very strange your IGPU is showing 7GB VRAM available, its a first as far as I know.

The only BIOS setting that can impact a working IGPU in MacOS is the DVMT-Pre-Allocated setting. MacOS expects it to be at least 64MB but depending on the CPU generation it will generally work better if set to more such as 128MB or 256MB.

Hi @jaymonkey

After digging deeper I can confirm that on original iMac has more than 2GB of shared memory!!

"gartSizeBytes"=4294967296

Please see an attached file ;)

Also accordign to Apple's documentation shared memory can be up to 8GB. So the 7.5GB of shared memory on my system should be correct actually.

I have updated my related build page too:

 

Attachments

  • IOReg-iMac19.1.zip
    191.9 KB · Views: 59
Last edited:
Also accordign to Apple's documentation shared memory can be up to 8GB. So the 7.5GB of shared memory on my system should be correct actually.


@iLikeHackintosh,

I have not seen that document before .... interesting find, as you say to does seem that some newer iMacs can indeed use more than 2GB of VRAM for the IGPU so i stand corrected.

Thinking about it there are a few Mac devices like the iMac16,1 and iMac18,1 that have a retina display and only have a IGPU as the primary display adapter, (no AMD dGPU) so it would make sense that these would have more then 2GB of VRAM in order to drive all those pixels.

However on iMacs that have the IGPU configured as headless (IE: any iMac that has a AMD dGPU) there is no need for much (if any) VRAM, MacOS only uses a few select features of the IGPU when configured as headless and these all tend to be stream based features such as video/jpg Encode/Decode, Airplay, SideCar .. etc ... data is streamed into a small buffer, processed by the IGPU and then returned back to the calling process. There is no need for a large amount of VRAM as there are no physical display connectors so no need for Video RAM for pixel/texture mapping.

In all my testing i've never seen a headless IGPU use very much memory (maybe 300mb at most), however i did that testing a few years back when i initially wrote the guide, I'll try and find time over the holidays to do some more research and testing to see if anything has changed.

Cheers
Jay
 
@iLikeHackintosh,

I have not seen that document before .... interesting find..

@jaymonkey, for first I have to underline, there nothing personal here, my intention wasn't to proof you are wrong! Instead I wanted figure out why and what causes this ~7GB. It's all for the good of Hackintosh community, so we can build better hacks. New hardware is more and more power, which brings also new horizons.

Please note also that responsible for these readings are Open GL/Metal drivers shipped with the OS. Seems that Apple has changed the way it uses memory for graphics.

Also it's worth of mentioning that on Coffee Lake systems Apple uses these kexts:
  • AppleIntelCFLGraphicsFramebuffer.kext
  • AppleIntelKBLGraphicsMTLDriver.kext
  • AppleIntelKBLGraphicsGLDriver.kext
 
Last edited:
I have to underline, there nothing personal here, my intention wasn't to proof you are wrong! Instead I wanted figure out why and what causes this ~7GB.


@iLikeHackintosh,

No need to apologies, nothing taken personally.

As i said it's been a few years since i did a deep dive into IGPU use on MacOS, and I too would like to understand why your system reports 7GB VRAM.

I could understand it if you where using a iMac SMBIOS that only has IGPU and a non Headless PlatfromID.

But if your using a SMBIOS that has AMD GPU as primary and the IGPU configured as headless then the 7GB VRAM makes no sense what so ever as it would never be used.

Cheers
Jay
 
@iLikeHackintosh,

One possible explanation is that HWMonitorSMC2 is reporting the maximum amount of possible VRAM that could be allocated to the IGPU if it was being used to drive a display rather than the actual amount of VRAM allocated which would normally be 1.5GB (or 2GB if using the 2048MB VRAM patch).

I take it is only HWMonitorSMC2 that is reporting the 7GB ?

Cheers
Jay
 
But if your using a SMBIOS that has AMD GPU as primary and the IGPU configured as headless then the 7GB VRAM makes no sense what so ever as it would never be used.

I suppose thats totally differently allocated. Please note that new Mac Pro can have up to 768GB of memory and supports this Apple Afterburner card, which supports up to 6 streams of 8K ProRes RAW video at 30 fps. This kind of setup requires a lot of shared memory. I bet that Apple has changed a lot there how shared memory is initialised and used. This 7.5GB shown on my system is for sure just a maximum where my system is allowed to go, not actually allocated memory area. It will depend at workload as I understand.
 
I take it is only HWMonitorSMC2 that is reporting the 7GB ?

It has nothing to do with HWMonitorSMC2 as it reads only data provided by OS itself. Please note also that responsible for generating these readings are Open GL/Metal drivers shipped with the OS, not HWMonitorSMC2!!
 
Status
Not open for further replies.
Back
Top