Zink OpenGL-Over-Vulkan Now Exposes GLSL 1.30

[phoronix]

Phoronix: Zink OpenGL-Over-Vulkan Now Exposes GLSL 1.30

The Zink Mesa driver for implementing OpenGL over the Vulkan API is now quite close to hitting OpenGL 3.0...

http://www.phoronix.com/scan.php?page=news_item&px=Zink-GLSL-1.30-Exposed

[uid313]

Can Zink be faster than it is today? Or will it always be this slow?

[ResponseWriter]

Can Zink be faster than it is today? Or will it always be this slow?

"make it work, make it right, make it fast"

[You-]

Can Zink be faster than it is today? Or will it always be this slow?

When comparing OpenGL 1.x and 2.x features, you are often comparing against fixed function pipelines, so any overhead of conversion that Zink undertakes will be obvious. Against later versions of OpenGL when the non zink path will also be carrying out complicated processing, the overhead will be less significant.

[kpedersen]

Can Zink be faster than it is today? Or will it always be this slow?

As mentioned, the overhead.

If you want to use a young API underneath OpenGL, you need younger and faster hardware to achieve the same result.

[smitty3268]

Can Zink be faster than it is today? Or will it always be this slow?

It can definitely be optimized a lot, but it's never going to run at 100% speed of a native OpenGL implementation.

[tildearrow]

"make it work, make it right, make it fast"

The honest open-source way:

"make it work, make it right, fail, make it work, make it right, fail, make it work..."

OSS -> ALSA -> ??? -> ESD/aRts/JACK/whatever -> ??? -> PulseAudio -> Fix it -> ??? -> PipeWire -> ???...

sysvinit -> runit/OpenRC/whatever -> ??? -> systemd -> systemd improvements -> ???

KDE 1 -> KDE 2 -> KDE 3 -> ??? -> KDE 4 -> ??? -> KDE 5 -> Finally -> ???

Linux static binaries -> ld.so -> ??? -> dpkg/rpm -> ??? -> dependency hell -> APT/Yum/pacman/ZYpp -> ??? -> dnf -> error while loading shared libraries: libBreakMe.so.999: cannot open shared object file: No such file or directory -> Flatpak/Snap/AppImage -> ???

write in C -> fix your vulnerable code -> ??? -> a mess -> rewrite in C++ -> oh hey look a new cool programming language -> *looks at exa* -> oh wow this is soooo cool o-o -> ??? -> rewrite in Rust -> ???

The Intel way:

"make it work, make it fast, make it right, make it fast, make it right, make it fast, make it fast, make it fast, cheat, cheat, rebrand, rebrand, rebrand, rebrand, make it right, rebrand, rebrand, make it right, rebrand..."



Only AMD got it right:

- make it work: the first x86 clones
- make it right: AMD64
- make it fast: Zen

[pal666]

Can Zink be faster than it is today? Or will it always be this slow?

everything can be faster than it is today. but zinc can't be faster than no zinc

[zboszor]

everything can be faster than it is today. but zinc can't be faster than no zinc

And if coupled with the copper from the Commodore Amiga, you get brass. ;-)

[JPFSanders]

Zinc is not supposed to be fast at this stage, that will come later once it completes later OpenGL (3.x at least) and becomes more useful. For now all it has to do is provide an implementation as complete as possible to allow for development to continue. At this stage all is foundational work.