The seams now meet in one Metal 4 draw #4M91DG

The native Metal backend is no longer only an architectural proposal. Luv can create a Metal GPU provider, attach it to an SDL-owned CAMetalLayer, compile two live mathematical shader methods through a device-owned MTL4Compiler, link them into MTLRenderPipelineState, bind a shared MTLBuffer by GPU address through MTL4ArgumentTable, and issue a completed draw through the ordinary GPU command vocabulary. The remaining backend threshold is the full block material: uniform, texture, sampler, depth, and mesh resources must cross the same path before a pinned capture can be compared with Vulkan.

SDL canvas and events
        |
        | SDL_MetalView / borrowed CAMetalLayer
        v
Metal canvas context ---- Objective-C declarations ---- libobjc + Metal
        |                              |
        |                              `---- native ABI help where required
        v
luv GPU protocol
        ^
        |
typed shader specification
        |\
        | `---- MSL lowering ---- Metal pipeline ---- argument table ---- draw
        `------ SPIR-V lowering - Vulkan pipeline                    WORKING

The seams remain independently understandable: SDL owns the host, the Objective-C substrate (#M2PDTP) owns the Apple object boundary, and the shader language owns target-specific lowering. They are now staged proofs of one backend rather than three reasons to postpone starting it. #5A7QDE records the executable presentation half, #58IDSR the compiler half, and #PH57K5 the remaining block-material join. #348B7B records why argument tables implement resource binding here rather than decorate a legacy encoder path. #NABRMK records why the second backend matters and #HXUGEA why Metal 4 is the right native model for it.

Mentioned in: Objective-C interop is a reusable substrate

A native Metal backend now stands beside Vulkan #NABRMK

Moppe first supplied the motivation: its Metal renderer proves mesh shaders, MetalFX, and a finished post stack on the same Apple hardware, while MoltenVK cannot expose every native capability. That source evidence remains on the Moppe legacy page. The implementation claim now belongs here.

The current backend is deliberately narrow but real:

• hal/gpu.lisp in :luv is the shared semantic seam;
• the hal/metal module supplies Metal provider, device, queue, compiler, buffer, shader-module, render-pipeline, texture, general command-encoder, finished command-buffer, and render-pass objects;
• hal/metal/canvas.lisp specializes the canvas × provider relationship;
• declared Objective-C messages cover synchronous Metal 4 library compilation as well as the submission and drawable vocabulary needed by one frame; and
• cold probes validate in-memory luvcraft vertex and fragment libraries, their linked MTLRenderPipelineState and MTLDepthStencilState, the complete clear path, and a generated live-pipeline triangle through MTL4ArgumentTable on an Apple M2 Pro.

The canvas now uses that same general submission contract rather than a frame-owned shortcut: it creates an encoder through create, records ordinary commands, obtains one-shot work from finish, and calls the queue's submit. Only drawable signaling and presentation remain backend-local. This is enough to make asynchronous submission, dependency ownership, and destruction a portable contract for the implemented command vocabulary. It does not claim equal backend feature surfaces or WebGPU conformance. #HXUGEA describes the explicit backend mechanisms shared semantically.

Mentioned in: Each backend has a completion frontier of a different extent, The seams now meet in one Metal 4 draw, Sky, temporal reconstruction, and mesh shaders bound the proof

Metal 4's explicit model matches the Vulkan layer #HXUGEA

Metal 4 asks the application to own memory, synchronization, hazards, and resource lifetime explicitly. That is closer to luv's modern Vulkan layer than Metal 3's implicit model would be:

• command allocators may be reused only after GPU retirement, the same fact represented by luv's per-queue completion frontier;
• monotonic MTLSharedEvent values correspond to timeline-semaphore frontier values;
• explicit stage barriers match luv's owned image-transition decisions;
• MTL4ArgumentTable uses GPU addresses and resource IDs rather than hiding bindings in per-draw setter state;
• Metal 4 command buffers do not retain resources, matching luv's explicit lifetime and deferred-reclamation obligations; and
• queue-scoped MTLResidencySet makes residency a session concern.

The correspondence is now represented by the Lisp objects as well as the native calls. A finished metal-gpu-command-buffer owns its allocator, native command buffer, and every wrapper captured while encoding. Submission stamps those dependencies with a monotonically increasing shared-event value and retains them in a queue record until the frontier passes. Metal supplies no safety net for a missing barrier, so this lifetime parity is not a substitute for hazard proofs. The useful standard is semantic parity with explicit backend mechanisms, not line-for-line similarity.

Mentioned in: The seams now meet in one Metal 4 draw, A native Metal backend now stands beside Vulkan

Argument tables realize semantic binding groups #348B7B

Apple's Metal 4 core API account says that Metal 4 encoders do not bind individual buffers, textures, and heaps. The application instead populates an argument table and makes it visible to selected pipeline stages. The Metal 4 introduction separately places residency in MTLResidencySet. These are source claims about the native contract, not reasons to expose Metal tables as luv's application model.

Luv's binding group remains the semantic relationship among a layout and its resources. Its Metal realization should own stage-appropriate argument tables: buffers become GPU addresses, textures and samplers become resource IDs, and residency remains a queue or command-buffer concern. Vertex arrays use the same native table mechanism, but set-vertex-buffer still expresses their distinct draw relationship and obtains attribute stride from the linked pipeline layout.

The first realization is intentionally smaller than that destination. A render pass creates a vertex-stage table for the installed pipeline, set-vertex-buffer writes one GPU address and stride into it, and draw snapshots it through setArgumentTable:atStages:. The device's shared residency set contains the buffer allocation. This proves the mechanism, but the per-pass table is not yet a reusable Metal bind group; uniform buffers, texture resource IDs, and sampler resource IDs are the next extension.

SDL remains the platform shell #SODRMA

The canvas protocol separates a native place from its GPU presentation relationship. sdl-canvas owns the window, event translation, main-thread dispatch, pointer mode, size, and clock; backend contexts own the presentation resources.

SDL 3 provides SDL_Metal_CreateView, SDL_Metal_DestroyView, and SDL_Metal_GetLayer. The resulting metal-canvas-context owns the view, borrows its CAMetalLayer, assigns the configured Metal device, and destroys the view before the SDL window. Those SDL calls are main-thread-only; the existing call-on-sdl-canvas-thread path already reaches Cocoa's main thread. The host selects :vulkan or :metal as an immutable presentation policy before opening, while provider-specialized make-canvas-context methods validate the relationship.

Replacing SDL with NSWindow remains a separate experiment. It was neither necessary for the clear proof nor desirable as hidden scope in the backend.

Mentioned in: Present a Metal clear through the existing SDL canvas

The typed shader specification is already the shared IR #LVKEYO

The mathematical shader language already owns backend-independent meaning: stages, interfaces, resources, typed expressions, quantity annotations, lexical order, and source provenance. Its current compiler immediately turns that graph into SPIR-V IDs, decorations, storage classes, instructions, and a spir-v-module. Those objects are therefore a Vulkan lowering product, not a necessary interchange format for Metal.

The smaller shape is sibling lowering:

                    /--> SPIR-V lowering --> structured SPIR-V --> words
shader specification
                    \--> MSL lowering ----> structured document --> text

Translating SPIR-V back to MSL would preserve a single machinery path at the cost of making Vulkan interface choices the architecture of the Metal backend. Direct lowering keeps expression-to-output provenance and leaves native mesh/object stages available when a real pipeline gives them semantics.

Mentioned in: 3. The shared shader language is trapped inside the SPIR-V backend, Lower one mathematical shader directly to MSL

Target-specific lowering stays open and inspectable #JDLQPN

The CLOS seam is target × source construct, not one growing target switch. The intended relationship is illustrated by:

Target objects are justified when they carry version, capability, platform, or binding-layout policy; an EQL keyword is enough while target choice is only a closed setting. Dense instruction and text data remain data.

The MSL product should be a modest structured document of declarations, entry-point parameters, statements, and source occurrences rather than one opaque accumulated string or a general C AST. The shader lab should be able to select a Lisp expression and show the MSL it caused just as it shows SPIR-V instruction occurrences. Unsupported target operations should signal a source-located shader-language condition rather than silently approximate.

Mentioned in: Lower one mathematical shader directly to MSL

Generated MSL remains a view of semantic objects #YA4KDP

Generated source is useful to read, but it is not a new semantic store. The MSL fields, parameters, local statements, and output statements retain the declaration, resource, binding, or assignment which produced them. Rendering asks those existing #C6E3LA objects for their quantity specification or component layout and writes a short English explanation beside the ordinary Metal representation. Missing annotations remain visible rather than being inferred from a nearby use.

This establishes one more provenance link beneath #58IDSR:

shader declaration or binding
        | identity retained by
        v
structured MSL node ---- renders ----> comment + Metal declaration
        |
        `---- may later record ----> exact source range

The existing expression occurrences retain an expression and its rendered text, but not yet the final character range in the document. A useful next tooling step is therefore small: let the renderer record half-open ranges for fields, statements, comments, and expression occurrences. The shader lab can then move in either direction between a visible piece of generated MSL and the live semantic object which explains it. Type aliases may later improve the spelling of homogeneous quantities, but they do not replace this relation and cannot describe heterogeneous lane layouts.

The Metal 4 compiler belongs to the live backend #2X8254

The running backend should compile through MTL4Compiler rather than make xcrun metal, temporary files, or subprocess management part of live Lisp. The compiler is a device-owned object which accepts source-bearing MTL4LibraryDescriptor objects and creates library and pipeline products.

The first path should be synchronous: a candidate owns its MSL document, source, library, descriptors, and pipeline state until the complete artifact can publish at the frame boundary. The currently installed artifact remains untouched on failure. Only after that transaction works should asynchronous compiler tasks, Objective-C blocks, archives, or warm-start serializers enter the required path.

That first compiler boundary is now executable. metal-gpu-device owns one MTL4Compiler beside its queue. Creating a shader module from a descriptor whose language is :mathematical lowers the specification to an msl-document, passes its source through an in-memory MTL4LibraryDescriptor with language version 4.0, verifies the named function and stage, and retains the document, library, entry point, and function type as one inspectable module artifact. Native rejection copies NSError text into a metal-gpu-error without poisoning the compiler.

The next compiler boundary is executable too. metal-gpu-render-pipeline checks that both shader modules belong to the device and have the required stages, translates the HAL's 48-byte vertex layout into an MTLVertexDescriptor, names both library functions with MTL4LibraryFunctionDescriptor objects, and synchronously creates an MTLRenderPipelineState. Its depth comparison and write policy are retained as a draw-time MTLDepthStencilState. The pipeline product no longer retains the temporary native descriptors, while its owned native states are released explicitly by destroy.

xcrun metal remains useful as an offline diagnostic and cross-check. It is not the acceptance authority for a live pipeline.

Mentioned in: Lower one mathematical shader directly to MSL

The second backend tests apparently portable names #OV1AZO

The Metal slice is allowed to reveal target-shaped vocabulary rather than declare the existing surface neutral in advance:

• shader-resource currently says descriptor set and binding, while Metal 4 argument tables distinguish resource categories, IDs, and GPU addresses;
• interface locations and built-ins become MSL entry-point structures and attributes rather than SPIR-V decorations;
• shader-module-descriptor/language now distinguishes :spir-v, :mathematical, and the Metal-side :msl document escape hatch. Both devices accept :mathematical and own their target lowering; raw words and documents remain explicitly named artifacts rather than inferred slot types;
• vertex, fragment, and compute form the proved shared stage core, while mesh/object stages should follow a concrete native pipeline; and
• Metal publication must preserve the existing revision, last-known-good, frame-boundary, and deferred-retirement semantics.

Names should change only when this second implementation supplies evidence. #58IDSR is the first deliberate test.

Mentioned in: Lower one mathematical shader directly to MSL

The first live pipeline is the backend threshold #DR3V60

The backend becomes a complete rendering alternative when one unchanged shader-specification-for method can feed both target compilers and the Metal artifact preserves live publication semantics.

One implementation sequence owns that threshold: #58IDSR has proved direct MSL source and compiler acceptance; #PH57K5 now joins that product to the existing canvas and transactional live-pipeline lifecycle. Moppe remains visual and API evidence, not the owner of luv's implementation roadmap.

Mentioned in: Structural shader-type identity