What does Vulkan do differently than OpenGL?

2 hours ago, Cacodemon345 said:

I am talking about stuff like this when I refer to platform-specific code to initialize a library:

#if BX_PLATFORM_WINDOWS

pd.nwh = wmi.info.win.window;

#elif BX_PLATFORM_OSX

pd.nwh = wmi.info.cocoa.window;

#elif BX_PLATFORM_LINUX

pd.ndt = wmi.info.x11.display;

pd.nwh = (void*)(uintptr_t)wmi.info.x11.window;

#elif BX_PLATFORM_EMSCRIPTEN

pd.nwh = (void*)"#canvas";

#endif // BX_PLATFORM_WINDOWS ? BX_PLATFORM_OSX ? BX_PLATFORM_LINUX ?

// BX_PLATFORM_EMSCRIPTEN

So, how would you do it? You cannot hide the fact that these systems are different - and you most certainly do not want to go the SDL way where the library hijacks the entire system with no option to roll out your own OS interface in case the provided solution is not sufficient.

On 10/10/2021 at 10:49 PM, Graf Zahl said:

Working with it?

You could have known that when the renderer was implemented. Now ages later it seems you had a change of heart.

On 10/10/2021 at 10:49 PM, Graf Zahl said:

 

I have to accept that the so-called 'experts' consider it the future but working with Vulkan just creates such totally fucked up code that it's very hard to work with it or to refactor it if the need arises.

Atleast the GLES renderer can function as some kind of backup in terms of stability.

On 10/10/2021 at 10:49 PM, Graf Zahl said:

Ever wondered why the Vulkan backend still has some stability issues?

I wouldn't know. You heralded it initially as the future, from experts by experts. So color me interested to see you shut it down so heavily as you do now.

45 minutes ago, Redneckerz said:

You could have known that when the renderer was implemented. Now ages later it seems you had a change of heart.

You shouldn't confuse dissatisfaction with rejection. Also do not confuse "this is really annoying to use" with "this is useless". The Vulkan code is there to stay, at least until the next cross-platform graphic API.

But having followed the development of this renderer day to day as it was happening, I can tell you the disillusion happened very early.

40 minutes ago, Redneckerz said:

You could have known that when the renderer was implemented. Now ages later it seems you had a change of heart.

Atleast the GLES renderer can function as some kind of backup in terms of stability.

I wouldn't know. You heralded it initially as the future, from experts by experts. So color me interested to see you shut it down so heavily as you do now.

PLease don't judge things you do not understand. There's different layers here that are a bit at odds:

1) In terms of graphics programming, Vulkan is the future. This is where things will gravitate to, there's no point denying that. So any forward looking software needs a Vulkan/D3D12 backend or it will get stuck in development nirvana sooner or later.

2) 1) does not imply that I like the API or how it was designed. Here I have strong misgivings on several levels. First, the incredible verbosity is an instant turn-off - to even do the simplest things you got to write a wall of code. In addition, despite being heralded as 'made for better performance', this only goes for software directly written for it that does not have to bother with legacy support. There's several things in GZDoom that need refactoring before Vulkan can truly show its strengths. But these are primarily blocked by OpenGL being a singlemindedly single-threaded API and older incarnations not even supporting all features.

3) OpenGL ES will never function as a backup for anything. It's a stripped down OpenGL renderer for low end hardware. Currently less than 10% of our users are on such hardware. Considering natural attrition and a boost from Windows 11's upped system requirements I'd expect it dead in maybe 5-6 years and if I find the time to do a reworking of the renderer to better support Vulkan it will be relegated to a legacy branch even sooner.

4 hours ago, Gez said:

You shouldn't confuse dissatisfaction with rejection. Also do not confuse "this is really annoying to use" with "this is useless". The Vulkan code is there to stay, at least until the next cross-platform graphic API.

 

But having followed the development of this renderer day to day as it was happening, I can tell you the disillusion happened very early.

OH no, absolutely not. I just clearly remember how positively things were and found it sudden that there was now a dislike to that very same thing.

Graf's extended answer provides more clarity that initially was missing.

4 hours ago, Graf Zahl said:

 

PLease don't judge things you do not understand.

You weren't giving specifics, so one could easily be misconstrued. Luckily you provide an elaborate answer, so thanks for that.

4 hours ago, Graf Zahl said:

3) OpenGL ES will never function as a backup for anything. It's a stripped down OpenGL renderer for low end hardware. Currently less than 10% of our users are on such hardware. Considering natural attrition and a boost from Windows 11's upped system requirements I'd expect it dead in maybe 5-6 years and if I find the time to do a reworking of the renderer to better support Vulkan it will be relegated to a legacy branch even sooner.

Its a stable renderer atleast, no?

Vulkan has one problem: It doesn't gracefully handle out of memory situations. It either crashes or hangs if VRAM runs out.

No easy way to fix that, I take?

On 10/15/2021 at 8:16 AM, ChopBlock223 said:

No easy way to fix that, I take?

it basically refuses to manage memory at all. OpenGL, for example, did it wrong by allowing the programmer to upload more textures that will fit in GPU RAM, and doing texture swapping by itself (which makes performance estimations hard, and can cause spurious slowdowns). then Vulkan designers decided to throw it all away and do virtually nothing at all, expecting the programmer to strictly control everything. both approaches are bad, tbh, but OpenGL at least doesn't go with "you should have known better, and now you're dead, haha!" approach. ;-)

TBH, this is something that normally needs to be handled on the application side. All the system can do in out of memory situations is trying to swap out stuff and depend on heuristics.

The client normally knows better which resources can be safely evicted and which can not.

Of course all that becomes a moot point if the allocator in some drivers is broken and does not return a failure but instead locks up the system.

The memory problem with vulkan is that the nvidia driver incorrectly reports more memory available than there actually is. If GZDoom's memory allocator then decides to use it all the driver crashes the application. It is an unfortunate thing about vulkan that isn't actually vulkan's fault. It is clearly a driver bug - either it shouldn't report that much memory available, or it should honor its promise as swap out the memory like it does with OpenGL.

You generally don't see this problem with modern games simply because they don't just try allocate in this way. Instead they allocate a texture cache of a certain size (that you usually can choose in the settings in games) and then they never have more textures loaded than that.

3 hours ago, dpJudas said:

The memory problem with vulkan is that the nvidia driver incorrectly reports more memory available than there actually is.

What the actual fuck? Is there any consistency or pattern to how the reported amount of memory is incorrect?

I mean Doom 2016's Vulkan had bugs on NVIDIA GPUs related to VRAM usage so I think it's probably NVIDIA being crap at VRAM reporting to Vulkan applications.

5 hours ago, Altazimuth said:

What the actual fuck? Is there any consistency or pattern to how the reported amount of memory is incorrect?

I can't remember the specifics anymore, it was a long time ago I looked into it. GZDoom delegates memory allocations to a helper library that should fail the allocation if there's no longer room in the memory heaps reported by vkGetPhysicalDeviceMemoryProperties. Since the allocation doesn't actually fail I'm assuming the driver returns VK_SUCCESS to all the calls to vkAllocateMemory.

However, I admit I didn't personally verify this with a test application outside GZDoom. There is a chance that the bug here is actually in the memory allocation helper library. I just don't find it particular likely as it does report memory allocation failures for some of the other vulkan memory heaps.

Interestingly, NVidia's NVRHIlibrary does not use AMD's allocator wrapper.

In any case, the version of the allocator we were using was ancient, so I updated the file. Maybe it works better by now.