r494 the GL 3D-channel classification: NV2080_ENGINE_TYPE_GRAPHICS (1) is a GR channel

With the real-GSP KGR snapshot in place the X driver's 3D-engine selection
succeeds; the next wall was 'Failed to initialize DMA' / 'Failed to allocate
push buffer' - the X driver's pushbuffer NOP test never saw its GPFIFO entry
consumed. Root: the wire's NV_CHANNEL_ALLOC_PARAMS engineType carries
NV2080_ENGINE_TYPE_* (NULL=0, GR0/GRAPHICS=1, COPY0=9); CUDA's kernel-RM GR
channels arrive with NULL=0 and the progress service's convention is
'engine_type == 0 means GR', so the X/GL 3D channel's real GR0 value 1 was
misclassified as a CE - the CE path then demanded a ring translation the
channel does not have (rrc=-2 'norrng'), never probed the USERD, and the pump
never executed a single entry (submissions=0 at the 10 s timeout).

Normalize GR0..GR7 (1..8) to 0 at channel registration; every other engine
id is >= COPY0 (9) so no CE can be captured. Also fixes the KGR snapshot
max-size constant: KGR_GET_INFO is 3712 bytes (8 engines x 58 x 8), which
the 1664-byte cap silently dropped - the one snapshot the engine selection
actually needs.

1 files changed, 1 insertions, 1 deletions

diff --git a/kernel/gsp_phys_booter.c b/kernel/gsp_phys_booter.c
index df96ec1..734ebf2 100644
--- a/kernel/gsp_phys_booter.c
+++ b/kernel/gsp_phys_booter.c
@@ -6844,7 +6844,7 @@ EXPORT_SYMBOL_GPL(gsp_phys_backend_static_wait);
  * getter refuses entries once the session has moved on.
  */
 #define GSP_PHYS_KGR_SNAP_ENTRIES	10
-#define GSP_PHYS_KGR_SNAP_MAX_SIZE	1664u
+#define GSP_PHYS_KGR_SNAP_MAX_SIZE	3712u	/* KGR_GET_INFO: 8 engines x 58 x 8 */
 
 struct gsp_phys_kgr_snap {
 	u32 cmd;