OpenGL is getting mesh shaders as well, via GL_EXT_mesh_shader

https://www.supergoodcode.com/mesh-shaders-in-the-current-year/

66•pjmlp•4h ago

Comments

prideout•2h ago

Why is Minecraft mentioned several times in the post?

wirybeige•2h ago

The post links to this: https://github.com/MCRcortex/nvidium

nvidium is using GL_NV_mesh_shader which is only available for nVIDIA cards. This mod is the only game/mod I know of that uses mesh shaders & is OpenGL. & so the new gl extension will let users of other vendors use the mod if it gets updated to use the new extension.

mellinoe•2h ago

Presumably because Minecraft is the only application which still uses OpenGL but would use the extension

doubletwoyou•2h ago

pretty sure the base minecraft rendering engine is still using opengl, and most of the improvement mods also just use opengl so exposing this extension to them is probably important to a game where its 50 billion simple cubes being rendered

FrustratedMonky•2h ago

Is Minecraft the only thing using OpenGL anymore?

What is the current state of OpenGL, I thought it had faded away?

aj_hackman•2h ago

It's officially deprecated in favor of Vulkan, but it will likely live on for decades to come due to legacy CAD software and a bunch of older games still using it. I don't share the distaste many have for it, it's good to have a cross-platform medium-complexity graphics API for doing the 90% of rendering that isn't cutting-edge AAA gaming.

m-schuetz•2h ago

OpenGL is going to live a long life simply because Vulkan is way more complex and overengineered than it needs to be.

jsheard•1h ago

It's steadily getting better as they keep walking back aspects which turned out to be needlessly complex, or only needed to be complex for the sake of older hardware that hardly anyone cares about anymore, but yeah there's still a way to go. Those simpler ways of doing things are just grafted onto the side of the existing API surface so just knowing which parts you're supposed to use is a battle in itself. Hopefully they'll eventually do a clean-slate Vulkan 2.0 to tidy up the cruft, but I'm not getting my hopes up.

m-schuetz•1h ago

Might be getting better but just yesterday I dabbled in Vulkan again, digging through the examples from https://github.com/SaschaWillems/Vulkan, and the complexity is pure insanity. What should be a simple malloc ends up being 40 lines of code, what should be a simple memcpy is another 30 lines of code, and what should be a single-line kernel launch is another 50 lines of bindings, layouts, pipelines, etc.

flohofwoe•1h ago

Tbf, a lot of the complexity (also in the official Khronos samples) is caused by insane C++ abstraction layers and 'helper frameworks' on top of the actual Vulkan C API.

Just directly talking to the C API in the tutorials/examples instead of custom wrapper code would be a lot more helpful since you'd don't need to sift through the custom abstraction layers (even if it would be slightly more code).

E.g. have a look at the code snippets in here and weep in despair ;)

https://docs.vulkan.org/tutorial/latest/03_Drawing_a_triangl...

jplusequalt•1h ago

Why should these things be simple? Graphics hardware varies greatly even across generations from the same vendors. Vulkan as an API is trying to offer the most functionality to as much of this hardware as possible. That means you have a lot of dials to tweak.

Trying to obfuscate all the options goes against what Vulkan was created for. Use OpenGL 4.6/WebGPU if you want simplicity.

flohofwoe•1h ago

A simple vkCreateSystemDefaultDevice() function like on Metal instead of requiring hundreds of lines of boilerplate would go a long way to make Vulkan more ergonomic without having to give up a more verbose fallback path for the handful Vulkan applications that need to pick a very specific device (and then probably pick the wrong one on exotic hardware configs).

And the rest of the API is full of similar examples of wasting developer time for the common code path.

Metal is a great example of providing both: a convenient 'beaten path' for 90% of use cases but still offering more verbose fallbacks when flexibility is needed.

Arguably, the original idea to provide a low-level explicit API also didn't quite work. Since GPU architectures are still vastly different (especially across desktop and mobile GPUs), a slightly more abstract API would be able to provide more wiggle room for drivers to implement an API feature more efficiently under the hood, and without requiring users to write different code paths for each GPU vendor.

jplusequalt•1h ago

Metal has the benefit of being developed by Apple for Apple devices. I'd imagine that constraint allows them to simplify code paths in a way Vulkan can't/won't. Again, Metal doesn't have to deal with supporting dozens of different hardware systems like Vulkan does.

flohofwoe•1h ago

Metal also works for external GPUs like NVIDIA or AMD though (not sure how much effort Apple still puts into those use cases, but Metal itself is flexible enough to deal with non-Apple GPUs).

m-schuetz•1h ago

