r458 THE memset2d root cause: the CE copy decode read only LINE_LENGTH_IN and ignored the LINE_COUNT value the driver encodes in the SAME count=2 method group at 0x418

Raw push evidence (sema-op2d-raw, new bounded diagnostic):
  raw 17000520 7c7f0204 ... 20018104 00001000 20018105 00001000
      20028106 00001000 00000100 20048100 7d7e 40c00000
The group at 0x418 carries count=2: v0 = LINE_LENGTH_IN (4096),
v1 = LINE_COUNT (0x100 = 256 rows). The CE decode stored only v0, so
st.line_count stayed 0, the 2D-copy builder took the single-row path
(m->bytes = 4096) and a 4 MB cudaMemcpy2D delivered exactly ONE page
per 1 MB block. memset2d_probe (new per-phase client) shows the exact
shape: per-MB ok=4096 / bad=1044480 in all three phases, total
12,505,200 of 12,582,912 - deterministic across boots (r453/r454/r459
identical). The GRCE variant has always decoded the count=2 form
(gr_line_count = v1); the CE path did not.

Fix: CE_M_LINE_LENGTH_IN stores v1 into st.line_count when count >= 2,
so the existing r420c contiguous-run logic (pitch == line => flat run
of rows*line) finally sees the row count. The same decode feeds the
fill path (cudaMemset2D).

Also adds the bounded sema-op2d-raw witness (raw method stream of every
pitch-shaped copy push) that produced the evidence, and a per-phase
memset2d_probe client under tools/cuda-ab/.

0 files changed, 0 insertions, 0 deletions