Gaming on Intel® Processors with Intel® Graphics
Ask questions and get answers, tips/tweaks, and techniques from product and technology experts
Announcements
FPGA community forums and blogs have moved to the Altera Community. Existing Intel Community members can sign in with their current credentials.
674 Discussions

Intel Needs to Refocus on Real-World Performance—A User’s Manifesto

GHOST4
Beginner
1,024 Views

HELLO,INTEL 

*I am a fan of your excellent cpus.

*I had known you since 2010.

*Even my first cpu was from yours The Intel Pentium N3700.

*You had been an excellent cpu manufacturer.

*You are the real hero among enthusiasts like us .

*But ...there are some problems and some suggestions.

*I always want you to win.

I Don’t Want Theoretical Specs. I Want Real Speed

  • Don’t advertise peak clocks that last milliseconds.

  • Show us sustained performance under realistic thermal and power conditions.

  • Benchmark your chips with actual workloads—gaming, rendering, multitasking—not just synthetic tests.

 

🧠 Focus on What Matters

  • Your P-cores are powerful—refine them and let them lead.

  • Give us more L2 and L3 cache instead of bloating core counts.

  • Prioritize IPC and latency over flashy GHz numbers.

 

Don’t Force AI on Us

  • NPUs are not essential for most users—especially gamers.

  • Don’t sacrifice iGPU performance or CPU die space for features we don’t use.

  • Make AI acceleration optional in performance-focused CPUs.

 

Firmware Is Your Secret Weapon

  • Optimize Thread Director for gaming and creative workloads.

  • Improve Turbo Boost behavior for sustained performance.

  • Give users more control over performance modes and thermal profiles.

 

Respect the Enthusiast Community

We’re not asking for miracles—we’re asking for honest engineering. Build CPUs that deliver real-world performance, and we’ll be your biggest fans.

Until then, we’ll keep pushing for better—because we know you can do better.

— Dharsan Performance-first user, i5-1235U owner AND YOUR FAN.

0 Kudos
4 Replies
Mike_Intel
Moderator
960 Views

Hello GHOST4,


Thank you for posting in Intel community Forum.


For me to document your request/suggestions, please help provide the following details.


  1. What is the model of your processor?
  2. What is the model of your Graphics Controller?
  3. Can you tell us more why you recommended or suggest the following? Please elaborate.


If you have questions, please let us know. Thank you.


Best regards,

Michael L.

Intel Customer Support Technician


0 Kudos
GHOST4
Beginner
924 Views

Hello Michael,

 

Thanks for the quick reply — I appreciate you documenting my suggestions. Below are the details you requested and an explanation of why I recommended the changes.

 

Processor model

Intel Core i5-1235U (Alder Lake-U, 2 Performance cores + 8 Efficient cores)

 

Graphics controller

Intel Iris Xe iGPU — 80 EUs (integrated)

 

Summary of my recommendations and rationale

 

1. Power reporting slopes (IMON / iGPU IMON / PSYS)

 

Current settings I tested:

 

CPU IMON slope ≈ 0.25 (entered as 25 in 1/100 increments)

 

iGPU IMON slope ≈ 0.30 (30)

 

PSYS slope ≈ 0.60 (60)

 

 

Why: These slope values change how the platform reports current/power to Intel power-management firmware. Lowering the slopes makes the firmware under-report current/power, which delays or prevents premature current/power-limit throttling (TDC/PL1/PL2/PSYS). On my laptop this allowed the CPU and iGPU to sustain higher boost clocks for longer without dropping frequency early.

 

Observed benefit: System felt much smoother, and synthetic scores improved (Silverbench ≈ 34,241; close to a Ryzen 5 5700U result of ≈ 35,000). Package temps remained acceptable with improved cooling.

 

 

 

2. TDC (Thermal/Time-dependent Current)

 

I found that the TDC limit was the immediate cause of “current limit throttling.” Raising TDC removes the instantaneous current cap that forces clocks down even when PL1/PL2 would otherwise allow more power.

 

Why: On iGPU-heavy gaming, CPU+iGPU bursts spike current. If TDC is too low the platform will throttle instantly. Increasing TDC to an appropriate value prevents those spikes from causing throttles.

 

Suggested range: For gaming on a laptop with a 65 W adapter, I found pragmatic ranges of 40–60 A (register entries in 1/8 Amp or 1/4 Amp units depending on vendor interface). Start conservative and test VRM temps.

 

 

 

3. PL1 / PL2 / Tau adjustments

 

Raise PL1/PL2 and lengthen the Tau (time window) so that the CPU can sustain higher power for longer before throttling down.

 

Why: Stock laptop profiles are conservative; raising these lets the CPU make use of the extra headroom unlocked by slope/TDC tuning. Combined with the IMON/PSYS adjustments this yields better sustained clocks in games and multithreaded workloads.

 

 

 

4. Thermal-aware scheduling idea

 

A scheduler/daemon (or firmware support) that schedules latency-sensitive tasks to cooler P-cores and background tasks to hotter P-cores or E-cores, with dynamic role rotation so no core stays hot indefinitely.

 

Why: This spreads heat and reduces hotspots, prolongs boost windows, and reduces stutter. I prototyped this idea conceptually (and tested lightweight affinity moves) and it reduced thermals and improved frame stability in practice.

 

 

 

5. Safety & monitoring

 

I am monitoring package power, per-core clocks, limit reasons, VRM/adapter temperatures, and battery/AC state (HWiNFO on Windows; RAPL / sensors on Linux).

 

I’m aware that aggressive slope/TDC/PL settings increase VRM and adapter stress. I tested with improved cooling and reverted if VRM temps or adapter behavior was unsafe.

 

 

 

 

What I can provide to Intel (if helpful)

 

HWiNFO logs (sensors, limit reasons) from my gaming and synthetic runs

 

Before/after benchmark results (Silverbench, Geekbench, Cinebench) and thermal logs

 

Exact register values and the commands I used (VR mailbox 0x4 for IMON slope; 0xB for PSYS max P; TDC register in 1/8 W or 1/8 A format depending on platform)

 

A short description of the dynamic scheduler idea and a prototype pseudo-code or daemon for Linux

 

 

What I’m requesting from Intel

 

Clarification of safe ranges and recommended approaches for manipulating IMON/PSYS/TDC on Alder Lake-U platforms (especially where platform protections may react unexpectedly)

 

Any vendor-recommended guidance on VR mailbox usage (0x4 / 0xB) and the correct way to revert values if the EC/BIOS is locked

 

If possible, documentation on how PSYS and IMON interact with EC/adapter behavior so I can build safe automated monitoring

 

 

If any of the above needs more detail (logs, specific register dumps, command sequences), I can upload attachments. Thank you for helping document this.

 

Best regards,

[GHOST]

0 Kudos
Mike_Intel
Moderator
884 Views

Hello GHOST4,


Thank you for the information provided.  


I will do further research on this matter and post the response on this thread once it is available.


If you have questions, please let us know. Thank you.


Best regards,

Michael L.

Intel Customer Support Technician


0 Kudos
Mike_Intel
Moderator
786 Views

Hello GHOST4,


First of all, thank you for the feedback that you raised.


All of the feedback that you mentioned are noted and will be forwarded now to the appropriate team.


Since we already noted the feedback, I need to close this inquiry. 

If you need further assistance, please post a new question as this thread will no longer be monitored. 


Thank you and have a great day.


Best regards,

Michael L.

Intel Customer Support Technician


Reply