Overcoming OpenGL ES's Limitations

When Vulkan is described as an explicit API, meaning that developers are required to tell it exactly what they want, rather than relying on defaults or driver heuristics to perform the correct function. By not being explicit, older APIs suffer from a number of subtle issues that are hard to debug and can be difficult or even impossible to fix or work around.

Table 1. Explicit API Redesign
OpenGL Vulkan
Originally architected for graphics workstations with direct renderers and split memory Matches architecture of modern platforms including mobile platforms with unified memory and tiled rendering
Limited and random performance as driver does lots of work: state validation, dependency tracking, error checking, etc. Explicit API - the application has direct and predictable control over the operation of the GPU
Threading model doesn't enable generation of graphics commands in parallel to command execution Multi-core friendly with multiple command buffers that can be created in parallel
Syntax evolved over the course of 20 years - complex API choices can obscure optimal performance path Removing legacy requirements simplifies API design, reduces specification size, and enables clear usage guidance
Shader language compiler built into driver. Only GLSL supported. Have to ship shader source SPIR-V as compiler target simplifies driver and enables front-end language flexibility and reliability
Despite conformance testing, developers must often handle implementation variability between vendors Simpler API, common language front-ends, and more rigorous testing increases cross-vendor functional and performance portability