Contribute
Register

HP ZBOOK G5 17

I have great news, I was angry at the fact that the WX card was burning up 40W on idle and I read somewhere that using a laptop frame buffer might help, and so I tried injecting different ones, but then got a MBP15,1 ioreg and I see they use the Palena frame buffer, so I tried it and the thermals/power usage is so much better!
Now the core clock goes down to 0.2 GHz and the Ram also goes down to 0.3 GHz, and now I get < 17W on idle, and a whole hour + extra battery time!

So, just for fun I went back to the Bios and switched the laptop to Discrete Graphics mode to bench test the new frame buffer, and I saw in ioreg that the @0 LCD monitor (laptop display) now had the dpcd registers populated, so I test DRM, and lo and behold everything works!!! No more snow!!! sleep, reconnect screens, etc!!!
Itunes bought movies, safari netflix, etc...

I had to patch the other frame buffer outputs on my config file, but now all 4 output connectors work.
Internal Screen @1080p works w/hdcp
TB3 - @4k works + hdmi audio w/hdcp
DVI - @4k works + hdmi audio w/hdcp
HDMI - @4k works + hdmi audio w/hdcp

The only thing that "broke" is HVEC hardware encoding and the full LCD brightness range fix, which I'm sure I can figure out as I previously injected a range fix for the IGPU, so it's just a matter of doing the same for the GFX0 device (I hope) but in the meantime it's very usable, just doesn't dim all the way down. (fixed)

For the HVEC and IGPU for compute, I know there are Bios hacks, but this machine is very "secure" and setting or changing variables using RU, SHELL, or anything other than it's own Bios config utility has proven to be impossible.
But I have a theory that I could have the Zbook in Hybrid mode and then using an SSDT change a variable on the fly that will switch the Mux chip to the DGPU input.
I know the Zbook can do that, and I believe that's pretty much how it works on Windoze, but I don't know which variable to set and the HP people don't make it easy to understand their DSDT/SSDT's
 
Last edited:
The thing with trying to switch graphics is that you either need some way to keep both enabled at the same time (which uses more battery power), or somehow tap into and use whatever stack that apple has to switch on/off the dedicated graphics, which is much more difficult. Might be able to do something with Lilu and patching, but that'd be a pretty impressive feat.

That said, I don't think that many people have looked at it since most laptops don't have physical muxes (instead opting to use optimus and copying data over PCIe). You may be able to find out more about this with time put into it, as I don't actually know too much about what would be involved.

I would look into it, but my iGPU in my M4700 can't actually push to any displays, so I'm forced to use the dGPU all the time.
 
Yeah, this Laptop is a unicorn in the mux department, the problem I found before is that on hybrid mode IGPU is primary and there's no way to change that, so the LCD always gets signal from IGPU and there's a few drawbacks to that.
- No HDCP handshake, so no DRM, and that's a whatevergreen side effect. (even though my IGPU can host apple's firmware and can use the amd card for hw decoding)
- For GPU intensive apps, if they are not coded to specifically look for another dGPU, they use the IGPU and the performance sucks.

So before this new find, I turned off metal support for the IGPU and then the AMD card did all the heavy lifting, but at a performance premium ~20% less than in dedicated mode.

And like you mention, more battery draw

In the past when I was playing with a ZBook G2 (same muxing beast, with less whitelisting MXM cards!) I created some SSDT's to try to do this switch and I managed to switch the device, but it always resulted in a hard reboot.
And this G5 version is a lot more complex in the switching department. From what I can see in the SDDT, HP turns off devices that are not needed to save power and OSX doesn't like that. But the trick may be to keep the variable that defines the power state to on, while changing the variable that triggers the GPE switch, or something...
 

Attachments

  • ACPI Files.zip
    64.4 KB · Views: 52
Last edited:
i was recently working on some more basic stuff with G3s running quadro m2000m, hybrid mode where High Sierra sees both gpus and the internal is driven by the hd630 and externals by m2000m - i enabled dgpu agpm with the proper kext and all, but this is all some serious **** you are working on there!
I was also under the impression that whatevegreen patching is not so precise as specifing the framebuffer can lead to massive perf and power saving improvements, i wonder why there is not more looking into iteven in the desktop space (radeonboost is probably related?)
 
WhenMusicAttacks said:
radeonboost
Click to expand...

That info.kext pretty much just sets a PowerPlay profile and sets the CFG_FORCE_MAX_DPS flag to True and reduces the life of your card dramatically!

What I see different in the Palena FB is the PP (PowerPlay) settings are tweaked, the clocks are tweaked and the connectors are different, but also it shows up as "AMD Radeon RX Baffin Mobile GL XT Prototype" in Activity Monitor, so there may be more going on under the hood.

