Re:OpenGL is getting mesh shaders as well, via GL_EXT_mesh_s...
by pjmlp on Saturday October 11, 2025 @07:50AM
(#45548416)
Because not everyone doing 3D graphics is implementing AAA rendering engines on RTX cards.
The ANARI effort was born exactly because the visualisation industry refusal to adopt Vulkan as is.
Re:OpenGL is getting mesh shaders as well, via GL_EXT_mesh_s...
by flohofwoe on Saturday October 11, 2025 @07:58AM
(#45548464)
Looking at the ANARI spec and SDK it looks pretty much like a typical C API to me, implementing an old-school scene-graph system. What am I missing - e.g. what makes it specifically well suited for non-C languages? :)
If anything it looks more like an admission by Khronos that Vulkan wasn't such a great idea (but a 3D API that's based on scene graphs isn't either, so I'm not sure what's so great about ANARI tbh).
Re:OpenGL is getting mesh shaders as well, via GL_EXT_mesh_s...
by pjmlp on Saturday October 11, 2025 @09:36AM
(#45549031)
Python is part of ANARI value proposal, and the standard takes this into account.
https://github.com/KhronosGroup/ANARI-SDK/tree/next_release/...
Re:OpenGL is getting mesh shaders as well, via GL_EXT_mesh_s...
by fulafel on Tuesday October 14, 2025 @12:23AM
(#45576236)
At first blush it looks like it supports writing C in Python more than going along the grain of the managed nature:
status_handle = ffi.new_handle(anari_status) #something needs to keep this handle alive
Why not though? In the end an API call is an API call, and everything is compiled down to machine code no matter what the source language is.
FWIW, the high-level "OOP-isms" of the Metal API is also its biggest downside. Even simple create-option "structs" like MTLRenderPassDescriptor are fully lifetime-managed Objective-C objects where every field access is a method call - that's simply unnecessary overkill.
And ironically, the most binding-friendly API for high-level languages might still be OpenGL, since this doesn't have any structs or 'objects with methods', but only plain old function calls with primitive-type parameters and the only usage of pointers is for pointing to unstructured 'bulk data' like vertex-buffer- or texture-content, this maps very well even to entirely un-C-like languages - and the changes that WebGL did to the GL API (for instance adding 'proper' JS objects for textures and buffers) are arguably a step back compared to native GL where those resource objects are just opaque handles.