Just to offer a counterpoint (and I'm happy to discuss), Vulkan has much better load-balancing and resource-sharing potential than OpenGL. Resource Sharing: -

Just to offer a counterpoint (and I'm happy to discuss), Vulkan has much better load-balancing and resource-sharing potential than OpenGL. Resource Sharing: -------------------- Vulkan requires the application provide verbose information about the features being used. Vulkan also reports the number and types of heaps, their sizes, and detailed information on the max number of each type of resource the application can allocate. OpenGL allows the application to just "go for it," allocate resources without bound [1], and the driver will attempt to "make it work." The only way the application knows it has reached a limit is when the driver finally fails with GL_OUT_OF_MEMORY. When the driver and OS need to move resources around, such as if the GPU's memory is exhausted, Vulkan applications are much easier to manage. A Vulkan application's memory will be clearly structured so that the driver can identify little-used resources and relocate them so that the next application can get the resources it needs. Load Balancing: ------------------- Vulkan requires the application to be much more explicit about which queues and devices the application will be using, and even what priority the application places on different loads. OpenGL again has no such concept. An application can only access OpenGL from a single thread, and OpenGL just lets the application "go for it." When the driver and OS need to load balance, a Vulkan application is much easier to load balance. Any rendering or compute in Vulkan is explicitly defined with clear fences, transitions and barriers. The OpenGL application's only mode of operation is "why didn't this run faster?" The GPU vendor's OpenGL driver contains hundreds of application-specific tweaks to the OpenGL API to try to accomodate one particular application. The GPU vendor's Vulkan driver has not been around long enough to accumulate much of that bitrot. In summary, neither API explicitly triggers load-shedding behavior in the application. The Android app lifecycle is a completely different story. On desktop machines, Vulkan and OpenGL applications are designed with very few constraints. They mostly are expected to be the main or only application running, and expect to run on machines with medium or high-end specs. The OS and driver manage load-sharing and resource-sharing silently behind the scenes. With Vulkan, however, the OS and driver have a much easier time for the reasons discussed above. I recommend Vulkan strongly for all new development. [1] https://stackoverflow.com/questions/6354208/glgentextures-is-there-a-limit-to-the-number-of-textures https://stackoverflow.com/questions/6354208/glgentextures-is...