CUDA can be complex if you want, but it offers more powerful functionality as an option that you can choose, rather than mandating maximum complexity right from the start. This is where Vulkan absolutely fails. It makes everything maximum effort, rather than making the common things easy.

jplusequalt•1h ago

I think CUDA and Vulkan are two completely different beasts, so I don't believe this is a good comparison. One is for GPGPU, and the other is a graphics API with compute shaders.

Also, CUDA is targeting a single vendor, whereas Vulkan is targeting as many platforms as possible.

m-schuetz•35m ago

The point still stands: Vulkan chose to go all-in on mandatory maximum complexity, instead of providing less-complex routes for the common cases. Several extensions in recent years have reduced that burden because it was recognized that this is an actual issue, and it demonstrated that less complexity would have been possible right from the start. Still a long way to go, though.

pjmlp•1h ago

Yes, recent example, the board getting released by Qualcomm after acquiring Arduino.

Between OpenGL ES 3.1 and Vulkan 1.1, I would certainly go with OpenGL ES.

Narishma•55m ago

Oh I didn't know the new Arduino board had a GPU. Do we know what kind?

pjmlp•40m ago

Yes, Adreno 702

https://www.qualcomm.com/products/internet-of-things/robotic...

flohofwoe•1h ago

Vulkan (1.0 at least) being a badly designed API doesn't mean that OpenGL will be maintained unfortunately. Work on OpenGL pretty much stopped in 2017.

m-schuetz•1h ago

I am sadly aware, but I won't switch until the complexity is fixed. Although I did kind of switch, but to CUDA because the overengineered complexity of Vulkan drove me away. I'm neither smart nor patient enough for that. What should be a malloc is a PhD thesis in Vulkan, what should be a memcpy is another thesis, and what should be a simple kernel launch is insanity.

jplusequalt•1h ago

I don't doubt OpenGL will live forever. But Vulkan 1.3/1.4 is not as bad as people make it out to be.

m-schuetz•1h ago

So I've been told so I'm trying to take another look at it. At least the examples at https://github.com/SaschaWillems/Vulkan, which are probably not 1.3/1.4 yet except for the trianglevulkan13 example, are pure insanity. Coming from CUDA, I can't fathom why what should be simple things like malloc, memcpy and kernel launches, end up needing 300x as many lines.

jplusequalt•56m ago

In part, because Vulkan is a graphics API, not a GPGPU framework like CUDA. They're entirely different beasts.

Vulkan is also trying to expose as many options as possible so as to be extensible on as many platforms as possible. Also, Vulkan isn't even trying to make it more complex than it need be--this is just how complex graphics programming is period. The only reasons people think Vulkan/DX12 are overly complicated is because they're used to using APIs where the majority of the heavy lifting comes from the drivers.

flohofwoe•35m ago

> In part, because Vulkan is a graphics API, not a GPGPU framework like CUDA. They're entirely different beasts.

Tbf, the distinction between rendering and compute has been disappearing for quite a while now, apart from texture sampling there isn't much reason to have hardware that's dedicated for rendering tasks on GPUs, and when there's hardly any dedicated rendering hardware on GPUs, why still have dedicated rendering APIs?

Cieric•1h ago

> It's officially deprecated in favor of Vulkan

Can you provide a reference for this? I work in the GPU driver space (not on either of these apis), but from my understanding Vulkan wasn't meant to replace OpenGL, it was only introduced to give developers the chance at getting lower level in the hardware (still agnostic from the hardware, at least compared to compiling PTX/CUDA or against AMD's PAL directly, many still think they failed.) I would still highly advocate for developers using OpenGL or dx11 if their game/software doesn't need the capabilities of Vulkan or dx12. And even if you did, you might be able to get away with interop and do small parts with the lower api and leave everything else in the higher api.

I will admit I don't like the trend of all the fancy new features only getting introduced into Vulkan and dx12, but I'm not sure how to change that trend.

ecshafer•1h ago

I only play with this stuff as a hobbiest. But OpenGL is way more simple than Vulkan I think. Vulkan is really really complicated to get some basic stuff going.

marmarama•1h ago

Which is as-designed. Vulkan (and DX12, and Metal) is a much more low-level API, precisely because that's what professional 3D engine developers asked for.

Closer to the hardware, more control, fewer workarounds because the driver is doing something "clever" hidden behind the scenes. The tradeoff is greater complexity.

Mere mortals are supposed to use a game engine, or a scene graph library (e.g. VulkanSceneGraph), or stick with OpenGL for now.

The long-term future for OpenGL is to be implemented on top of Vulkan (specifically the Mesa Zink driver that the blog post author is the main developer of).

