Is the XE GPU in the 358H limited to 1850mhz?

[Mark_Hall]

Core Ultra X7 358H, the GPU won’t go over 1850mhz, but I thought the limit was supposed to be 2500mhz.

Framework Laptop 13, Core Ultra X7 358H, BIOS 03.02, EC sakura-3.0.2,
Ubuntu 24.04, kernel 7.0.0-31-generic, mesa 26.2.3 (PPA kisak) GuC 70.55.3 (ptl_guc_70.bin).

On tile0/gt0/freq0, rp0_freq, rpa_freq and
max_freq all read 2500. rpe_freq is 900, rpn_freq 100, but on monitoring it rarely goes above 1850 even with heavy load (Cyberpunk 2077) - the highest value I’ve seen is 1950mhz

It isn’t thermal, it isn’t PL1, it isn’t a missing DVFS request as writing 2500 to gt0/freq0/min_freq is accepted and cur_freq reads 2500.

I thought maybe SR-IOV (OK actually Gemini suggested that) but in Grub, Ubuntu shows xe.max_vfs=0

During load testing, pl4 is reported as the reason. Is that set by the BIOS or EC? Can it be changed?

[Anatolii]

Same laptop and chip here. I see something similar I guess, but from the power package side.

Package power under different loads:

• stress-ng --cpu 12 alone: 40 W, cores 2.5-3.4 GHz, 100 C, fans full;
• vkmark alone: 10–12 W, GPU reaches its full 2500 MHz;
• Both together: 15 W, cores at 100% busy but only ~2100 MHz;
• Games (CS2, Control): 20-23 W, CPU ~1500 MHz, GPU ~1550, 60–65 C, fan barely spinning;

PL1 is 33 W, so nothing is near the sustained limit in any of the GPU cases. Temps are fine, and the EC isn’t asserting PROCHOT (framework_tool --host-command 0x3E22 0 returns 0000 under load).

So the odd part is the combined case: the package draws less with CPU+GPU both working than with the CPU alone.

Tested on kernel 7.2.6. 7.3-rc behaves the same. BIOS 03.02, EC sakura-3.0.2, Kubuntu, kisak mesa, 100 W charger.

Caught the transition live. stress-ng alone: 30 W, P-cores 3800 MHz, E-cores 2900. Start vkmark on top of it and within a few seconds the package drops to 17 W with P-cores at 1970 and E-cores at 1550, and it stays there. vkmark alone only draws 10–12 W. So adding the GPU load lowers total package power by ~13 W instead of raising it. Temps and fan are nowhere near a limit at that point.

[Mark_Hall]

OK that sounds like a bug. I got similar results, vmark + stress-ng combined pulls less power than stress-ng alone, which makes no sense.

[onix331]

Running fedora 44, kernel 7.2.5, i cannot confirm this (also 358h CPU)

I tried both vkmark and furmark + stress-ng as in the posts above, but my GPU is clocking at 2.5Ghz constantly (GPU load ~90-95%), CPU load 99%, with peak power at 38.5W ish, sustained ~25W

[Mark_Hall]

So you can get peak GPU performance even while CPU is being stressed?

I am seeing something more like this:

vkcube only: Package Power 13w, GPU 2500mhz, CPU 2314mhz
vkcube and stress-ng Package Power 21w, GPU 1850mhz, CPU (top core) 2.04ghz
stress-ng only: Package power 33w, CPU (top core) 3.5ghz

I’ve forced CPU package power up to about 37w with another stress test, but the bizzare thing here is the package power being lower when CPU/GPU are stressed.

If this is fine in Fedora, this looks more like a mesa bug.

[onix331]

I attached screenshots of what i’m seeing; note that i removed both tuned-ppd and power-profiles-daemon since i think that the CPU is behaving much better that way. (Better idle power consumption etc.)

With furmark and stress-ng --cpu 12:

With vkmark and stress-ng --cpu 12:

Here’s uname -a

Linux fedora 7.2.5-200.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Sep 11 15:11:05 UTC 2026 x86_64 GNU/Linux

[Anatolii]

Ruled out on my side:

• platform profile (balanced vs performance)
• power-profiles-daemon and thermald both stopped
• fan forced to 100%
• upstream linux-firmware (GuC 70.72.1, GSC 1397, DMC 2.36), kernel 7.2.6 and 7.3-rc3
• removing pcie_aspm/nvme and all non-standard boot params
• switched back from Kisak Mesa to the Ubuntu default 26.0.8-1ubuntu0.3

Same result: still ~16–18 W and GPU ~1900 MHz under stress-ng + vkmark. GPU throttle reason stays pl4 only, same as GPU-only load where it hits 2500. Will try a Fedora 44 live USB next.

[Anatolii]

Retested on Kubuntu with kernel 7.3 (rc-3) (the Fedora live USB I tried earlier had 6.19, too old to compare):

• Furmark alone: GPU ~1950 MHz, package ~28-29 W;
• Furmark + stress-ng: package 32 W (at PL1), GPU still ~2000;

So under a heavy load the power budget gets used properly.

About the 2500 MHz vs 1950 MHz difference: I think it’s just what some tools report, which may not be the real frequency. Ran nvtop along with Furmark and got 2500 MHz GPU reading, which appears to be what system requests, but not the real frequency. To see the real one I used:

while true; do d=/sys/class/drm/card1/device/tile0/gt0/freq0; echo "$(date +%T) cur=$(cat $d/cur_freq) act=$(cat $d/act_freq) $(cat $d/throttle/reasons)"; sleep 1; done

the output was

19:21:10 cur=2500 act=2000 pl4
19:21:11 cur=2500 act=1950 pl4
19:21:12 cur=2500 act=1900 pl4
19:21:13 cur=2500 act=1900 pl4
19:21:14 cur=2500 act=1900 pl4
19:21:15 cur=2500 act=1900 pl4

@onix331, could you please check this while running Furmark on your system?

while true; do d=/sys/class/drm/card1/device/tile0/gt0/freq0; echo "$(date +%T) cur=$(cat $d/cur_freq) act=$(cat $d/act_freq) $(cat $d/throttle/reasons)"; sleep 1; done

or (depending on where the gpu is, card0 or card1)

while true; do d=/sys/class/drm/card0/device/tile0/gt0/freq0; echo "$(date +%T) cur=$(cat $d/cur_freq) act=$(cat $d/act_freq) $(cat $d/throttle/reasons)"; sleep 1; done

It will show both requested GPU frequency and the real one that the GPU could achieve.
This could settle the frequency discrepancy, I guess.

What still looks off is lighter GPU loads: vkmark + stress-ng drops the package from ~30 W to 17 W, and games sit at 20-23 W, well below PL1.

[Mark_Hall]

This is what I am seeing - they’re reading cur_freq when seeing 2500mhz rather than act_freq. The driver is requesting the correct frequency but not getting it because of pl4

[onix331]

Ok. It seems like most tools out there will read the current, not actual clock.
I do wonder why, maybe the actual clock is somehow misleading?

Here’s the output of the command (card0) running just furmark (no CPU load) and cpupower set --epp power (Powersaving)

21:21:00 cur=2500 act=1950 pl1
21:21:01 cur=2500 act=1900 pl1

Here is cpupower set --epp performance

21:21:42 cur=2500 act=1950 pl1
21:21:43 cur=2500 act=1900 pl1

Running turbostat i get these number respectively (Intel’s own tool also seems to favour the current clock)

Powersave:

Busy% Bzy_MHz PkgTmp  GFXMHz  PkgWatt CorWatt GFXWatt 
11.33   1262    72      2500    24.70   3.04    19.53 
7.36    665     72      2500    24.73   3.04    19.55

And performance again

Busy%   Bzy_MHz PkgTmp  GFXMHz  PkgWatt CorWatt GFXWatt 
13.78   1267    72      2500    24.91   3.18    19.45 
6.99    767     72      2500    24.92   3.18    19.45

Exact command used:

sudo turbostat --quiet --show Busy%,Bzy_MHz,PkgWatt,CorWatt,GFXWatt,GFXMHz,PkgTmp --interval 1

Now, with stress-ng --cpu 12 and furmark running i get this, either with powersave or performance, virtually no difference either way.

