Zink brings conformant OpenGL on Imagination GPUs | Hacker News Reader

Zink brings conformant OpenGL on Imagination GPUs

collabora.com

137 pointsmfilion30 comments

I am hopeful this will help mesa3d support with RISC-V SoCs such as JH7110 (and thus VisionFive2 and Star64) be excellent.

Dupe of https://news.ycombinator.com/item?id=36621057

So.. if you combine Zink and MoltenVK can you get modern OpenGL on Mac? Would be funny.

https://www.collabora.com/news-and-blog/blog/2021/06/14/zink...

As of summer 2021 there was some support for exactly this.

GL was modern in the 1980s. Making it "Open" didn't particularly modernize it, that just popularized it. It's finally deprecated on Mac.

OpenGL has received continuous development. Also, I find it easier to work with than Vulkan. Sometimes you do want higher abstraction.

Guess what? GPUs have received continuous development too, since the days of SGI. And OpenGL hasn't kept up. Its "higher" abstraction is the wrong abstraction.

So we are no longer running arbitrary code against arbitrary buffers of random access data?

OpenGL isn't really a 'high abstraction level' API though, that would be a lot more 'declarative'.

Instead it's originally modelled after some mid-80s(?) fixed-function 3D rendering hardware from SGI, which then got incrementally extended in the following decades to support new GPU hardware features, but without any thought put into the overall API design.

I don't think "higher level" intrinsically means "declarative" though. I'd think most people would agree OpenGL is higher level than Vulkan for a variety of reasons.

I guess what I wanted to say is that GL transitioned from a non-abstractive API in it's very early days into the wrong abstraction in the present day.

Well, there is AZDO, and in platforms like Android, until Google bothers to provide Java/Kotlin bindings, it is the API most app developers will reach out.

Most will never deal with Vulkan and the NDK directly, unless there is no other way.

Likewise on the Web, for developers that what to write 3D code that is actually usable everywhere.

Can you explain why you think it's "wrong"?

The GL programming model defines a highly granular and highly dynamic state machine of dozens (hundreds?) of small knobs and sliders that needs to be mapped to an underlying hardware which looks very different by now.

This results in small state changes potentially causing large and unpredictable 'recompiles' of the internal 'driver state' at random points (e.g. calling one of the blend state functions - which should be a very cheap operation - might trigger expensive shader recompiles in some random GL call down the line, but if and when this exactly happens depends on the specific GL implementation).

That's one important reason why modern 3D APIs prefer to group state into immutable state-group objects (even if those modern 3D-APIs also don't perfectly map the underlying hardware).

I think they mean that more recent (or “modern”) OpenGL versions beyond 4.1 aren’t supported on macOS, and semi-seriously suggested Zink/MoltenVK as a way to use (say) OpenGL 4.6 on that platform

there is also https://github.com/openglonmetal/MGL

disclaimer: have not used or tested

Ah, sounds like this isn’t the same Imagination behind the MIPS SBCs https://en.m.wikipedia.org/wiki/Imagination_Creator

It actually is the same Imagination.

Keeping track who is behind MIPS is an adventure.. from wikipedia:

February 8, 2013 MIPS Technologies is sold to Imagination Technologies for $100 million

September 22, 2017 MIPS business is sold by Imagination Technologies to Tallwood Venture Capital as Tallwood MIPS Inc. for $65 million

June 2018 MIPS Tech Inc. is acquired by Wave Computing

April 2020 Wave Computing files for bankruptcy

March 2021 Wave Computing emerges from bankruptcy, renames itself as "MIPS" and joins RISC-V International. Development of the MIPS architecture ceases

Interesting. The OpenGL team used to be one of the most prominent driver teams at IMG, and now it's outsourced. They explain the (market) reasons in the post.

I am not surprised. As I understand it, Vulkan is a low-level API which is a much better fit to the actual hardware than OpenGL or DirectX.

You probably want to implement Vulkan anyways, so why bother re-implementing a separate legacy API when an existing translation layer can give the same or better result for a fraction of the effort? Heck, Intel even did the same thing to get DirectX working on their Arc GPUs: they just used Wine's DXVK translation layer.

Note that Intel is only using a translation layer for DirectX 9, and from what I’ve heard online the result is bad performance. DirectX 11 and 12 are both implemented natively.

DirectX 11 and 12 are both much more aligned to the hardware. DX 12 took the basic principles from AMD's Mantle and is very similar to Vulkan and Apple's Metal. Therefore, it makes a lot of sense and is not too much additional work to implement these natively.

More like it brought to DirectX PC, most of the stuff that was already available in XDX.

Intel are actually using Microsoft's D3D9on12, which isn't nearly as good as dxvk.

I believe they're using both. Swapping depending on the game.

https://www.tomshardware.com/news/intel-gpu-driver-optimizat...

An inkless printing technology "brings conformant OpenGL?"

Zink? Zink is an inkless printing technology, originally for instant cameras. The name is short for "zero ink."

https://zink.com

Keep down-modding, Redditards. Be sure to "flag" this, assholes. Heaven forbid someone upset your pathetic, insular worldview with FACTS.

Reply on news.ycombinator.com