able to directly call an entry point without wrapping it in a trampoline with a CallData structure if it is already tagged as a compute shader or cuda kernel

[mkeshavaNV]

[mkeshavaNV]

@ccummingsNV - should I move this to you? I believe you've started looking at it?

[jkiviluoto-nv]

@nv-slang-bot Mukund (mkeshavaNV) won't be returning to this work for a while. Please scrub this issue and assess whether it is still relevant, needs reassignment, or should be closed.

[nv-slang-bot]

Scrub & reassess (requested by @jkiviluoto-nv). Verified against main @ 507b4cf, confirmed identical to the live remote head at time of writing.

• Status: Open, unimplemented. Zero commits in the 949-commit history reference able to directly call an entry point without wrapping it in a trampoline with a CallData structure if it is already tagged as a compute shader or cuda kernel #820. ⚠️ This issue's body is empty — the title is the entire spec. It is checklist item 2 of epic Support raw dispatch in slangpy #768, whose body scopes the work as "Modify our existing calldata.py based path" and separately notes the legacy .dispatch() path "is not well maintained and should be retired" — so work on dispatchdata.py does not satisfy this issue. One correction to the premise of the request below.
• Q1 — Still relevant? YES, and the path is worse than merely absent — it segfaults. No entry-point detection exists on the calldata path: grepping entry_points|is_entry_point|CUDAKernel across calldata.py/generator.py/function.py/codegen.py returns only ray-tracing entry-point names, and CUDAKernel appears zero times in library logic (all 32 hits are authored .slang test/benchmark sources and docs prose). The wrapper is unconditional — generator.py:928-942 always emits the CallData structs and then [shader("compute")] + [numthreads(...)] + void compute_main(...) (generator.py:767-786). Prim mode does drop the _trampoline function (generator.py:937, Remove trampoline function generation on fwds pass #879), but the CallData struct and generated compute_main wrapper remain, which is exactly what this issue asks to skip. Entry-point detection does exist — but only on the path Support raw dispatch in slangpy #768 wants retired: dispatchdata.py:83-86 reuses a pre-existing kernel, code that predates the epic (Fixed the way entry points are looked up to avoid exceptions #399), and mod.tagged_kernel.dispatch(uint3(32,1,1), buffer=...) works correctly today. New finding, not covered by any existing issue: calling an already-tagged entry point through the functional API crashes the process on both backends I could test. Controlled isolation — same body, same signature, tag as the only variable:
  
  | variant | tag | semantic | CUDA | Vulkan |
  |---|---|---|---|---|
  | v_plain | — | — | rc=0 OK | rc=0 OK |
  | v_sem | — | SV_DispatchThreadID | rc=0 OK | rc=0 OK |
  | v_tag | [shader("compute")] | — | rc=139 SIGSEGV | rc=139 SIGSEGV |
  | v_full | [shader("compute")]+[numthreads] | SV_DispatchThreadID | rc=139 SIGSEGV | rc=139 SIGSEGV |
  
  [shader("compute")] alone is sufficient. Reproduced 3 of 3 trials on CUDA, with the v_sem control passing 3 of 3 in the same loop. Localised: kernel generation and shader compilation both complete (instrumented CallData.__init__ reached its exit, generated shader dumped in full) — the crash is at dispatch, after compile. The generated code shows the collision: SlangPy emits its own [shader("compute")] void compute_main(… uniform GridArg<3> dispatchThreadID …) wrapping a function that is already an entry point, and slang warns E38040: entry point parameter treated as uniform on the tagged variant. Hypothesis, unverified: that double-entry-point / uniform-vs-varying collision is the mechanism — I have not attributed it to slangpy vs slang codegen (see caveats).
• Q2 — Needs reassignment? Not this issue — one correction. able to directly call an entry point without wrapping it in a trampoline with a CallData structure if it is already tagged as a compute shader or cuda kernel #820's sole assignee is @ccummingsNV, not @mkeshavaNV. Per the timeline: @jhelferty-nv assigned mkeshavaNV on 2026-02-26; mkeshavaNV then assigned @ccummingsNV and unassigned himself on 2026-03-13, after asking "should I move this to you? I believe you've started looking at it?". So Mukund's departure does not orphan able to directly call an entry point without wrapping it in a trampoline with a CallData structure if it is already tagged as a compute shader or cuda kernel #820. It does orphan siblings: able to wrap a 'raw entry point' for the backwards pass, and detect that if the forwards function is marked [CUDAKernel], so should the backwards one be #822 and epic Support raw dispatch in slangpy #768 itself are both still assigned to him and need rehoming (take a thread count, in the event the kernel has a dimensionality of 0 (no arguments are vectorized) #819 is closed/completed; able to generate a minimal wrapper for an entry point when the only thing missing is the compute shader / cuda kernel tag #821 already sits with @ccummingsNV).
• Q3 — Should it be closed? NO — keep open. Not fixed (verified above), not a duplicate (searched issues and PRs; nothing covers direct entry-point calls, and the shader_cache_path segfaults on first pipeline creation (Vulkan) #1089/[Bug] Backward dispatch segfaults when a [Differentiable] function has a loop with a negative runtime start value #1051/Simple function taking ITensor argument segfaults in forward pass if a custom bwds function is defined #639 segfaults are unrelated conditions), not obsolete. There is a scope question I'm deliberately leaving to a maintainer: Support raw dispatch in slangpy #768 says .dispatch() should be retired, yet the entry-point detection this issue wants already exists there, and the direction that actually shipped for checklist item 1 was _thread_count on the CallData path. So able to directly call an entry point without wrapping it in a trampoline with a CallData structure if it is already tagged as a compute shader or cuda kernel #820's framing may be partly superseded even though the capability is genuinely missing from the calldata path.
• Next action: (1) keep open at P2 — no reassignment needed here, @ccummingsNV already owns it; (2) split the segfault into its own bug — it's a crash on a call that is reachable today, independent of whether this optimisation is ever built, and it warrants a clear exception as a guard even if the optimisation is declined; (3) restate acceptance criteria in the empty body before any handoff — a bare reassignment of an empty-body issue hands over a title, not a task; (4) reassign able to wrap a 'raw entry point' for the backwards pass, and detect that if the forwards function is marked [CUDAKernel], so should the backwards one be #822 and Support raw dispatch in slangpy #768 off @mkeshavaNV.
• Blocker: none for the assessment. Caveats on what I could not check, stated so the verdict isn't read as cleaner than it is: no local build of HEAD was available (python absent from PATH, no build/ dir), so the probe ran on the released 0.43.1 wheel — the result transfers because generator.py, calldata.py, dispatchdata.py, codegen.py and function.py are all byte-identical between v0.43.1 and 507b4cf (verified by object hash; the 14 intervening commits touch none of them), but I did not run HEAD itself. gdb is not installed here, so I have no native backtrace and cannot attribute the segfault to slangpy vs the slang compiler — that ownership call is open. Metal and D3D12 were not exercised (unavailable on this Linux host).

_{Also noted while scrubbing, outside this issue's scope: two orphaned artifacts from @mkeshavaNV that a plain issue read won't surface — PR #904 is an open [DNS] draft (dev/mkeshava/benchmark_test, last touched 2026-03-31, 116 commits behind main), and branch dev/mkeshava/ppisp_dispatch_timers has no PR at all (2026-03-31, 116 behind). Both are ppisp benchmark work, unrelated to #820. dev/mkeshava/nn_parameter belongs to closed PR #828. For #820 specifically: no orphaned work exists — that's a measured result, not an unasked question.}

_{🤖 Generated by an automated SlangPy coworker — may be inaccurate. A human maintainer should verify.}