GL/D3D11 raw calls and swap/Present in standalone render thread

[JordanPKFX]

Is it safe to make raw GL/D3D11 calls and QOpenGLContext::swap/IDXGISwapChain::Present inside a standalone render thread in parallel to the main Qt widgets thread ?

Very basic tests (gl/d3d11 clear color then swap) seems to work both on windows and linux, but I have no idea of qt implementation dependent stuff on windows/linux/macosx platforms that might be problematic later on.

Here is the pseudo code of the setup:

Main/qt/ui thread widget setup:

void	QMyViewport::setupUI()
{
	...
	QMyRenderViewportWindow		*renderViewportWindow = new ...;
	windowContainer = QWidget::createWindowContainer(renderViewportWindow);
	someLayout->addWidget(windowContainer);
	...
}

Standalone render thread loop:

void	MyRenderThread::runRenderThread()
{
	while (....)
	{
		QMyRenderViewportWindow		*renderViewportWindow = GetMyRenderViewportWindow();
		MyAbstractContext			*context = ...; // gl or d3d11 context/swapchain/device abstraction
		context->makeCurrent(renderViewportWindow);
		renderViewportWindow->myRender(); // no qt suttf, raw gl or d3d11 only
		context->swap(renderViewportWindow); // gl swap or d3d11 Present
		context->doneCurrent(renderViewportWindow);
	}
}

The main purpose of this setup is to have all the gl/d3d11 calls and swap in another thread, so if the render/Qt stalls, it does not affect the Qt/render thread.

(There are some subtitles not specified here, for example the render thread can render multiple QMyRenderViewportWindow, multiple shared contexts, etc...)

The main concern here is about data races with Qt or platform-dependend stuff when swaping in another thread ?

I am less concerned with Qt data races, because there is no Qt calls inside the render thread, there should be only GL or D3D11 stuff. Other events like resizes use message passing from the main/qt thread to the render thread. Input events are only handle on the main/qt thread.