Jump to content
559 posts in this topic

Recommended Posts

Posted (edited)

This log is a breakthrough. Let me parse it carefully.

V202 verdict: GGTT[0] present=1 llc=1 — ForceWake was the whole problem with the earlier zero reads. And now we have the real PTE values for the actual surfaces:

  • V201[4]: surf=0x412be000  PTE=00000007:e377f08b present=1 llc=1 
  • V201[8]: surf=0x40396000  PTE=00000007:e2ef808b present=1 llc=1 

The GGTT PTEs are valid. The display engine can DMA from those surfaces. The pipeline abort is not caused by missing mappings.

Two things stand out now:

  1. PLANE_SURF=0 at HANGCHECK — the surface cycling hasn't happened yet when fwCall=15 fires. The GPU is already stalled (INSTDONE=0xfffffffe, bit0=0 = CS stall) during startGraphicsEngine before the FB controller even arms real surfaces.

  2. INSTDONE=0xfffffffe + EXECLIST_STATUS=0x18001 (one context queued, active) — the RCS command streamer is stuck mid-execution on the initial ExecList batch. No fault bits set, so it's not a page fault. It's a stall — likely a MI_SEMAPHORE_WAIT or pipeline sync waiting on something that never comes.

lilu.log

Edited by Stezza88
Posted (edited)

The big picture just snapped into focus. Two findings from this log:

1. GGTT PTEs are validGGTT[0] present=1 proves ForceWake was the whole problem with earlier reads. V201[4] (0x412be000) and V201[8] (0x40396000) both show present=1 llc=1 with physical addresses at ~31.4–31.5GB DRAM. The GGTT mapping is correct. Display DMA should reach those pages.

