Zink Now Achieves OpenGL ES 3.2 Atop Vulkan

[phoronix]

Phoronix: Zink Now Achieves OpenGL ES 3.2 Atop Vulkan

Mike Blumenkrantz in addition to addressing that big performance problem with Tesseract and other Zink OpenGL-on-Vulkan improvements in recent days has now landed OpenGL ES 3.2 support...

https://www.phoronix.com/scan.php?page=news_item&px=OpenGL-ES-3.2-Zink

[tildearrow]

Surprisingly. Fast. Progress.

Without Blumenkrantz we wouldn't be up to this point yet. Congratulations on this amazing job.

[uid313]

Very nice with support for both the latest OpenGL and OpenGL ES.
There are still some non-standard extensions that are not yet implemented.

What's next for Zink?
More performance improvements?
Support for more of the non-standard OpenGL extensions?
OpenCL support?
Direct3D support?

[andrei_me]

Speaking of Linux drivers, I'll leave this quote from yuzu developers:

Mesa drivers are the best drivers

https://yuzu-emu.org/entry/yuzu-progress-report-jul-2021/

[Black_Fox]

There are still some non-standard extensions that are not yet implemented.

According to the Mesa Matrix, Zink is doing very well in this area too - i965 driver currently implements 35 such extensions, radeonsi is right behind with 34 and zink is at 31.

[oiaohm]

According to the Mesa Matrix, Zink is doing very well in this area too - i965 driver currently implements 35 such extensions, radeonsi is right behind with 34 and zink is at 31.

That number is deceptive. The different is 8 not what appears to be 4 and that is deceptive. Remember AMD and Intel and zink don't implement the exact match of features with opengl.

GL_ARB_bindless_texture and GL_ARB_seamless_cubemap_per_texture both are implemented by the Intel and AMD drivers that Zink does not have this could still adversely effect some programs.
.
The next 4 are effectively doubles in the mesa matrix list GL_EXT_memory_object_fd and GL_EXT_memory_object is one pair and the GL_EXT_semaphore_fd and GL_EXT_semaphore is the other pair. These all relate to using file handles to pass around memory objects and so on. This is functionality opengl Wayland compositor would be needing.

This starts us with Zink 6 behind not 3 or 4 here because all 6 are implemented by AMD and Intel.

GL_KHR_blend_equation_advanced_coherent and GL_KHR_texture_compression_astc_hdr and GL_ARB_fragment_shader_interlock are in Intel but not in AMD and not in zink.

GL_ARB_bindless_texture and in AMD driver but not in Intel or Zink. This does take the count for Zink to implement up to 7.

GL_ARB_texture_filter_minmax and GL_ARB_sample_locations is implemented by zink and not by AMD or Intel drivers.

I do suspect I have missed a few here. But reading these opengl extensions is not easy. I would say there is 7 or more implement. 4 of those being the double up ones in future could be quite important.

Zink is 100 percent getting there. Most of ZInk up has been the low hanging fruit work. Yes Zink has recently moved on to the mid level fruit work this include the optimisations work. Of course this still has what people last 10 percent as in 10 percent taking 90% of the development time. I would not say Zink is a close to complete as it first appears. Because of the fact a lot of really hard stuff is still left undone in Zink. Yes you know it hard when software implementations of opengl have historically skipped out on 4 of those missing features.

[boxie]

I really do like that Mike fella https://www.supergoodcode.com/im-done/ such a funny character

[vb_linux]

Speaking of Linux drivers, I'll leave this quote from yuzu developers:



https://yuzu-emu.org/entry/yuzu-prog...port-jul-2021/

I read the whole article and very informative and shows even collaboration with MEsa devs, So kudos.
But the full quote implies Mesa drivers are the best drivers for AMD, it was not a shade on others.

Full Quote:

AMD Radeon Linux users may have noticed that The Legend of Zelda: Skyward Sword would run at very slow framerates in stable versions of the OpenGL Mesa drivers. This is caused by a driver level bottleneck resulting in very slow PBO (Pixel Buffer Object) downloads. While the current mesa-git has this bottleneck solved, a solution is needed until those fixes reach the stable release versions. By specifying the GL_CLIENT_STORAGE_BIT flag, an alternative faster path can be used, increasing performance from around 8 FPS to a solid 60 FPS. Mesa drivers are the best drivers.

That quote in itself shows the power of open-source drivers where developers were able to work around something because of how much deeper understanding of drivers is possible.

Got the following image from the link:

[Quackdoc]

Very nice with support for both the latest OpenGL and OpenGL ES.
There are still some non-standard extensions that are not yet implemented.

What's next for Zink?
More performance improvements?
Support for more of the non-standard OpenGL extensions?
OpenCL support?
Direct3D support?

Someone would need to make G3D state trackers for D3D and openCL. Zink already supports d3d9 by way of Gallium nine. and while I would love to use d3d10umd working on zink (would be phenomenal for VMs when Venus becomes a thing, could be viable gpu accel in windows) it doesn't work on wine.

God I want good openCL support with gallium tho.

[rmfx]

Very nice with support for both the latest OpenGL and OpenGL ES.
There are still some non-standard extensions that are not yet implemented.

What's next for Zink?
More performance improvements?
Support for more of the non-standard OpenGL extensions?
OpenCL support?
Direct3D support?

Just perf, stability and extensions are way enough and already a huge task.
Zink should do gl over vk only and do it the best possible.