Multithreading Doom's playsim

[Rachael]

For the record - it was the clip planes, not the stencil buffer, that were broken. And they were so broken that just enabling them made the driver lose it.

Ah, my mistake, sorry.

[Graf Zahl]

Regarding market share, the 2019 survey shows a measly 2.5% of all users with AMD pre-Vulkan hardware.
So by now that should mostly be irrelevant.

[MartinHowe]

Since I guess this thread is coming to its natural end and/or may devolve into a GPU discussion, I'd just like to say thanks to all who replied, particularly @Blzut3, from whom I have learned a lot.

For background: I trained in microelectronics and my dream job as a late teen (c. 1983) was 'microprocessor architect at Intel' (AMD was tiny then, ARM was just beginning and AXP was a fantasy). Eventually I achieved MSc in microelectronics, but ill health derailed my career, though I've stayed in IT in one form or another. My current job is refurbishing PCs and electrical stuff, plus training young people with autism in a mix of tech, workplace and practical skills, the latter two base on my own experiences as high-function autism and Asperger Syndrome were not understood when I was their age (teachers thought I was a genius, crazy, or both). I still do weird crazy stuff, but only for Doom

Out of interest, I have tried to keep up with computer architecture over the years, but gotten somewhat behind of late. So this thread has been fascinating

[Blzut3]

OpenGL simply isn't it for AMD,

To add to this, if you dig through reddit you can find comments from AMD employees that basically state that they more or less only maintain the Windows OpenGL driver for Minecraft and CAD. There simply aren't enough popular games using OpenGL for there to be any motivation for the situation to change. Now that id tech is Vulkan exclusive, I think Minecraft may be the only major game still using the API on Windows? (Random aside: wonder if the Microsoft buy out will change id's long history of using OpenGL/Vulkan.) As you say, Vulkan wrappers will probably be the final nail for any hope of native OpenGL drivers for Windows improving.

[Cacodemon345]

(Random aside: wonder if the Microsoft buy out will change id's long history of using OpenGL/Vulkan.)

That isn't very likely to happen in any case since id Software will continue to run as an independent studio. Minecraft still uses OpenGL as you stated and there's actually an ANGLE implementation that wraps OpenGL ES behind a Direct3D backend which is available for use in Windows UWP. And more and more games are using Vulkan as it is becoming more cross-platform; there's already a Vulkan-to-D3D12 wrapper and Vulkan is already running on the Switch.

Ultimately I agree Vulkan wrappers will drive out native OpenGL eventually. Once Mesa3D's Zink project is finally complete and able to outperform AMD's OpenGL implementation on Windows it's going to become merely a easy-to-use API interface for Vulkan. Nothing more and nothing less.

[Graf Zahl]

What I don't understand here is why Zink is being developed as part of a driver and not as a standalone drop-in library that can be used anywhere. This will inevitably limit its usefulness to the point where potential customers may just skip over it.

BTW, Microsoft is already doing their own OpenGL -> D3D12 wrapper - very much the same way as a system component. But from the looks of it they seem to want to settle at GL3.3.

But I think ultimately such wrappers are mere stopgap measures. What we really need is a more accessible high level API on top of Vulkan that exposes its strengths but smoothes over all the rough spots that only matter when performance has to be tuned to the metal.

[Blzut3]

What I don't understand here is why Zink is being developed as part of a driver and not as a standalone drop-in library that can be used anywhere. This will inevitably limit its usefulness to the point where potential customers may just skip over it.

You're ultimately confusing what "driver" means in the context of Mesa. Mesa is the implementation of the user space dynamic library that provides the API and contains no kernel space code.

Granted I would personally think it would be more useful as a system wide installation instead of relying on every piece of software shipping Zink. But I don't see any reason that it couldn't be provided by the application.

[Graf Zahl]

Granted I would personally think it would be more useful as a system wide installation instead of relying on every piece of software shipping Zink. But I don't see any reason that it couldn't be provided by the application.

Think Windows, not Linux. On windows it's not SOP to install dependencies, they are normally shipped with the application.

[Rachael]

Think Windows, not Linux. On windows it's not SOP to install dependencies, they are normally shipped with the application.

I do agree with you on this in general, however there are exceptions to every rule.

Once Vulkan completely overtakes OpenGL as the dominant cross-platform graphics API I am predicting at least this will happen: I believe that a community-driven "continuation" of OpenGL may occur built atop Zink in order to keep Vulkan accessible at least to some degree, to all. This would be not much different from the Glide wrappers that are already available, today. On that note, even OpenAL-Soft does this. I think that there will be custom extensions tacked onto it, again driven by the community, in order to interact with some of Vulkan's features without requiring a full Vulkan implementation within the application.

If this occurs, one of three things will happen:

1) It's possible that such a library will be system-installed, much like the Glide wrappers already are.

2) It's also possible that some applications will include such wrappers built-in, much like how OpenAL-Soft already comes with GZDoom.

3) The more likely outcome is actually a combination of both of the above.

[Cacodemon345]

It should not be impossible to build Mesa3D's Zink as a layer over Vulkan for Windows since it already can be built as a software OpenGL renderer library for that platform.

[Blzut3]

Think Windows, not Linux. On windows it's not SOP to install dependencies, they are normally shipped with the application.