2. The ordering is reversed from what we thought — HANGCHECK fires (fwCall=15) before ANY V201 call. The BAR2 "aperture mapped" message appears after HANGCHECK. This means the accelerator path starts first, stalls (INSTDONE bit0=0, ACTHD=0, IPEHR=0 — CS hasn't executed a single instruction), and then the FB tier independently runs its surface cycling (V201[1-8]).

The CS stall and the display abort are probably two separate problems. The pipeline abort must be caused by something else — wrong PLANE_CTL tiling, PLANE_SIZE mismatch, display power-well timeout, or something in Apple's color pipeline init for the non-stolen surface case.

 

 

The picture just completely changed.

Edited by Stezza88
#define R(addr) NGreen::callback->readReg32(addr)
SYSLOG("ngreen", "V203: --- SCANOUT REGISTER DUMP ---");
// Plane A
SYSLOG("ngreen", "V203 PLANE_A: CTL=%08x STRIDE=%08x POS=%08x SIZE=%08x OFFSET=%08x SURF=%08x SURFLIVE=%08x AUX_DIST=%08x AUX_OFFSET=%08x KEYVAL=%08x KEYMSK=%08x KEYMAX=%08x COLOR_CTL=%08x",
R(0x70180), R(0x70188), R(0x7018C), R(0x70190), R(0x701A4),
R(0x7019C), R(0x701AC), R(0x701C0), R(0x701C4),
R(0x70194), R(0x70198), R(0x701A0), R(0x701CC));
// Pipe A general
SYSLOG("ngreen", "V203 PIPE_A: SRCSZ=%08x CONF=%08x MISC=%08x MISC2=%08x STAT=%08x",
R(0x6001C), R(0x70008), R(0x70030), R(0x7002C), R(0x70024));
// Transcoder A timings
SYSLOG("ngreen", "V203 TRANS_A: HTOTAL=%08x HBLANK=%08x HSYNC=%08x VTOTAL=%08x VBLANK=%08x VSYNC=%08x VSYNCSHIFT=%08x",
R(0x60000), R(0x60004), R(0x60008), R(0x6000C),
R(0x60010), R(0x60014), R(0x60028));
// DDI function control + MSA
SYSLOG("ngreen", "V203 TRANS_A_DDI: DDI_FUNC_CTL=%08x DDI_FUNC_CTL2=%08x MSA_MISC=%08x CONF=%08x CLK_SEL=%08x",
R(0x60400), R(0x60404), R(0x60410), R(0x70008), R(0x46140));
// DP M/N values for Pipe A
SYSLOG("ngreen", "V203 TRANS_A_DPMN: DATAM1=%08x DATAN1=%08x DATAM2=%08x DATAN2=%08x LINKM1=%08x LINKN1=%08x LINKM2=%08x LINKN2=%08x",
R(0x60030), R(0x60034), R(0x60038), R(0x6003C),
R(0x60040), R(0x60044), R(0x60048), R(0x6004C));
// Pipe A scaler 1
SYSLOG("ngreen", "V203 PIPE_A_PS1: CTRL=%08x WIN_POS=%08x WIN_SZ=%08x VPHASE=%08x HPHASE=%08x",
R(0x68180), R(0x68170), R(0x68174), R(0x68188), R(0x68194));
// DSC slice control / PPS for Pipe A (DSC_BASE_A around 0x6B200; varies by gen)
SYSLOG("ngreen", "V203 DSC_A: PIC_RC=%08x PPS0=%08x PPS1=%08x PPS2=%08x PPS3=%08x PPS4=%08x",
R(0x6B200), R(0x6B210), R(0x6B214), R(0x6B218), R(0x6B21C), R(0x6B220));
// DDI buf / port
SYSLOG("ngreen", "V203 DDI_BUF: A_CTL=%08x B_CTL=%08x | DP_TP_CTL_A=%08x DP_TP_STATUS_A=%08x",
R(0x64000), R(0x64100), R(0x64040), R(0x64044));
// Display Buffer programming
SYSLOG("ngreen", "V203 DBUF: CTL_S0=%08x CTL_S1=%08x DBUF_BUF_CFG_A_PA=%08x A_PB=%08x",
R(0x44300), R(0x44304), R(0x70B80), R(0x70B84));
#undef R

This is the definitive answer. After wbinvd, the LRCA page1 is all 0x00ffffff — the fill pattern Apple pre-initializes the buffer with. initWithOptions never writes the LRI headers (DW0, DW1 positions). It only writes zeros to certain value-slot positions.

The pattern becomes clear:

DW V508[1] post-wbinvd Expected (i915 layout)
0 0x00ffffff (fill) MI_NOOP (0x0)
1 0x00ffffff (fill) MI_LRI header (0x11001005)
2 0x00000000 (written) CONTEXT_CONTROL addr (0x2090)
3 0x00000000 (written) CONTEXT_CONTROL value
4 0x00000000 (written) RING_HEAD addr (0x2034)
5 0x00ffffff (fill) RING_HEAD value (0)
6 0x00ffffff (fill) RING_TAIL addr (0x2030)
7 0x00000000 (written) RING_TAIL value (0)

initWithOptions writes zeros to some VALUE slots but never writes the LRI headers or register addresses. The hardware sees 0x00ffffff at DW1 = MI_NOOP → no registers restored → ring state undefined → context posts IDLE immediately without executing anything.

Root cause: Apple's TGL initWithOptions does a partial CPU-side setup and relies on the GPU executing a "golden context" init batch (the submitStampCommand stamp) to write the actual LRI headers into LRCA page1. But the GPU can't execute anything because the LRCA is incomplete — classic chicken-and-egg.

The fix is V509: after withOptions returns, manually write the missing LRI structure to LRCA page1. But first we need the ring buffer GGTT address. The fifo[0x18]=0xffffffa044dcf000 is the ring buffer object — let me extend V508 to dump its fields to find the GGTT base

Posted (edited)

What's in place (built, awaiting test):

Hook Status Purpose
V506/V507 Working Keep GFX_RUN_LIST_ENABLE set (ExecList mode)
V508 Working (diagnostic) Confirmed DW1=0x00ffffff post-wbinvd
V509 Built, not yet tested Repair LRCA page1: writes Gen12 MI_LRI block after original returns

V509 writes (when DW1 = 0x00ffffff😞

  • DW1 = 0x11001005 (MI_LRI(3)|FORCE_POSTED, Gen12 bit-12)
  • DW2/3 = CTX_CTRL 0x2090 / 0xffff0001
  • DW4-7 = HEAD/TAIL at 0
  • DW8 = 0x11001003 (MI_LRI(2)|FORCE_POSTED)
  • DW9/10 = RING_START 0x2038 / value from live MMIO
  • DW11/12 = RING_CTL 0x2040 / value | RING_VALID
  • DW80 = 0x05000001 (Apple context-image valid marker)

Next step: Deploy and boot, look for in the log:

  1. V509: repairing LRCA page1 ... RING_START=402eb000 — repair fired
  2. V509: repair done DW1=11001005 — write confirmed
  3. Then check if startGraphicsEngine no longer returns 3022544385 (ideally no error, or a different/later error)

If V509 fires correctly and the ExecList context actually reaches ACTIVE state in HANGCHECK (CSB shows ACTIVE before IDLE), the ring-restore is working.

 

 

When 'ill return from work I will see...

Edited by Stezza88
  • Thanks 1

The one remaining hardcode is 0x19 — the submission slot index — which is structural to how ExecList works (LRCA always pinned at GGTT[0x18000/4096=0x18], page1=0x19) and isn't something we can derive at runtime without knowing the ELSP register contents.

Posted (edited)

I need to study React for my work at home from tomorrow.

 

So i will leave you gitted open source the maximum research possible about GFX study with my adl-p/rpl-p machine

I will return soon. See ya.

 

This library needs patience and more developers not disfactists..

 

Actual lib state:
- FB structs are consolidated / GFX structs needs study above, still unconsolidated

- GPU pipeline is on the road..

- FB-only is working but on my machine got visual problems tiling/stride core on 'paramSurfCompare' hook (forcing linear and stride 0xa0 is the only one way in which I can see something.. despite to apple wants x-tiled with 0x14 stride got black screen with this mode)

- FB+HW : at the moment i've got only a problem of screen recycling/restarting... but Metal loaded. The accelerator started.

- dropped - as you can see In first thread page and in the readme - a lot of boot arg not more needed for a suitable execution

- hooks are ordered in FB hooks and GFX hooks

- cleaned code from some junk..

- attached my personal data

 

Archivio.zip

repeated-fragmented.jpg

Edited by Stezza88

I'm sorry to see this end without success.  It's certainly not for lack of trying.  I was secretly cheering for you.  I love seeing the pursuit of what others say is impossible.

Nobody should expect AI to do anything significant, let alone correctly, and anyone who expected this person burning his money to offload his thinking to a markov chain deserves their disappointment.
My feeling is that he wanted to feel like he achieved what only a few can do but without the required skillset or will to acquire it, opting into the AI craze instead, and ultimately failing. Of course, he's going to deny this, but that's only my thoughts on the matter.
AI psychosis is confirmed again as a legitimate phenomenon.

I know I will sound mean by saying this, but I just say things how they are.

3 minutes ago, Stezza88 said:

Open source there is maximum effort research.

I'm not sure if shoving information into an LLM qualifies as "maximum effort", sir.

Posted (edited)

Call me what you want, but at least NootedRed works even if it has bugs. I didn't know anything when I started and I learnt everything myself, by experimenting and trying, until it worked. Nobody believed in me when I started. But I never called it quits because the "AI" couldn't find the issue for me.

Edited by Visual Ehrmanntraut

For context to readers, NootedGreen is an offshoot of NootedBlue, which was an offshoot of NootedRed by an ex-member of my team. 

Just now, Stezza88 said:

I am a leaker, if you create a videogame to make money, i will crack it. It's a promise

I never leaked anything from you or jalavoui, just shared my opinion on this matter without insulting you. It just worsens your position.

Posted (edited)

You have insulted my broken legs, it has been an hard work to reach the end of the road

 

And if you leaked nothing you've made it wrong. This library remains open to developer now. Here and forever..

Edited by Stezza88
×
×
  • Create New...