21:23:07 cur=2500 act=1700 pl1 
21:23:08 cur=2500 act=1750 pl1 
21:23:09 cur=2500 act=1650 pl1

Busy%   Bzy_MHz PkgTmp  GFXMHz  PkgWatt CorWatt GFXWatt 
84.65   1306    71      2500    25.02   6.77    15.79 
99.77   1277    71      2500    25.06   6.77    15.81

Lower GPU power is expected since the CPU is working harder, but the clock stays the same? But this is Intel Arc, i wouldn’t trust those clocks too much.
Also the 2.5Ghz is defined as Graphics Max Dynamic Frequency, and that is with the 80W Maximum Turbo Power they specify.
Since the framework 13 Pro can do what, 38W peak (realistically?), seeing such a lower clock seems to be expected.

[Joe_Name]

one change intel made with panther lake - it doesn’t auto-switch from balanced power profile to the performance power profile. Try switching the power profile to performance then test again. It made a huge difference for me. I tested forever getting nowhere, then: Phoronix

[Mark_Hall]

I’ve done a few dozen tests now all with basically the same result. The GPU never hits 2.5ghz at all. It seems like all of these tools report the driver request as the actual frequency, rather than sampling the frequency. I started all of this as I was building in monitoring to fw-helper and thought I had either faulty hardware or some bad driver / firmware. I’m now showing both requested and actual frequency.

I’m not convinced this is about the GPU needing 80w to get to this frequency. It’s leaving a lot of power on the table when the CPU and GPU are stressed, 8-10w at least and the GPU rarely pulls above 10w so it could potentially get 2x that with much higher frequencies.

I’m curious about other laptops now and if this is the same on Windows.

[gremlin]

Hi everyone! I opened an issue on Framework’s GitHub. Perhaps I should have opened it against EC repository but I digress…

Essentially what I discovered is that GPU frequency is limited by PL4 which is hard capped at 80w while previous Intel generations have much higher limits (more information is on the github). I have an open ticket with FW support where I’m trying to escalate this to get attention from the dev team.

Hopefully this will be addressed in the next BIOS and/or EC version.

[Adrian_Joachim]

@gremlin

Hi everyone! I opened an issue on Framework’s GitHub. Perhaps I should have opened it against EC repository but I digress…

And there I was complaining about them way overcooking the amd equivalent of this parameter (P3T) on the 7x40u causing dips into battery, guess they overcorrected a little.

I do hope if they adjust it they only do it for the performance profile and not globally though.

[Mark_Hall]

This is not going to solve the GPU ‘cap’ at 1800/1950mhz. pl4 is a microsecond cap, you’re never going to observe the spikes. The negative correlation between CPU clockspeed and GPU clockspeed is entirely to do with current in package, not TDP.

Interestingly if you cap the Atom cores (E and LP-E cores) you get a significant boost in P-core performance. I’m working on a game mode for fw-helper that will optimise the balance of GPU and CPU performance through selective parking and throttling of cores.

[Gautam]

Either way, thanks to @gremlin for opening the issue; I really want to see what Framework has to say about this and if they can do something on their end to help fix this. CS2 is getting less than half the performance that it should be getting on the X7 (even with the FW13 Pro’s lower performance relative to other X7 laptops), as I’m getting 60-100fps with constant dips while other X7 laptops easily reach 200-240fps.

[gremlin]

Wow it does go to 2150 and even 2200 on power saver profile! It is so counter intuitive, right? I was so convinced by AI and the fact that EC code only has power caps on PLs that I didn’t even think about running a game on power saver profile. And you know I was digging in that direction before off of a reddit review where the person was pinning games to efficiency cores to get better fps but in my experience the gains were marginal at best.
Thank you very much! I think you should leave a comment on GitHub as well as there are a couple replies from other people who are experiencing the same issue.

[catastrophic]

If you haven’t already, please file a ticket with support so they can investigate. Feel free to link this thread and the Github link. Thanks!

[gremlin]

Follow up: I replicated the cap on the cores and ran some gaming behcnes. And while the frequency gain aligned with your results there were no performance gains in gaming. If anything capping CPU cores is harmful to the stability of the game. Meanwhile mainboard stays flat at 25w on balanced…