Speed up non-GPL compatible renderer's Blender addon with OpenGL driver and GPL system library exception?

I have no plans what so ever to write anything specifically designed to interface with Workbench or Eevee. What Blender would do with any 3D api now or in the future would be irrelevant to what I had in mind. What I am contemplating is to interface with my OpenGL driver from my GPL addon.

2 Likes

Ok, so the idea is to have a proprietary library with the same API as a system library but not actually use it as a system library that would have been part of the operating system.

I still think that’s trying to get around the intent of the GPL on a technicality, so personally not interested in helping figure that out.

1 Like

We’re on the same page there, If you have paid attention, i have beyond “that sounds like a crazy bad idea” purely kept to the to the question asked.

Apparently, there’s also such thing as “OpenGL inter-process GPU resource sharing” which, without a custom OpenGL driver, might allow to call glMapBuffer(GL_PIXEL_UNPACK_BUFFER) in the renderer’s server process to efficiently upload rendered images directly to the GPU to the same OpenGL texture that the addon uses for its glDrawArrays() call. This would have no overhead and solve my minimum requirements to make the addon usable. Everything else could probably be communicated over more typical inter-process methods, which also support shared memory, but it sounds like that would have one extra memcpy for the GPU image upload.

1 Like