Page MenuHome

Drawing issues when running in multiple windows
Closed, ResolvedPublic


Short description of error

When using Blender with multiple-windows, you can't use Clay, or Eevee.

Detailed issue

The OpenGL 3.3 core profile documentation, Appendix D, page 336 clearly states that:

Framebuffer, query, and vertex array objects are not shared.

If we force OpenGL context to share every single resource, things work. To try this in Linux you can apply the following hack/patch: P596. However this doesn't work well if user has multiple graphic cards and move windows around between them. In Blender we only resort to that if user has intel cards.

Proposed solution

First and foremost we need to get rid of static allocated elements as we do now in places like draw_cache.c. They can safely be moved to a struct owned by the Window, while some global stuff could be owned by WindowManager.

Second we need a non-shared-OpenGL-resources-manager. A system that allocates and retrieve them per window. We need this for OpenSubdiv as well, since we also rely on VAO there. Ideal solution and implementation open for discussions.



Event Timeline


We seem to rely on VAOs for the Batches (see batch.c). And in some cases those batches are statically created (e.g., DRW_cache_fullscreen_quad_get).

Dalai Felinto (dfelinto) triaged this task as Confirmed, Medium priority.Jun 7 2017, 6:46 PM

How about a more radical approach? Have one drawing context that all the windows use. The GPU already draws in sequence whether we have one context or many. The one drawing context has all VAOs so we don't have to manage anything ourselves. Adding yet another manager isn't the only solution.

How important is the multi-different-GPU situation? I've thought about this but never worked out a real design or heard any feedback (until this task!). We currently make assumptions in the code about GL version, limits, capabilities being similar for the whole system. Assumptions that aren't true given different GPUs. Yet Blender still works! Which suggests people generally don't rely on multiple display GPUs from multiple vendors.

Mike Erwin (merwin) added a comment.EditedJun 8 2017, 2:22 PM

FYI our new immediate mode handles this by recreating its internal VAO every time we start drawing to a different window (each window has its own GL context). Much simpler there because imm has only one VAO total, not one per batch, potentially thousands.

I like what @Mike Erwin (merwin) said! Lets draw every viewport on context A. Since we already draw viewports to offscreen textures, we can just output the viewport texture (rendered in Ctx A) to window with Ctx B.

How important is the multi-different-GPU situation?

Blender should work on any GPU configuration. Period.

I'm out of my depth, but I thought this might relate to this bug I reported T52886

So I tried one approach that may not be sufficient.

See D3057 for my attempt on having only one context for every viewport.

While this works quite well, we have another issue. VAO management. The UI still uses batches (very sparsely) that have a single VAO and does not draw on every new window context.

@Mike Erwin (merwin) I too did not want a new manager for this issue but the bad VAO usage is hurting performance too. So I tried to come up with something as lightweight as possible for managing lots of VAOs. See P608 for more details.

Brecht Van Lommel (brecht) closed this task as Resolved.

I think this has all been addressed by D3057 and rBc5eba46d7f4d, so closing.