genpfault•57m ago

> specifically the Mesa Zink driver

https://docs.mesa3d.org/drivers/zink.html

flohofwoe•56m ago

> fewer workarounds because the driver is doing something "clever" hidden behind the scenes.

I would be very surprised if current Vulkan drivers are any different in this regard, and if yes then probably only because Vulkan isn't as popular as D3D for PC games.

Vulkan is in a weird place that it promised a low-level explicit API close to the hardware, but then still doesn't really match any concrete GPU architecture and it still needs to abstract over very different GPU architectures.

At the very least there should have been different APIs for desktop and mobile GPUs (not that the GL vs GLES split was great, but at least that way the requirements for mobile GPUs don't hold back the desktop API).

And then there's the issue that also ruined OpenGL: the vendor extension mess.

m-schuetz•39m ago

> Closer to the hardware

To what hardware? Ancient desktop GPUs vs modern desktop GPUs? Ancient smartphones? Modern smartphones? Consoles? Vulkan is an abstraction of a huge set of diverging hardware architectures.

And a pretty bad one, on my opinion. If you need to make an abstraction due to fundamentally different hardware, then at least make an abstraction that isn't terribly overengineered for little to no gain.

flohofwoe•1h ago

> Can you provide a reference for this?

The last OpenGL release 4.6 was in 2017... I think that speaks for itself ;)

