Future of OpenGL/OpenGLCompute needs deciding #5475
Comments
|
The OpenGL (non-compute) backend is extremely limited and probably not worth keeping. However, I think OpenGLCompute is worth saving and will definitely help us get Vulkan going (since they are semantically very similar). The major limitation of OpenGLCompute AFAIK is poor support for anything except 32-bit types; we will need to solve this for Vulkan as well. So I propose:
|
|
On that note, I'm almost inclined in creating a general gpu back-end run-time subsystem, and there is a lot of code in the gpu back-ends that could be shared among each other. |
|
We need to decide on this. I think @shoaibkamil's proposal to deprecate in Halide 11 and remove in Halide 12 is a good one. We need to support this with loud warning messages when using the OpenGL backend. |
|
I wonder whether #5545 should influence our thinking on this. I think it would be good to get it reviewed and merged for Halide 11 but still move forward with deprecation. The current model of "let OpenGL bit rot until someone fixes it" isn't really sustainable. |
|
I'm all in favor of landing #5545 if it passes review. |
|
The issue with OpenGL is not so much bit rot but that it never worked very well in the first place. Some of this is the compiler implementation, but some of it is fundamental limitations in OpenGL itself. (As well as the practical realities of the ecosystem around it.) We can certainly improve the compiler, but if every use case has it dominated by another approach, it seems wasteful to push on this. |
|
From our discussion today, it sounds like we will deprecate OpenGL in Halide 11, which means we need to add a warning. Then we will outright remove the code from master once it's released. |
alexreinking
added
the
release_notes
|
I'll add warning(s) |
Fixes #5475 This removes the OpenGL backend (but *not* the OpenGLCompute backend) from public use: - Remove Target::OpenGL - remove DeviceAPI::GLSL - remove Func::glsl() and Func::shader() - remove all OpenGL-specific apps and tests - remove HalideRuntimeOpenGL.h - remove some internal code that is OpenGL-only Note that there is still internal code that needs trimming; since the OpenGLCompute backend uses some of the same code, and some of the same build deps, and some of the same runtime shared-library loading, I tried to err on the side of leaving code/buildrules/etc in place for now, with the plan to clean that up in subsequent PRs. Note also that feature Target::EGL is still present, as I believe it is still useful in conjunction with OpenGLCompute.
* Remove OpenGL support (part 1) Fixes #5475 This removes the OpenGL backend (but *not* the OpenGLCompute backend) from public use: - Remove Target::OpenGL - remove DeviceAPI::GLSL - remove Func::glsl() and Func::shader() - remove all OpenGL-specific apps and tests - remove HalideRuntimeOpenGL.h - remove some internal code that is OpenGL-only Note that there is still internal code that needs trimming; since the OpenGLCompute backend uses some of the same code, and some of the same build deps, and some of the same runtime shared-library loading, I tried to err on the side of leaving code/buildrules/etc in place for now, with the plan to clean that up in subsequent PRs. Note also that feature Target::EGL is still present, as I believe it is still useful in conjunction with OpenGLCompute.
Per various offline discussions (and some online, eg #5474), our OpenGL backend has many limitations/problems and is arguably of dubious value even if implementation issues are fixed. We should really decide whether we want to improve it or officially deprecate/remove them.
Strawman proposal to start a discussion:
The text was updated successfully, but these errors were encountered: