[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-95936":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":15,"stars30d":16,"stars90d":15,"forks30d":15,"starsTrendScore":15,"compositeScore":17,"rankGlobal":9,"rankLanguage":9,"license":18,"archived":19,"fork":19,"defaultBranch":20,"hasWiki":21,"hasPages":19,"topics":22,"createdAt":9,"pushedAt":9,"updatedAt":23,"readmeContent":24,"aiSummary":25,"trendingCount":15,"starSnapshotCount":15,"syncStatus":26,"lastSyncTime":27,"discoverSource":28},95936,"NoGraphicsAPI","sebbbi\u002FNoGraphicsAPI","sebbbi","Minimal graphics API. Built on top of latest Vulkan extensions. As close as possibly to my \"No Graphics API\" blog post and the SIGGRAPH talk.",null,"C++",812,20,10,1,0,198,7.97,"MIT License",false,"main",true,[],"2026-09-21 02:04:29","# NoGraphicsAPI\n\n`NoGraphicsAPI` is an experimental Vulkan 1.4 implementation of the ideas in Sebastian Aaltonen's\n[*No Graphics API*](https:\u002F\u002Fwww.sebastianaaltonen.com\u002Fblog\u002Fno-graphics-api). It explores how much of\na conventional graphics API disappears when shaders use 64-bit GPU pointers, texture and sampler\ndescriptors live in application-owned GPU memory, and synchronization describes hazards instead of\nresource state.\n\nThe Vulkan backend is implemented and exercised by three example applications. Metal support is not\nimplemented; [the Metal 4 design](docs\u002Fmetal-porting.md) records the proposed mapping and open issues.\n\n## How it maps to *No Graphics API*\n\n- **GPU pointers replace buffer objects and bindings.** `create_gpu_heap()` returns a raw allocation\n  with a GPU address and, for mapped memory, a CPU address. Address-based commands consume\n  `GpuRange {gpu, size}` directly, and shaders follow typed 64-bit pointers for vertex fetch and\n  arbitrary data structures.\n- **Applications own descriptor heaps.** Texture and sampler descriptor heaps are mapped GPU heaps.\n  The application chooses slots, writes descriptors through the CPU address, binds the GPU range,\n  and passes 32-bit indices to shaders.\n- **Root data is one small payload.** A shared C++\u002FSlang structure is copied with\n  `vkCmdPushDataEXT` for each draw or dispatch. Its pointer fields are GPU addresses. Unlike the\n  blog's GPU-resident, stage-specific roots, graphics stages share one CPU-supplied root.\n- **Barriers describe execution and memory hazards.** The public API exposes global stage\u002Faccess\n  barriers, not per-resource transition lists. Normal textures remain in one unified layout.\n- **Pipeline binding state stays small.** There are no public buffer objects, descriptor sets,\n  descriptor layouts, pipeline layouts, or sampler objects. Viewport, scissor, and exposed\n  depth\u002Fstencil behavior are command state rather than PSO permutations, while data arrives through the root and descriptor heaps.\n- **Submission is explicit and asynchronous.** Applications provide timeline points for reuse and\n  deferred destruction. Submitted command buffers are one-shot.\n\nThe [design comparison](docs\u002Fno-graphics-api-comparison.md) separates faithful mappings, Vulkan-driven\ndifferences, and features that remain outside the prototype.\n\n## Vulkan realization\n\nThe backend intentionally creates no `VkDescriptorSetLayout`, `VkDescriptorPool`, `VkDescriptorSet`,\nor `VkPipelineLayout`. Its central extensions are:\n\n- `VK_EXT_descriptor_heap` for application-owned resource\u002Fsampler heaps and `vkCmdPushDataEXT`;\n- `VK_KHR_device_address_commands` for address-based index, indirect, and copy commands;\n- `VK_KHR_shader_untyped_pointers` as the descriptor-heap SPIR-V prerequisite;\n- `VK_KHR_unified_image_layouts`, when available, to optimize ordinary texture access in\n  `VK_IMAGE_LAYOUT_GENERAL`;\n- `VK_EXT_mesh_shader` for mesh pipelines and dispatch.\n\nNoGraphicsAPI is a low-level, thin Vulkan wrapper. Debug builds enable `VK_EXT_debug_utils` and the\nKhronos validation layer when available.\n\nVulkan 1.4 supplies buffer device addresses, timeline semaphores, dynamic rendering,\nsynchronization2, scalar block layout, and the remaining core features. See\n[Vulkan support](docs\u002Fvulkan-support.md) for the concise feature and command mapping.\n\n## GPU memory and descriptor heaps\n\nThere are no public buffer objects or internal suballocators. Applications own data and descriptor\nheaps; optimal-tiled textures use separate GPU-only heaps. The optional utility library provides\napplication-side data and texture allocation policies.\n\n`GpuRange` is the non-owning address\u002Fsize view used by commands. Texture and sampler descriptors are\naddressed in Slang through the standard heap syntax:\n\n```slang\nTexture2D\u003Cfloat4> texture = ResourceDescriptorHeap[texture_index];\nSamplerState sampler = SamplerDescriptorHeap[sampler_index];\nfloat4 texel = texture.Sample(sampler, uv);\n```\n\n## Shared root ABI\n\nShared scalar, vector, and matrix types come from `\u003CNoGraphicsAPIUtility\u002Fshader_types.h>`. Root\nstructures are declared once and included by C++ and Slang:\n\n```cpp\nstruct RootArguments\n{\n    Vertex* vertices;\n    float4x4 mvp;\n};\n```\n\nOn the CPU, pointer fields receive GPU virtual addresses while ordinary values are copied directly:\n\n```cpp\nGpuCpuRange\u003CVertex> vertex_memory = bump_allocator.allocate\u003CVertex>(vertex_count);\nRootArguments root{\n    .vertices = vertex_memory.gpu,\n    .mvp = mvp,\n};\ngpu::draw(commands, root, vertex_count);\n```\n\nSlang declares the same root as push-constant data and reads both pointer and value fields directly:\n\n```slang\n[[vk::push_constant]] ConstantBuffer\u003CRootArguments> root;\n\nVertex vertex = root.vertices[vertex_id];\nfloat4x4 mvp = root.mvp;\n```\n\nThe draw or dispatch copies the root bytes immediately through `vkCmdPushDataEXT`; the root does not\nneed to outlive the call. Shared structures use C layout, and matrix-bearing roots use row-major matrix\nlayout. Root values must be trivially copyable, have a size divisible by four, and be no larger than\n`DeviceCaps::max_push_data_size`.\n\nPublic descriptor structures have useful defaults. Call sites use C++20 designated initializers to\nname only fields that differ from those defaults. `Span` and `ByteSpan` are non-owning pointer\u002Fcount\nviews used for function inputs.\n\nThe full shader-side contract is in the [Slang shader contract](docs\u002Fslang.md).\n\n## Build and run\n\nRequirements:\n\n- CMake 3.24+, a C++20 compiler, and Vulkan SDK headers and development libraries version 1.4.357\n  or newer;\n- a little-endian x86-64 target; the optional utility math target additionally requires AVX2 and FMA;\n- a Vulkan 1.4 loader and device exposing the required descriptor-heap, device-address-command,\n  untyped-pointer, and mesh extensions above, plus their required BDA, synchronization, and\n  16-bit\u002Fscalar-layout features;\n- coherent CPU-visible GPU memory through a PCIe BAR on a discrete GPU or UMA on an integrated GPU,\n  plus device-local memory compatible with the supported buffers and textures;\n- Slang 2026.14.1+ and SPIRV-Tools 2026.3+ when building the examples.\n\nMSVC and clang-cl are supported on Windows. GNU and Clang can build the headless library on other\nplatforms. MinGW, 32-bit x86, and ARM targets are not supported.\n\nThe utility implementation is shipped in-tree, so configuration has no Git or network dependency.\nThe default configuration builds NoGraphicsAPI and its companion utility library. Examples and tests\nare opt-in so embedding NoGraphicsAPI with `add_subdirectory()` does not add development targets:\n\n```sh\ncmake -S . -B build -DCMAKE_BUILD_TYPE=Release\ncmake --build build\ncmake --install build --prefix path\u002Fto\u002Finstall\n```\n\nThe same install provides independent `NoGraphicsAPI` and `NoGraphicsAPIUtility` packages:\n\n```cmake\nfind_package(NoGraphicsAPI CONFIG REQUIRED)\nfind_package(NoGraphicsAPIUtility CONFIG REQUIRED)\ntarget_link_libraries(my_application PRIVATE\n    NoGraphicsAPI::NoGraphicsAPI\n    NoGraphicsAPIUtility::math\n    NoGraphicsAPIUtility::textures)\n```\n\nNoGraphicsAPIUtility provides shared C++\u002FSlang types, math, data and texture suballocation, and a\ntimeline-driven `DeleteQueue`. These are optional application-side policies; NoGraphicsAPI does not\ndepend on them. The queue delays allocator reuse and resource destruction until the application\ntimeline completes. `BumpAllocator::allocate_atomic()` supports relaxed-atomic concurrent reservations from worker threads.\n\nFor repository development on Windows, enable the examples and tests explicitly. Building examples\nrequires the Slang and SPIR-V Tools versions listed above.\n\n```sh\ncmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DNOGRAPHICSAPI_BUILD_EXAMPLES=ON -DNOGRAPHICSAPI_BUILD_TESTS=ON\ncmake --build build\nctest --test-dir build --output-on-failure\n```\n\nThe Windows examples use the normal swapchain path:\n\n- [`triangle`](examples\u002Ftriangle\u002Ftriangle.cpp): the minimum vertex\u002Ffragment draw and presentation path;\n- [`cube`](examples\u002Fcube\u002Fcube.cpp): typed GPU-pointer vertex fetch plus application-owned texture and\n  sampler heaps;\n- [`deferred_renderer`](examples\u002Fdeferred_renderer\u002Fdeferred_renderer.cpp): GPU-compute simulation and\n  mesh-shader rendering in a multi-pass workload with pointer-based scene data, barriers between\n  passes, and timeline-managed CPU\u002FGPU overlap.\n\nThey can be run from their corresponding directories under `build\u002Fexamples` when\n`NOGRAPHICSAPI_BUILD_EXAMPLES` is enabled.\n\n## Hardware support\n\nDriver support was checked on 5 September 2026 against the latest available packages; linked reports\nare representative snapshots. `create_device()` remains authoritative; Vulkan 1.4 alone does not\nprovide the required new extensions.\n\nThe latest available Windows drivers are [AMD Adrenalin 26.9.1](https:\u002F\u002Fwww.amd.com\u002Fen\u002Fresources\u002Fsupport-articles\u002Frelease-notes\u002FRN-RAD-WIN-26-9-1.html)\nand [NVIDIA 616.64 WHQL](https:\u002F\u002Fus.download.nvidia.com\u002FWindows\u002F616.64\u002F616.64-win11-win10-release-notes.pdf).\n\n| Architecture | Current driver | Products | CPU-visible heap | Required extensions |\n| --- | --- | --- | --- | --- |\n| AMD RDNA 2 (dGPU) | Windows \u002F Adrenalin 26.9.1 | [RX 6000][rdna2-rebar] | PCIe ReBAR or\u003Cbr>🔴 [256 MiB fixed BAR][rdna2-fixed] | 🔴 Unsupported |\n| AMD RDNA 2 (iGPU) | Windows \u002F Adrenalin 26.9.1 | [600M](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=47714) | UMA | 🔴 Unsupported |\n| AMD RDNA 2 (iGPU) | Linux \u002F Mesa RADV 26.2+ | [Steam Deck](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51189) | UMA | Supported |\n| AMD RDNA 3 (dGPU) | Windows \u002F Adrenalin 26.9.1 | [RX 7000](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51443) | PCIe ReBAR | Supported |\n| AMD RDNA 3 (iGPU) | Windows \u002F Adrenalin 26.9.1 | [700M](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=49646) | UMA | Supported |\n| AMD RDNA 4 (dGPU) | Windows \u002F Adrenalin 26.9.1 | [RX 9000](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51293) | PCIe ReBAR | Supported |\n| NVIDIA Turing | Windows \u002F NVIDIA 616.64 | [GTX 1600][gtx16] | 🔴 [256 MiB fixed BAR][turing-rebar] (214 MiB exposed) | Supported |\n| NVIDIA Turing | Windows \u002F NVIDIA 616.64 | [RTX 2000][turing] | 🔴 [256 MiB fixed BAR][turing-rebar] (214 MiB exposed) | Supported |\n| NVIDIA Ampere | Windows \u002F NVIDIA 616.64 | [RTX 3000](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51549) | PCIe ReBAR | Supported |\n| NVIDIA Ada Lovelace | Windows \u002F NVIDIA 616.64 | [RTX 4000](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51469) | PCIe ReBAR | Supported |\n| NVIDIA Blackwell | Windows \u002F NVIDIA 616.64 | [RTX 5000](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51573) | PCIe ReBAR | Supported |\n\n🔴 marks missing required extensions or a capacity-limited fixed BAR. All checked ReBAR GPUs expose\ntheir main VRAM heap as CPU-visible; availability depends on platform firmware. A fixed BAR can still\nsatisfy the memory requirement, but limits the default CPU-visible heaps; GPU-only allocations\ncan use separate VRAM.\n\nChecked UMA heap sizes are 5.1 GiB on a Windows\n[Radeon 680M](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=47714), 5.8 GiB on\n[Steam Deck](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51189), and 21.2 GiB on a Windows\n[Radeon 780M](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=49646); they vary with system configuration.\n\nCurrent Windows RDNA 2 reports lack `VK_EXT_descriptor_heap`; the checked RDNA 3 and RDNA 4 AMD GPUs\nand all listed NVIDIA GPUs advertise every required extension. With Mesa\n[RADV 26.2 or newer](https:\u002F\u002Fdocs.mesa3d.org\u002Frelnotes\u002F26.2.0.html), Steam Deck also has all required\nextensions. Linux\u002FSteamOS window presentation is not implemented yet and is planned for a near-term update.\n\n🔴 [Pascal \u002F GeForce GTX 10](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51084) is below the NVIDIA\nfloor: it lacks all four new extensions and exposes a 214 MiB fixed BAR.\n\nIntel Windows support is not verified. The latest public\n[Arc report](https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51355) lacks the descriptor-heap,\ndevice-address-command, and shader-untyped-pointer extensions. Mesa ANV\n[26.2 or newer](https:\u002F\u002Fdocs.mesa3d.org\u002Frelnotes\u002F26.2.0.html) exposes the required extensions on Linux,\nbut this repository currently lacks Linux swap chain support (to be implemented).\n\n[rdna2-rebar]: https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=42800\n[rdna2-fixed]: https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=48951\n[gtx16]: https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51563\n[turing]: https:\u002F\u002Fvulkan.gpuinfo.org\u002Fdisplayreport.php?id=51475\n[turing-rebar]: https:\u002F\u002Fwww.nvidia.com\u002Fen-us\u002Fgeforce\u002Fgraphics-cards\u002Fcompare\u002F?section=compare-specs\n\n## Current scope\n\nThe library has been reviewed with GPT-6 Astra Ultra, but remains a prototype and may contain bugs. Please report issues.\n\nImplemented today: graphics, mesh, and compute PSOs; direct and indirect work; GPU-address copies;\napplication-owned descriptor heaps; common texture types and views; dynamic rendering and\nviewport\u002Fscissor\u002Fdepth-stencil state; global barriers; timeline submission; deferred destruction; and Win32 presentation.\n\nThis is a deliberately single-threaded, single-queue graphics API. Ray tracing, task shaders, sparse memory,\ndevice-generated command graphs beyond the existing indirect operations, pipeline caching, MSAA, non-Win32\npresentation, and a Metal backend are outside the current implementation. The public header remains the source\nof truth for the exact API surface.\n\nFurther reading:\n\n- [Comparison with *No Graphics API*](docs\u002Fno-graphics-api-comparison.md)\n- [Vulkan extension and command mapping](docs\u002Fvulkan-support.md)\n- [Slang shader contract and root ABI](docs\u002Fslang.md)\n- [Proposed Metal 4 port](docs\u002Fmetal-porting.md)\n\n## License\n\nNoGraphicsAPI and NoGraphicsAPIUtility are distributed under the [MIT License](LICENSE). The cube\nexample's texture is derived from Vulkan-Tools and is redistributed under Apache-2.0. See\n[third-party notices](THIRD_PARTY_NOTICES.md) for complete attribution and license details.\n","NoGraphicsAPI 是一个实验性的极简图形 API 实现，基于 Vulkan 1.4 及其最新扩展，旨在践行“无图形 API”理念：通过 GPU 64 位指针替代传统资源绑定、应用自管描述符堆、以危害模型（hazard-based）取代显式资源状态转换、并大幅削减管线对象与描述符集等抽象层。其核心特点是零 VkDescriptorSetLayout\u002FVkPipelineLayout 创建、依赖 VK_EXT_descriptor_heap 和 VK_KHR_device_address_commands 等扩展，支持地址直访、推送根数据与统一图像布局。适用于图形引擎底层研发、GPU 编程范式研究及 Vulkan 新特性验证等技术探索场景。",2,"2026-09-07 02:30:03","CREATED_QUERY"]