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

[Quackdoc]

I'm an old guy. I have zero interest in games. I'm an artist and I have software (about 400k lines of C) for my artwork. I use OpenGL but not in complex ways beyond a couple of shaders. Nobody would describe OpenGL as elegant, I think.

I fear that OpenGL is somehow threatened by Vulkan. I bought a Vulkan book and instantly got lost in it's object oriented nonsense. If it is that hard to get GLXgears working it doesn't speak well of Vulkan as a language.

What I mean is that GLXgears doesn't use much of OpenGL so translating all of OpenGL calls to Vulkan is going to be very difficult.

Driver development is hard, not software development, Zink already has a lot of support, I found most games runs fairly well, and that would cover a broad group of functions, but not all.

EDIT: Vulkan is a lot of work, but the work is more tedious than hard.

[Clive McCarthy]

I certainly got the impression that Vulkan was deliberately low-level. Not a bad thing. Maybe it just needs a Glib. In it's pre-standard-library days C could be rough to deal with.

It is possible I just bought the wrong Vulkan book.

I don't expect nor need anything more from OpenGL. I have encapsulated most of the things I don't like about OpenGL in my own code. For example I have a function called: generate_and_bind_opengl_object() which hides a bunch of OpenGL needless crap. At the same time, shockingly GLU is still around.

[smitty3268]

I fear that OpenGL is somehow threatened by Vulkan.

OpenGL isn't going anywhere any time soon. However, it's strictly legacy at this point, there for backwards compatibility. Don't expect any more changes to come to OpenGL.

I bought a Vulkan book and instantly got lost in it's object oriented nonsense.

That's interesting, considering that OpenGL is the one based around a state machine while Vulkan is much more low level. I assume whatever book you bought assumes a more modern design for it's demo code, is what you mean by this. There's nothing about Vulkan that is inherently more object oriented as far as I know, anyway.

If it is that hard to get GLXgears working it doesn't speak well of Vulkan as a language.
What I mean is that GLXgears doesn't use much of OpenGL so translating all of OpenGL calls to Vulkan is going to be very difficult.

It was intentionally designed to be low level, and for experts to use. If you aren't that into graphics programming, then Vulkan may not be the correct API for you. That doesn't make it bad - it just means you aren't the target audience. Instead, the Vulkan designers assumed lighter users would use a higher level library built on top of Vulkan which would provide a simpler way of using it. That can even be OpenGL itself, although I'd hope for something more elegant than that. There haven't been a ton of these popping up yet, which is a bit disappointing, but I do think over time they will pop up more and more.

[Clive McCarthy]

I'm an old guy. I have zero interest in games. I'm an artist and I have software (about 400k lines of C) for my artwork. I use OpenGL but not in complex ways beyond a couple of shaders. Nobody would describe OpenGL as elegant, I think.

I fear that OpenGL is somehow threatened by Vulkan. I bought a Vulkan book and instantly got lost in it's object oriented nonsense. If it is that hard to get GLXgears working it doesn't speak well of Vulkan as a language.

What I mean is that GLXgears doesn't use much of OpenGL so translating all of OpenGL calls to Vulkan is going to be very difficult.

[Quackdoc]

I hoped this future would be here already as these features were meant to be ready by Q1/2020.

Fingers crossed. I have been using android x86 in a qemu VM for a little while now, I am too impatient for qemu to pick up support for the vulkan patch. Hopefully it is soon.

[kpedersen]

Basically you have a cursed problem where everyone on one hand is right yet its wrong at the same time.

Hmm, I see. I did suspect as much.

In terms of digital preservation, QEMU seems perfect on the surface but its main interests really do lay in chasing the most modern platforms (and KVM mostly).
Perhaps added flexibility of specifying the exact hardware keyboard controller could be a solution but it is adding more complexity.

[oiaohm]

So in short, something isn't quite right (perhaps in both projects) and DOS unfortunately isn't quite an attractive platform for the kind of technical developer required.

Its more of a mess. Seabios on real hardware will do it and need the patch so djgpp will work. Then you have real hardware keyboard controllers that are not djgpp compatible either.

Bochs and QEMU are emulating different generations of hardware in the keyboard controller. Welcome to hell. Qemu is correctly replicating how some real server x86 hardware behaves and bochs is correct emulating how some other hardware behaves.

1) Seabios bug on particular keyboard controllers is problem one.
2) Particular modern keyboard controllers in real modern chipsets also behave how qemu does in the new version. So they fixed a bug in emulation to match modern hardware now the it breaks again.
3) Boch has a keyboard controller that behaves like a keyboard controller from when dos was dominate so is the legacy design.

The fact that qemu behavour is right for particular hardware so it correct emulation of that hardware that makes the fix tricker.

This is a case there was a bug in Seabios, There is a issue in modern hardware keyboard controllers vs legacy hardware keyboard controllers that show self with old dos programs. The modern version of keyboard controller does result in less emulation overhead running Linux,freebsd and windows in qemu.

Basically you have a cursed problem where everyone on one hand is right yet its wrong at the same time.

[kpedersen]

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.

Quite possibly. However, I believe there might be something more to it because every BIOS I have tried in Qemu exhibits the same behaviour. And Seabios on i.e Bochs doesn't.

There was a patch for (open-source) DJGPP / CSDPMI programs here (I integrated it into Vim (incl pmode/dj if you remember that!) on that same thread).

https://www.vogons.org/viewtopic.php?p=938609

Since there has been a patch for Seabios that fixes it but only on a specific version of Qemu.

So in short, something isn't quite right (perhaps in both projects) and DOS unfortunately isn't quite an attractive platform for the kind of technical developer required.

[timofonic]

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).

Yes, that's what I meant.

What's optional? That's relative. They can modularize the code.

The sooner they support Vulkan as a first class citizen, the better for everyone.

One of the big issues with virgl OpenGL is that all OpenGL apps on the virtualized guest, do share single OpenGL context on the host and single queue between the two. This causes a lot of stutter when one more than 1 OpenGL is running on the guest. For example, running Unigine Heaven I get about 95 fps, but if I also run glxgears (with vsync 60 Hz), the Unigine Heaven performance drops A LOT, to about 45 fps, and there is visible stutter. virgl vulkan will solve this problem, by using multiple queues and logical devices, which are easily supported by Vulkan API and drivers, even from a single userspace process (like qemu). The zink itself does of course isn't 100% performance of the native OpenGL drivers (like radeonsi), but it is pretty close. In fact in some benchmarks and tests, for example supertuxkart, zink+radv gets 99-102% of radeonsi, which is amazing). In most others, the 65% is average I see across many benchmarks and titles (usually 55%-75%, with very few benchmarks where it gets more or less than that).

I stopped trust VirGL developers, really. That should be done for everyone. Also, it would be nice if using Wine/DXVK as a basis for Microsoft Windows 2D and 3D support.

I see half baked efforts. I understand it may be difficult to achieve, but VMWare did something similar.

[ms178]

So, Khronos just released h264 and h265 extensions for Vulkan for decoding done mostly by AMD, and finialized by Nvidia and Intel's help, and encoding and other formats are coming soon. Nvidia already have beta drivers supporting this. It should be relatively easy to make it work in virgl / venus, and write user space libraries (like vaapi / vdpau), that use this new vulkan api to do decoding. The future is bright here.

I hoped this future would be here already as these features were meant to be ready by Q1/2020.