Also on other not so good news, a few weeks ago I was having trouble with some windows update stuff and I installed the latest Bios, and now I can't go back! I lost the ability to undervolt and while the new quiet fan profile is great for acoustics, it is terrible for temperatures, so after a bit of back and forth with HP support, turns out I'm stuck, so I fixed the thermals by using liquid metal (scary stuff, but amazing! ~ -20C difference!!) and now I have a quiet and cool (but not quite the same great performer as it used to be ~ -220 points Cinebench CPU)
In the new Bios the battery stuff changed (HP added extended battery info BIX) so my old EFI folder no longer worked, and I also noticed I had a few bugs on the old one (For example if you sleep the laptop, unplug the AC and wake, the status doesn't change until you re-plug ac) and now it's fixed, but for the new Bios.
Also tweaked a bunch of other things, got rid of device HPET as it is not used by Macbooks anyways, etc... I basically copied everything except the ALS0 and MUX devices of a MBPro, and I hard coded the keyboard shortcuts on an SSDT so we can update voodoops2keyboard and the shortcuts stay, added some missing I2C methods to help with trackpad, etc...

I want to see if I can get the last couple of things sorted and this will be a better-than-mac...mac

Still missing:
-Ambient Light Sensor (not really a priority)
-Alps Trackpad Buttons and trackstick (hopefully @1Revenger1 can help)
(VoodooI2C works well but the buttons and trackstick don't work)
-Debug the "Audio Codec / Battery EC0 query mutes speaker using AppleALC CX8400 codec problem."
-Enable headless mode IGPU for IQS (Intel Quick Sync)
-802.11ac wifi (OpenIntelWireless works great ATM with 300mb up/dwn 802.11n only)
-Catalina + WX-4170 Support (something in the AMD driver (and my suspect is the frame buffer) changed and it stalls after handoff) more info on this post https://www.tonymacx86.com/threads/amd-wx4170-dgpu-on-zbook-g5-17-laptop.310950/#post-2233228

Everything else works!

(just fixed the brightness range issue)

Just FWIW, My attached/working EFI is not the most up to date OpenCore but it works.

Current EFI - https://www.tonymacx86.com/threads/hp-zbook-g5-17.266012/post-2158182
 
Last edited:
1Revenger1 said:
A github issue (with log attached) is going to be the easiest way to help with that. I believe that `log show --last boot | grep -i Voodoo` should work?
Click to expand...

I submitted a github issue to your VoodooPS2-Alps Repo, with the current "working" voodooi2c+HID logs.

Thanks for the help!
 
Last edited:
I think you might be confusing it slightly.
VoodooSMBus isn't a replacement for VoodooI2C. There are trackpads which work over I2C, and those which work over SMBus. SMBus is technically a derivative of I2C, but that doesn't mean that the hardware controllers which we interact with to send those packets are similar. Also, the trackpads tend to only be connected to one of those controllers.

Unfortunately I don't know too much about the I2C front, may be that there is some additional code that would need to be written - I'd maybe write to those guys in a github issue. Generally, the trackpad works over PS2 OR I2C, but not both at the same time, so it's likely an issue they'd need to solve.

I'll respond to the PS2 stuff on the github issue you posted. Even if the optimal solution likely is to use I2C, I'd like to know why the PS2 version doesn't work.
 
1Revenger1 said:
I think you might be confusing it slightly.
VoodooSMBus isn't a replacement for VoodooI2C. There are trackpads which work over I2C, and those which work over SMBus. SMBus is technically a derivative of I2C, but that doesn't mean that the hardware controllers which we interact with to send those packets are similar. Also, the trackpads tend to only be connected to one of those controllers.

Unfortunately I don't know too much about the I2C front, may be that there is some additional code that would need to be written - I'd maybe write to those guys in a github issue. Generally, the trackpad works over PS2 OR I2C, but not both at the same time, so it's likely an issue they'd need to solve.

I'll respond to the PS2 stuff on the github issue you posted. Even if the optimal solution likely is to use I2C, I'd like to know why the PS2 version doesn't work.
Click to expand...

From what I gather from the VoodooI2C devs, is that their goal is the trackpad itself, not the buttons, not the trackstick, so for using I2C we would need to use VoodooInput and add the buttons to their HID satelite or another option would be to port the Alps I2C drivers as a separate satelite and then incorporate the buttons+Trackstick.

Both of these options are beyond my current abilities
 
Fixed the problem below by using default framebuffer and injecting the ATY,Acre properties using a custom PolarisZbook_WX4170.kext.

we now have proper Power Management

Spoke too soon, there is a catch! (always a @@@!!! catch)

In discrete mode, everything was perfect, then the laptop goes to sleep, when it comes back, everything seems perfect, but there's a time bomb ticking, I believe something doesn't quite reset properly on the EC/MUX/WX so that after a couple hours, I get a weird freeze out of the blue. Applications appear to still be working, but the window server seems to have crashed. I can move the pointer, go back to sleep, wake, and there's sound, but the display is frozen, can't drag windows, I can login on a different machine using display-sharing, but to a black screen, and can't force quit apps, can't switch apps, can't see the top menu, can't shutdown. So after a hard reset, I get a brand new Yellow Screen after the apple logo disappears during boot, and basically same symptoms as before but instead of my previous state working window, I get Yellow. Everything underneath seems to be "working" but the window server is definitely crashed.

To get my machine back from this I perform a EC controller reset (hold power button for 20 sec.) and everything back to normal like nothing happened.

This has happened twice already and I think only after waking from sleep, otherwise seems to be pretty stable, so I'll keep digging to see if this is truly only happening because of a bad wake-up.

-----

Also tried going back to my IGPU as primary w/metal off, and DGPU for compute "hack-mode" but using the PALENA Frame Buffer for the WX card, and I'm getting horrible performance on the internal screen, (not so bad on external screens) and just by looking at the HWMonitor clocks, it looks like the WX core clock want's to be as low as it can if there's no display attached (makes sense) so if I'm using the IGPU for the internal display, then the WX is throttling from 1.2 to .2 GHz even under full 3D load, and causing a hiccups like effect.
On the external display though, It's keeping the clock high under load, so I guess one of Whatevergreen's side-effects of keeping the clock high and burning watts on iddle, kept performance high in my hack-mode, but using a power efficient framebuffer in this "mode" is a no-go!
(The CPU temp is also +3C hotter on idle in this "mode", So I guess IGPU also burning some extra watts!)
 
Last edited:
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top