This isn't true for graphics APIs though since we already install those system wide on Windows. Thus there is a long list of software that using OpenGL that can benefit from a system copy of Zink. Sure you could choose to include a copy of Zink with you program if you want to, but why should you when it will probably be ideal for AMD users to install Zink anyway? Who knows, since they're open source friendly, maybe AMD will start including it in their driver package once it out performs their native Windows driver. Guess we'll see, but the general sentiment I've been hearing is that it's not likely that Zink will outperform well written native OpenGL drivers, so we're a long ways off from the point where running Zink is universal. Now it's a different story for macOS, and if the situation ever gets that point on Windows then I'd absolutely agree with you.

As Rachael said it's not even that unusual for existing wrappers to be installed system wide. Now I don't necessarily see OpenGL going the way of OpenAL where community extensions cause Zink to become essentially it's own high level API. Certainly possible, but it would be an odd choice to pay for all the baggage just because no one can be bothered to design a new more suitable high level API.

There is probably room for debate on if a high level API is even needed. My suspicion is that the reason we haven't heard much from people trying to make a new high level API (there was lot of talk about this when Vulkan first launched) is because Vulkan/DX12/Metal have become less scary as time goes on, combined with many previous instances of needing to write custom rendering code being replaced with ever more generic, low cost game engines. For people doing hobby programming to turn into a profession later on, it doesn't make a whole lot of sense to invest into learning a high level API when you'll be needed to use a low level one on the job. Certainly would be nice to have a lower barrier to entry, but is OpenGL really the right tool for that?

Perhaps an even better question to ask would be with DXVK making D3D11 cross platform, is OpenGL a better tool than D3D11 for the job?

It should not be impossible to build Mesa3D's Zink as a layer over Vulkan for Windows since it already can be built as a software OpenGL renderer library for that platform.

There are absolutely efforts going on to get Zink running on Windows and macOS. It's just not the highest priority item right now since Zink still has a ways to go in optimization and correctness before whether you can use it on Windows and macOS is actually relevant.

[Graf Zahl]

There is probably room for debate on if a high level API is even needed. My suspicion is that the reason we haven't heard much from people trying to make a new high level API (there was lot of talk about this when Vulkan first launched) is because Vulkan/DX12/Metal have become less scary as time goes on, combined with many previous instances of needing to write custom rendering code being replaced with ever more generic, low cost game engines. For people doing hobby programming to turn into a profession later on, it doesn't make a whole lot of sense to invest into learning a high level API when you'll be needed to use a low level one on the job. Certainly would be nice to have a lower barrier to entry, but is OpenGL really the right tool for that?

I think you missed the potential customer base by a wide margin. I'M thinking more of professional software that needs to do a bit of 3D rendering without worrying too much about performance. In such environments productivity matters - and one thing Vulkan surely is not and never will be is being conductive to productivity. When writing such software I do not care about having to transition texture images or synchronize all actions or suffer obtuse crashes, and so on.

Perhaps an even better question to ask would be with DXVK making D3D11 cross platform, is OpenGL a better tool than D3D11 for the job?

Of these two APIs, D3D11 is far and away the better one, but this DXVK project looks like another one of those failures-by-design which is limiting itself to an unattractive scope, being solely meant for use with Wine.

[Blzut3]

I think you missed the potential customer base by a wide margin. I'M thinking more of professional software that needs to do a bit of 3D rendering without worrying too much about performance. In such environments productivity matters - and one thing Vulkan surely is not and never will be is being conductive to productivity. When writing such software I do not care about having to transition texture images or synchronize all actions or suffer obtuse crashes, and so on.

Ah, if I recall correctly AMD made V-EZ to try to target this use case, but must have had no demand since they seemingly dropped it soon after announcing it.

Of these two APIs, D3D11 is far and away the better one, but this DXVK project looks like another one of those failures-by-design which is limiting itself to an unattractive scope, being solely meant for use with Wine.

I'm not sure what the status on the effort is but there is a DXVK-Native project which allows building dxvk as a Linux shared object. Intention last I heard is to upstream the changes. Supposedly wine developers are interested in moving the translation out to native. Not entirely sure why they would care though.

In any case I expect that there will be enough "ick Microsoft" reaction to the idea of using D3D11 in native Linux code that adoption as a cross platform high level graphics API will be poor regardless.

EDIT: Forgot that Valve recently added DXVK to the Linux version of Portal 2: https://www.phoronix.com/scan.php?page= ... radv&num=1

[Graf Zahl]

Ah, if I recall correctly AMD made V-EZ to try to target this use case, but must have had no demand since they seemingly dropped it soon after announcing it.

The two reasons for that were most likely lack of documentation and a generally poor product. V-EZ had major performance issues - while to the outside it looked like a 'simpler Vulkan' it achieved this by setting up its own command buffers using C++ standard containers (yay, malloc!) and replaying them when complete. The overhead of this was just ridiculous.
It also wasn't encouraging that they dropped it and left.

I'm not sure what the status on the effort is but there is a DXVK-Native project which allows building dxvk as a Linux shared object. Intention last I heard is to upstream the changes. Supposedly wine developers are interested in moving the translation out to native. Not entirely sure why they would care though.

In any case I expect that there will be enough "ick Microsoft" reaction to the idea of using D3D11 in native Linux code that adoption as a cross platform high level graphics API will be poor regardless.

We'll see. The fact remains that of the current APIs, D3D11 is far and away the one that's easiest to use without having degenerated into a crusty mess like OpenGL.

[Talon1024]

I don't know how this turned into a discussion of graphics APIs, but since DXVK is released as Windows DLLs, some Windows people have used DXVK to improve performance in certain games. There's also bgfx, which (I think) aims to be an easier-to-use abstraction of all graphics APIs, and ANGLE, which can translate OpenGL ES to many other APIs.