Blender is considering ending OpenGL support in version 6.0, its next major milestone. The internal proposal was presented at the Viewport & EEVEE development meeting on October 5, 2026, and the meeting notes assume a 6.0 release in November 2027. The removal has not been decided, however, and virtual texturing was cited as one outstanding issue. Work on moving features to Vulkan is progressing, and in 5.3, which is currently in development, Vulkan is on track to become the default rendering backend. But whether it can adequately replace OpenGL in production environments that handle large numbers of textures will help determine whether OpenGL can be removed. Moving to a new graphics API is not the same as being able to let go of OpenGL entirely. Development meeting notes
Vulkan support, Vulkan by default, and OpenGL removal are three separate stages
Vulkan support in Blender 4.5 LTS, Vulkan as the default in the in-development 5.3, and the OpenGL removal being considered for 6.0 are distinct stages. Sorting the official release notes on Vulkan and the October 5 meeting notes into three perspectives (available features, default settings, and end of support) makes the current situation easier to understand.
| Version / status | Change described in official materials | Relationship to OpenGL |
|---|---|---|
| 4.5 LTS (released) | Vulkan has feature parity with OpenGL and supports OpenXR, subdivision, and more | OpenGL is the default; Vulkan can be selected in settings |
| 5.3 (in development) | Vulkan becomes the default on Windows (except Windows ARM) and Linux. Minimum requirement lowered to Vulkan 1.1 | A change of default setting, separate from removing OpenGL |
| 6.0 (internal proposal) | Ending OpenGL support is under consideration | Virtual texturing remains an issue; removal is undecided |
Sources: Vulkan section of the 4.5 LTS notes, Vulkan section of the 5.3 notes, October 5 meeting notes on OpenGL removal. This compares the entries as of October 6, 2026, and is not a performance comparison.
While Vulkan is offered as an option, users can fall back to the existing backend if problems arise. Making Vulkan the default means many more users will encounter it in normal operation. Removing OpenGL eliminates that fallback altogether. Even if Vulkan is judged to match OpenGL feature for feature, that alone does not mean OpenGL can be fully retired.
Lowering the minimum Vulkan requirement in 5.3 and making some GPU and driver features optional also fits into this trend. The move to the new API and the effort to widen the range of usable hardware are proceeding in parallel. Note that on the official releases page, 5.3 is still in Alpha, with a release planned for November 2026. Changes listed for a development build should not be confused with features already available to all users.
Why Blender is leaving OpenGL, and the practical benefit of HDR display
In its 2023 explanation of the Vulkan migration, the Blender team cited differences in OpenGL driver implementations and the accumulated workarounds needed to avoid the resulting bugs. Even with the same API, behavior differs by GPU vendor, and an optimization for one vendor does not necessarily improve performance on another. Blender bore the ongoing burden of absorbing those differences.
The team has also said it is moving away from OpenGL in order to take advantage of new rendering features, including hardware ray tracing. The setup is Vulkan on Windows and Linux, and Metal on macOS. For Mac, the policy of supporting only Metal from 4.0 was already announced, so this proposal can be seen as an extension of the ongoing overhaul of the graphics foundation for each OS.
One benefit users can see directly is HDR and wide-gamut display. In the Blender 5.0 color management features, compatible displays can show imagery with a wider range of brightness and color. On Linux, using Wayland and Vulkan is a requirement. On Windows, HDR and related settings must be enabled in the OS, and Vulkan must be selected in Blender.
In other words, a change of graphics API should not be judged on interaction speed alone. When producing HDR content, it also affects the range of brightness and color visible in the editing window. However, these features are available only when conditions such as the display and the OS are met, and simply switching to Vulkan does not give the same display in every environment.
How to fit large numbers of textures into GPU memory
The Vulkan limitations in 4.5 LTS state that all textures must fit in GPU memory. The amount that can be handled differs from OpenGL and also varies by GPU vendor and driver. This is the description as of 4.5 and does not indicate the final specification of 6.0. Even so, it is a concrete example showing that reaching feature parity with OpenGL is a separate matter from handling scenes with many images under the same conditions.
Textures are the image data that give a model's surface its color and detail. With virtual texturing, a large image is divided into small regions, and only the needed parts are loaded into memory. Rather than holding the entire image at once, the system manages the regions and resolution actually in use. However, the October 5 meeting notes do not explain which implementation or GPU feature is actually lacking. It cannot be concluded that a specific driver or a specific Vulkan feature is the obstacle to removing OpenGL.
Blender has another implementation that shows how difficult this problem is. The Cycles texture cache, developed for 5.2 LTS, loads only the image tiles and resolutions that are needed. According to the developers' design explanation, the common CPU approach of making a computation wait until the required tile has loaded is hard to carry over directly to the GPU. On a GPU, a very large number of operations run concurrently, and direct disk access during computation is normally not possible.
Cycles therefore adopted a design that collects the unloaded tiles requested by each operation, loads them in a batch, and then re-runs the GPU computation. Using a low-resolution substitute image until the needed image arrives was also rejected, because accurate rendering results are required. Reducing memory usage required redesigning not only where images are placed, but also the mechanism for pausing computation, loading the needed data, and resuming.
That said, this cache is an implementation for Cycles, and it does not mean the issues raised in the meeting notes for the Viewport and EEVEE have been resolved. Even within Blender, real-time screen drawing and the rendering that computes accurate images each need texture management designed to suit them.
The role of Cycles compute APIs and the display backend
According to the 5.2 LTS manual, Cycles GPU rendering uses CUDA and OptiX for NVIDIA and HIP for AMD. oneAPI is available for Intel and Metal for Apple. These differ in both settings and role from the display backend, where you choose between Vulkan and OpenGL.
The display backend is the foundation for drawing Blender's user interface and 3D viewport on the GPU. Cycles compute APIs, on the other hand, are used to run rendering on the GPU. Even if the OpenGL removal proposal is carried out, it does not mean Cycles' CUDA or OptiX will be replaced by Vulkan. Nor can Cycles rendering speed be inferred from Vulkan display performance.
For ray tracing as well, it is necessary to distinguish which rendering process uses it. What the 5.3 development release notes describe is a feature that uses hardware ray tracing for Workbench shadows. It targets Metal and Vulkan and requires a GPU and backend that support ray queries. This cannot be read as an announcement that EEVEE as a whole is moving to hardware ray tracing.
From drawing a line on old GPUs to verifying production environments
The Vulkan support table in 4.5 LTS shows that it is hard to judge whether a migration is feasible by GPU generation alone. For example, Intel 6th- to 10th-generation integrated GPUs are unsupported on Windows, while on Linux a configuration using Mesa is listed as a supported path. AMD's HD 7000 to 8000 series likewise differ: unsupported on Windows, but usable on Linux with Mesa. Even for GPUs of the same generation, support varies with the combination of OS and driver.
This table cannot be used as-is as the support table for a future 6.0. In 5.3, changes were also made to relax the minimum Vulkan requirement. What matters for users is not to judge only by whether their GPU supports Vulkan, but to open actual production files with their own OS and driver combination and check that there are no problems in the display modes they normally use and in scenes containing many textures.
Existing versions that use OpenGL will not become unusable immediately because of this proposal either. Blender continues to offer older versions for download and says they can keep being used as long as supported hardware and an OS are available. However, bug fixes for LTS versions are provided for two years, and being able to download an old version is a separate matter from receiving ongoing fixes.
Whether OpenGL can be removed in 6.0 depends on how the issues around virtual texturing are resolved and whether sufficient operation can be confirmed in real production environments. If memory can be managed properly even in scenes with large numbers of images, and display conditions on each OS are in place, users will be able to move their production environments while taking advantage of new features such as HDR.