And at least on macOS, OpenGL is officially deprecated, stuck at 4.1 and is also quickly rotting (despite running on top of Metal now - but I don't think anybody at Apple is doing serious maintenance work on their OpenGL implementation).

aj_hackman•1h ago

I've never been able to successfully create a GL context > version 2.1, or invoke the GLSL compiler.

As a sidenote, I've very much enjoyed your blog, and developed a similar handle system as yours around the same time. Mine uses 32 bits though - 15 for index, 1 for misc stuff, 8 for random key, and 8 for object type :^)

jlokier•38m ago

Recent versions of macOS will provide either an OpenGL 2.1 context or OpenGL 4.1 context, depending on how you request the context. You have to request a 3.2+ core profile, and not use X11 or the glX* functions.

From macOS 10.7 to 10.9, you'd get an OpenGL 3.2 context. As OpenGL 4.1 is backward compatible to OpenGL 3.2, it's fine that the same code gets OpenGL 4.1 now.

Basically, macOS will provide an "old" API to programs that need it, which is fixed at 2.1, and a "modern" API to programs that know how to ask for it, which has settled at 4.1 and is unlikely to change.

OpenGL 4.1 is harmonised with OpenGL ES 2.0. Almost the same rendering model, features, extensions, etc. On iOS, iPadOS etc you can use OpenGL ES 2.0, and no version of OpenGL (non-ES), so my guess is that's why macOS settled on OpenGL 4.1. Both platforms offer the same OpenGL rendering features, but through slightly different APIs.

But if you request 4.1 over GLX (which uses X11/Xorg/XQuartz), the X11 code only supports OpenGL 2.1. For example, if you're porting some Linux code or other GLX examples over.

Unfortunately, the GLX limitation is probably just due to the Xorg-based XQuartz being open source but only minimally maintained since before OpenGL 3.2 was added to macOS. XQuartz uses Xorg and Mesa, which have all the bindings for 4.1, but some of them are not quite wired up.

fulafel•56m ago

That's not "OpenGL is officially deprecated".

flohofwoe•38m ago

In the end, if nobody is maintaining the OpenGL standard, implementations and tooling it doesn't matter much whether it is officially deprecated or just abandondend.

fulafel•14m ago

.. but people ARE maintaining the implementations and tooling even if the spec might not be getting new features aside from extensions. There's a difference.

Look at Mesa release notes for example, there's a steady stream of driver feature work and bugfixes for GL: https://docs.mesa3d.org/relnotes/25.2.0.html (search for "gl_")

People are writing new OpenGL code all the time. See eg HN story sumbmissions: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

aj_hackman•1h ago

The universal narrative around OpenGL is that it's deprecated, so I assumed that came with a thumbs-up from Khronos. In any case, I'm not holding my breath for GL > 4.6.

jplusequalt•1h ago

I think Vulkan was originally called OpenGL Next. Furthermore, Vulkan's verbosity allows for a level of control of the graphics pipeline you simply can't have with OpenGL, on top of having built in support for things like dynamic rendering, bindless descriptors, push constants, etc.

Those are the main reasons IMO why most people say it's deprecated.

fulafel•51m ago

OpenGL in the form of WebGL is living its best life.

It's the only way to ship portable 3D software across the desktop and mobile platforms without platform specific code paths, thanks to the API fragmentation and proprietary platform antics from our beloved vendors.

In some years WebGPU may mature and start gaining parity (webgl took a looooong time to mature), and after that it'll still take more years for applications to switch given older hardware, the software inertia needed to port all the middleware over etc.

m-schuetz•44m ago

There is also the problem that WebGPU doesn't really add much except for compute shaders. Older WebGL apps have hardly any reason to port. Other problem is that WebGPU is even worse outdated than WebGL was at its release. When WebGL was released, it was maybe 5 years outdated. WebGPU somewhat came out in major desktop browsers this year, and by now it's something like 15 years behind the state of the art. OpenGL, which got de facto deprecated more than half a decade ago, is orders of magnitude more powerful with respect to hardware capabilities/features than WebGPU.

conradev•8m ago

Someone should tell Qualcomm then: https://www.qualcomm.com/developer/blog/2024/11/introducing-...

I believe the llama.cpp Vulkan backend is inoperable on Adreno GPUs

fulafel•2m ago

That's OpenCL, not OpenGL.

kbolino•1h ago

I don't think any major platform that ever supported OpenGL or OpenGL ES--including desktops, smartphones/tablets, and web browsers--has actually removed it yet. Apple will probably be the first to pull the plug, but they've only aggressively deprecated it so far.

jhasse•1h ago

How exactly is it aggressiv? I'm selling games using OpenGL on iOS, iPadOS, tvOS and macOS, works with all of their latest hardware. I'm not getting a warning or any sign from them that they will remove support.

kbolino•25m ago

It was my understanding (which could definitely be wrong) that their OpenGL support is both behind the times--which is impressive since OpenGL has received no major new features AFAIK in the past decade, the topic of this HN post notwithstanding--and won't even get any bugfixes.

Sharlin•10m ago

It's super frequently recommended as a starting point for learners because it's high level enough to get something on the screen in ten lines of code but low level enough to teach you the fundamentals of how the rendering pipeline works (even though GL's abstraction is rather anachronistic and differs from how modern GPUs actually work). Vulkan (requiring literally a thousand LoC worth of initialization to render a single triangle) is emphatically not any sort of replacement for that use case (and honestly not for 95% of hobbyist/indie use cases either unless you use a high-level abstraction on top of it).

The worst thing about OpenGL is probably the hilariously non-typesafe C API.

m-schuetz•1h ago

AMD, do support for NV_shader_buffer_load next! Shader Buffer Load brought "Buffer Device Address" / pointers to OpenGL/glsl, long before Vulkan was even a thing. It's the best thing since sliced bread, and easily lets you access all your vertex data with pointers, i.e., you don't need to bind any vertex buffers anymore. Also easily lets you draw the entire scene in a single draw call since vertex shaders can just load data from wherever the pointers lead them, e.g., it makes GLSL vertex shaders look like this:

    uniform Node* u_nodes;
    
    void main(){
    
        Node node = u_nodes[gl_DrawID];
        
        vec3 pos = node.position[gl_VertexID];
        vec2 uv  = node.uv[gl_VertexID];
    
        ...
    }

garaetjjte•1h ago

You could do similar thing with SSBO, I think?

m-schuetz•1h ago

That is for SSBOs. u_nodes is a pointer to an SSBO in this case. That SSBO then has lots of more pointers to various different SSBOs that contain the vertex data.

garaetjjte•10m ago

I'm thinking of declaring array of SSBOs that contain array of data structs. Address would be represented by index of SSBO binding and offset within that buffer. Though that limits maximum number of used SSBOs within drawcall to GL_MAX_VERTEX_SHADER_STORAGE_BLOCKS.

m-schuetz•2m ago

To my knowledge you can't have an array of SSBOs in OpenGL. You could have one SSBO for everything, but that makes other things very difficult, like how to deal with dynamically growing scenes, loading and unloading models, etc.

SeriousM•1h ago

It seems to me, as not so 3d savy, that 3d objects and shaders have a similar connection as html structure and css. Nowadays you need a structure of objects yet the layout, color and behavor comes from css.

In this regard, 3d scenes offer the elements but shaders can design them much more efficient than a engine ever could.

Is that accurate?

Btw, can objects modified by shaders signal collisions?

flohofwoe•49m ago

3D scenes (closest thing to the DOM) and materials (closest thing to CSS) are several abstraction layers above what modern 3D APIs provide, this is more 'rendering/game engine' territory.

3D APIs are more on the level of 'draw this list of triangles, and the color of a specific pixel in the triangle is computed like this: (hundreds of lines of pixel shader code)" - but even this is slowly being being replaced by even lower level code which implements completely custom rendering pipelines entirely on the GPU.

phkahler•1h ago

Why GL_EXT_mesh_shader and not GL_mesh_shader?

And why for ES? I thought ES was for less advanced hardware.

OnionBlender•44m ago

EXT is a Khronos naming convention. It means it is a generic extension, intended to be implemented across implementations.

https://wikis.khronos.org/opengl/OpenGL_Extension#Extension_...

catapart•35m ago

This sounds pretty cool, but can anyone dumb this down for me? Mesh shaders are good because they are more efficient than the general purpose triangle shaders? Or is this something else entirely?

flohofwoe•19m ago

It's essentially a replacement for vertex shaders which map more closely to how GPUs are processing big and complex triangle meshes as small packets of vertices in parallel by doing the job of splitting a complex triangle mesh into such small packets of vertices in an offline asset-pipeline job instead of relying too much on 'hardware magic' like vertex caches.

AFAIK mesh shaders also get rid of (the ever troublesome) geometry shaders and hull shaders, but don't quote me on that :)

By far most traditional triangle rendering use cases should only see minimal performance improvements though, it's very much the definition of 'diminishing returns'.

It's definitely more straightforward and 'elegant' though.

PS: this is a pretty good introduction I think https://gpuopen.com/learn/mesh_shaders/mesh_shaders-from_ver...

Igalia, Servo, and the Sovereign Tech Fund

Ryanair flight landed at Manchester airport with six minutes of fuel left

Show HN: I invented a new generative model and got accepted to ICLR

Notes on Switching to Helix from Vim

I'm in Vibe Code Hell

The Molecular Basis of Long Covid Brain Fog

Ask HN: What's the best hackable smart TV?

NanoMi: Open-source transmission electron microscope

All-Natural Geoengineering with Frank Herbert's Dune

Boring Company cited for almost 800 environmental violations in Las Vegas

A story about bypassing air Canada's in-flight network restrictions

Ohno Type School

My approach to building large technical projects (2023)

Nobel Peace Prize 2025: María Corina Machado

Weave (YC W25) is hiring a founding AI engineer

Origami Patterns Solve a Major Physics Riddle

Python 3.14 is here. How fast is it?

Examples Are the Best Documentation

Show HN: Lights Out: my 2D Rubik's Cube-like Game

QA-use-MCP: MCP for E2E testing

I Switched from Htmx to Datastar

OpenGL is getting mesh shaders as well, via GL_EXT_mesh_shader

Parallelizing Cellular Automata with WebGPU Compute Shaders

An MVCC-like columnar table on S3 with constant-time deletes

PSA: Always use a separate domain for user content

Fascism Can't Mean Both a Specific Ideology and a Legitimate Target

A small number of samples can poison LLMs of any size

Static Bundle Object: Modernizing Static Linking

Show HN: I've built a tiny hand-held keyboard

LLMs are mortally terrified of exceptions

OpenGL is getting mesh shaders as well, via GL_EXT_mesh_shader

Comments

Igalia, Servo, and the Sovereign Tech Fund

Ryanair flight landed at Manchester airport with six minutes of fuel left

Show HN: I invented a new generative model and got accepted to ICLR

Notes on Switching to Helix from Vim

I'm in Vibe Code Hell

The Molecular Basis of Long Covid Brain Fog

Ask HN: What's the best hackable smart TV?

NanoMi: Open-source transmission electron microscope

All-Natural Geoengineering with Frank Herbert's Dune

Boring Company cited for almost 800 environmental violations in Las Vegas

A story about bypassing air Canada's in-flight network restrictions

Ohno Type School

My approach to building large technical projects (2023)

Nobel Peace Prize 2025: María Corina Machado

Weave (YC W25) is hiring a founding AI engineer

Origami Patterns Solve a Major Physics Riddle

Python 3.14 is here. How fast is it?

Examples Are the Best Documentation

Show HN: Lights Out: my 2D Rubik's Cube-like Game

QA-use-MCP: MCP for E2E testing

I Switched from Htmx to Datastar

OpenGL is getting mesh shaders as well, via GL_EXT_mesh_shader

Parallelizing Cellular Automata with WebGPU Compute Shaders

An MVCC-like columnar table on S3 with constant-time deletes

PSA: Always use a separate domain for user content

Fascism Can't Mean Both a Specific Ideology and a Legitimate Target

A small number of samples can poison LLMs of any size

Static Bundle Object: Modernizing Static Linking

Show HN: I've built a tiny hand-held keyboard

LLMs are mortally terrified of exceptions