Large Texture Multiple Monitors

Started by
4 comments, last by JohnHardy 4 years, 5 months ago

Hello!

I am writing an multi-window application that does some data vis on many 4K monitors.  My challenge is that, on each monitor, I need to sample from a massive texture (shared between the windows) as a efficiently as possible. Luckily, it just fits under the resolution limit. However,  I don't know the best way to configure OpenGL for best performance in this situation and could use some pointers.

My current thinking is that the best bet is to avoid loading the texture 4 times (saving GPU memory and possibly some cache benefits?), render 4 separate windows, and then share the context between them.  I only have a single draw call per window (a large almost-full-screen plane). 

I guess my questions are:

  • Is there actually a performance benefit to doing this, or is it just a memory saving?
  • Is there a way to just share the texture rather than work in a single context? Is this better / worse?
  • Does it matter that the monitors may be plugged in / unplugged during run-time and would that mean I have to re-create the context or can I create a context without it being tied to a monitor?

Thanks!

Advertisement

Is it a single process ? 4 different processes ?

If I understood you well, you use the same image for the 4 renderings ?

I believe that, from the few technical information you gave, the easiest thing would be to have a single process managing 4 different windows, all of them having their own context, shared between each others.

Yea it's the same image for each rendering/window. At this stage it can be a single process if it's beneficial (although it may be harder to code?).

Is there a perf benefit or will I see the same sampling speed?

I've knocked up a WebGL prototype in THREEJS and I was wondering if doing it natively will improve performance.

Thanks for your help!

You should have a look at this spec

From what I know, this will be difficult (or even surely impossible) to share contexts between processes. However I think I can remember (this is totally unsure and cannot find again the relevant source) that it could be possible.

Switching from a context to another, or keeping a sync over different contexts can have an impact on performance. Not that much, but it can have an importance, depending on your needs. If you have a single process, and each threads has their own contexts (shared between them), then you will only have to deal about knowing when each can render (when the texture is ready and this is at the same time for all). No need to manage context synchronization since they will all be independent. 

Note also that OpenGL containers are not shared between contexts.

Thanks! Is there any literature on the differences WebGL Vs OpenGl overhead for large texture sampling? 

This topic is closed to new replies.

Advertisement