I just thought “mostly software rendered” was a bit strong. I think most of the SGI machines intended for graphics work had z buffers when OpenGL was released, texture mapping is a different story although it appeared not long after (we used indigo 2 machines with texture mapping at a previous job, and I thought they were older than they were… but google tells me the texture mapping versions were not released until 1995 and opengl was 1992). But yeah I take the point that it was designed with software fallbacks in mind, and that it is irrelevant to the vulkan vs opengl argument.
Glove and GL4ES could be used to implement OpenGL-ES and OpenGL over Vulkan drivers respectively. The catch is… Where does one find Vulkan drivers?
That’d be ANV and RADV from Mesa3D… but you need all the bits for accelerated OpenGL anyway to make those work so Vulkan to GL wrappers would be pointless.
Track Mesa development and the major graphic card providers (in which they’ll provide commercial Vulkan driver support on supported platforms and compliant drivers today).
We have Mesa 17.1.10/18.2.0+ and OpenGL ES built for Haiku. So, we can support Vulkan/OpenGL driver development on the latest Mesa snapshots using Haiku… 
2 Likes
Technically we only have OpenGL, as I was saying before, Vulkan support will for the time being require hardware acceleration support which we won’t see until someone works on it. Also last I checked the latest Mesa3D build was broken, so we are currently at 17.1.10 I think and above that requires some fixes.
True for right now. The Mesa 18.2 Gallium 3D driver is ‘broken’. Vulkan driver development without
supporting hardware is like a beautiful car without momentum. Nice to look at. 
Update:
- Added Vulkan 1.1.85 update to Mesa build.
- Repaired Mesa 18.2 Gallium driver (w-i-p, testing).
My Mesa dev build has OpenGL ES libs, so I my comments stem from my own dev worlk.
Or like an erector set still in the box… some assembly required 