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
==========
VULKANINFO
==========
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