Drawing issues when running in multiple windows #51736

New Issue

Dalai Felinto · 2017-06-07T18:44:51+02:00

Dalai Felinto commented

2017-06-07 18:44:51 +02:00

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.

**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 ](https://www.khronos.org/registry/OpenGL/specs/gl/glspec33.core.pdf), 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](https://archive.blender.org/developer/P596.txt). 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.

Dalai Felinto commented

2017-06-07 18:44:51 +02:00

Changed status to: 'Open'

Dalai Felinto commented

2017-06-07 18:44:51 +02:00

Added subscriber: @dfelinto

Mike Erwin was assigned by Dalai Felinto

2017-06-07 18:46:24 +02:00

Dalai Felinto commented

2017-06-07 18:46:24 +02:00

Added subscribers: @fclem, @Sergey

Dalai Felinto commented

2017-06-07 18:46:24 +02:00

Speculations

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).

**Speculations** 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).

Mike Erwin commented

2017-06-08 14:14:09 +02:00

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.

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 commented

2017-06-08 14:22:09 +02:00

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.

Clément Foucault commented

2017-06-08 15:16:39 +02:00

I like what @MikeErwin 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.

Sergey Sharybin commented

2017-06-08 15:30:50 +02:00

How important is the multi-different-GPU situation?

Blender should work on any GPU configuration. Period.

> How important is the multi-different-GPU situation? Blender should work on any GPU configuration. Period.

Stephen Hamacek commented

2017-10-15 06:04:39 +02:00

Added subscriber: @StephenHamacek

Stephen Hamacek commented

2017-10-15 06:04:39 +02:00

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

I'm out of my depth, but I thought this might relate to this bug I reported [#52886 ](https://developer.blender.org/T52886)

Dalai Felinto commented

2018-01-23 18:07:17 +01:00

Recommended reading: https://blog.gvnott.com/some-usefull-facts-about-multipul-opengl-contexts/

Dalai Felinto commented

2018-01-30 12:58:07 +01:00

Added subscriber: @ideasman42

Germano Cavalcante commented

2018-01-30 23:55:24 +01:00

Added subscriber: @mano-wii

Clément Foucault commented

2018-02-10 16:01:57 +01:00

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.

@MikeErwin 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.

So I tried one approach that may not be sufficient. See [D3057](https://archive.blender.org/developer/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. @MikeErwin 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](https://archive.blender.org/developer/P608.txt) for more details.

Brecht Van Lommel commented

2018-04-03 16:31:03 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2018-04-03 16:31:03 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2018-04-03 16:31:03 +02:00

Brecht Van Lommel commented

2018-04-03 16:31:03 +02:00

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

I think this has all been addressed by [D3057](https://archive.blender.org/developer/D3057) and c5eba46d7f, so closing.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Drawing issues when running in multiple windows #51736