Zink OpenGL-On-Vulkan Now Correctly Rendering... Glxgears

[phoronix]

Phoronix: Zink OpenGL-On-Vulkan Now Correctly Rendering... Glxgears

While Zink implements OpenGL 4 and is running an increasing number of games with good performance, one of the simple "demos" it hasn't been able to render correctly in recent years has been glxgears. But that milestone is now crossed once again with the latest Mesa code...

https://www.phoronix.com/scan.php?page=news_item&px=Zink-Glxgears-Provoking

[StarterX4]

Just like Wine being able to run many latest games, but some software from 2000's still don't work.

[microcode]

F for weird glxgears.

[timofonic]

glxgears...

what about vkgears with shaders, tesselation, raytracing and all cool stuff?

https://github.com/SaschaWillems/Vulkan

[Calinou]

Zink is now ready for the year of glxgears gaming.

[Quackdoc]

I have a feeling this is going to be really necessary when virglrenderer vulkan rolls out. I can't wait for qemu support, guess I have to figure out crosvm, and compile mesa, oh well.

but i think virgl vulkan to zink, will be faster than just regular virgl

[kpedersen]

Just like Wine being able to run many latest games, but some software from 2000's still don't work.

To be fair, QEMU can't even properly emulate MS-DOS yet: https://bugs.launchpad.net/qemu/+bug/1574246

Wine as a project is considerably more complex than MS-DOS emulation and much less funded.

[oiaohm]

To be fair, QEMU can't even properly emulate MS-DOS yet:

Wine as a project is considerably more complex than MS-DOS emulation and much less funded.

qemu supports more than one BIOS image. Turns out that bug you pointed to is in fact replication how real hardware with a Seabios behaves as well. So a failure with qemu and seabios described in that bug is qemu correctly emulating real hardware.

Wine own internal dos emulation is not that good. Wine project started external project called dosbox most of the time they have specailised in dos application compatibility then after while the default action for wine came use dosbox and only use wine own implementation if that did not work.

A few years latter we are using 64 bit systems the v86 mode of the Linux kernel is gone so wine own internal dos emulation cannot be run for dos applications because v86 mode is a required feature so it works. So wine own dos emulation sitting their for win3.x and before applications so now when you run dos applications with wine is basically a proxy to dosbox and dosbox has picked up a few features to work better with wine.

[onlyLinuxLuvUBack]

An interesting phoronix benchmark could be:

zink running the raylib gl demos with maybe patches for fps counting, and then nvidia driver vs radeon ?

[leipero]

glxgears...

what about vkgears with shaders, tesselation, raytracing and all cool stuff?

https://github.com/SaschaWillems/Vulkan

If I understand you correctly, you are suggesting that there should be a "demo" for vulkan included in mesa-demos (or whatever the name of the package is)? If that is the case, I agree.
The issue is that vulkan is still optional, however, what may be smart (I don't know?) is to build a tree or for package maintainers to make group "mesa3d" for example (or something like that) that would include all implementations (GL, VK, CL etc.) while allowing separate installation as it is the case now. Just trowing this out there, maybe it's a good idea, maybe terrible.

In that case, for compatibility purposes I guess mesa3d-demos would be a name that would include all demos for example. Or simply include it in mesa-demos (at the risk of having non-functional demo in the group).