[Mesa-dev] [Bug 8645] Issue when rendering with 2 contexts to one window

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=8645

--- Comment #9 from Wolfgang Draxinger <bugzilla+bugs.freedesktop.org at datenwolf.net> 2011-11-08 06:42:35 PST ---
Indeed a single drawable may have serveral OpenGL render contexts on it, which
also may be active in multiple threads at the same time. This is a common setup
to allow for such things like uploading texture or buffer object data, while
other threads are blocking, say in glXSwapBuffers. Blocking glXSwapBuffers on
V-Sync may give up to 1/50th (say if someone slightly missed a previous frame's
retrace deadline) of free CPU and GPU time, which is worth using.

But as soon as you go about drawing to the same drawable from multiple render
contexts you're begging for trouble. Effectively the target framebuffer is a
mutually exclusive, but shared resource, so the driver constantly has to switch
locks, and of course the whole rendering process (sending geometry, etc.) is
just one big race condition. The bug submitter's test case is just a perfect
example for such a race condition.

Now I see, that the original application is D3D9 multithreaded rendering
emulation. Personally I never experienced (native) D3D9 multithreaded rendering
usefull for something else like generating render-to-texture content. Anyway:
It is right that OpenGL contexts can be used from only one thread at a time,
BUT THEY ARE NOT BOUND TO A SPECIFIC THREAD! Once can unbind the context from
one thread, and rebind it to another:

thread_A:
    glXMakeContextCurrent(display, drawable, drawable, NULL)
    signal_thread(thread_B, "context released")

thread_B:
    wait_for_signal("context released")
    glXMakeContextCurrent(display, drawable, drawable, context);

It may also be worthwile for the D3D9 emulator to use a PBuffer drawable (maybe
in combination with a FBO, featuring depth texture attachments); instead of
glXSwapBuffer at the and of each thread signal that each threads composition
layer has been finished and only the last finishing thread should then collect
all intermediary pictures and combine them into a composition, implementing
things like depth testing and the like there.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.