Differing behavior on Windows 10 and Ubuntu

I have test application that now compiles and runs on both Windows 10 and Ubuntu 20.

The testing is being done on the same system with different boot partitions - so this should be as close as possible to an ‘identical’ hardware configuration.

Host system is an AMD Ryzen 7 with 32 GB
Card is a GeForce RTX 2060/PCIe/SSE2
Driver is NVIDIA 450.102.04
Both are running 64 bit versions of the OS - in case that’s not implicit.

First problem is vulkaninfo is reporting errors on the ubuntu side

$ vulkaninfo | more
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_virtio.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_intel.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_lvp.so: wrong ELF class: ELFCLASS32

Second problem is that the draw time on ubuntu is 0.813695 ms / frame and windows 10 is about 0.3 ms / frame. The difference is invisible to the eye - but part of this project is GP on GPU work and that means that my computing power is about 1/3 on ubuntu. I expect to be short on CPU power anyway, so that loss is more than annoying.

This effort is to develop a Vulkan framework that can be used as a foundation for high end, cross platform engineering apps and if the performance on the same box with different OSs isn’t the same it sort of defeats the purpose. Ultimately, it’s supposed to break the ‘3,000 lines to say hello in vulkan’ barrier.

I’ve installed the SDK using sudo apt and downloading the tarball - the behavior is the same.

Otherwise the two different builds appear to run identically.

Both should be release builds and were built with same CMake build in Release mode.

This may be part of the issue

CMake log reports this after find_package(vulkan)

Vulkan_INCLUDE_DIRS = /home/<user>/vulkan/
Vulkan_LIBRARIES = /usr/lib/x86_64-linux-gnu/libvulkan.so

The first is points to the extracted tarball
The second points to the library installed by apt

I think.

It definitely seems ‘wrong’ that fetching one package should point to two different trees.

The SDK version used should not matter. An important information I’m missing: what compiler are you using.

As for the performance delta: While the hardware is identical, the drivers, aka the implementation may differ between two operating systems, and your code may run a different code path depending on what OS it’s running on. But in general, Vulkan could run close to the same speed on Windows and Linux.

A good starting point would be to run your app through nsight which will let you quickly see the differences between a run on Windows and Linux.

You are correct about the primary difference being in the drivers and the compilers.

I suspect that my ubuntu build is falsely a release build and is actually a debug build. It’s performance corresponds closely to the windows debug build. A visual inspection shows that should not be the case - but I’ll keep digging.

The windows system is compiling in both clang_x64 and msvc_x64_x64 - both have similar performance.
The Vis Studio version is VS 19 v-16.9.4

ubuntu is
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

Ubuntu is using

gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

:~$ vulkaninfo | more
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_virtio.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_intel.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_lvp.so: wrong ELF class: ELFCLASS32

Vulkan Instance Version: 1.2.170

One annoying problem was that there were duplicate installs of vulkan tools. find_package was non deterministic and often picking the include and lib from different sources. That’s resolved.

It’s very hard to pin down whether LunarG, Nvidia or AMD is responsible for this one. It certainly doesn’t look like a standards issue.

I have worked for and know many B2B customers (3DSystem, StrataSys, PTC, dental CAD companies etc.) who are desperate for a high performance cross platform graphics engine (Vulkan) with a cross platform UI that modern, UI/UX developers can jump right into that is much more crash resistant than c++ (Nodejs/Electron).

Vulkan seemed ideal - and still does - for the following reasons.

  • Cross platform consistency
  • Runtime detection of hardware resources
  • Rugged/rigorous validation and error reporting
  • Awesome speed!

So, following the vulkan way, when I saw all those 32/64 bit linker messages I assumed I was doing something wrong and have been trying to fix it. From what I can tell there are some 32 bit libraries lurking in what is supposedly a 64 distribution. That sort of thing weakens one of Vulkan’s primary benefits. It should be fixed ASAP - IMO.

I saw a CMake flag that forces libraries to 32/64 bit versions - I haven’t gotten to that yet.

Shameless plug for what I’m working on.

There are still as small number of 3D design/CAD markets which are horribly CPU bound - both on graphics and computation. GrabCad/Stratasys is trying to do physical simulation of 3D printed translucency in real time - but they are deeply committed to Nodejs/Electron/React for their front end. 3DSystems has similar issues. DOD/Darpa does optical simulations that bog down clusters - and most of their contractors don’t have access to a cluster.

At the same time, from my observations, only well funded game companies with definite markets have the resources to port or write games in Vulkan. Less elite developers experiment with it, but the learning curve and the “3,000 line barrier” cause them to go elsewhere. I’m sure you see many coming in, but from out here I see the vast majority walking away.

At age 60, this looks to me like where Apple/MacOS was with the first Mac. An incredibly rich API that requires a great deal of time to bootstrap. That’s why Apple had a 1,500 line starter app that set up the main event loop and a couple of dialogs - so new folks could get up and running without building their foundation every time. Microsoft even named their version Foundation Classes.

So - VulkanQuickStart and VQSElectron - which I’m working on.

I know of at least two groups which which need this very badly - crossing my fingers they’ll pay when it’s available.

Thanks for your help

I’ve done everything I can think of to assure I’m comparing similar cases - I believe I am.

The full build tree is at

It uses

The following numbers are from the CAE application (which is proprietary) but the main repo shows the same problem.

Windows 10: 0.5 ms / frame
Ubuntu: 2.27 ms / frame

That’s about 5x slower on ubuntu. More than just minor differences.

The builds are of the same repo, same revision.
The builds now detect whether they are in debug or release and the output shows they are both release builds.

The debug validation shows some errors during setup due to an operation being out of order - but those are identical for both builds as well.

The windows case ROCKS! This is exactly what I was hoping to get out of vulkan and when I run it on multiple high end cards, this will totally wow the users.

The ability to run on linux probably isn’t a high priority - this class of user will often buy new hardware to run these cases - but it should work similarly on all platforms.


This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.