branchsbox/rendercontext-subcontextcancel
4 Commits over 0 Days - ∞cph!
Add IRenderContext::GetSubContext() to get or create a sub context for a new thread, use it in managedsceneobject
Render contexts can never be passed between threads; they can only be used on the thread that created them. The thread index will be set in the constructor and can't change after that.
This causes a problem in our current implementation of SceneCustomObject that reuses the threaded render context on the main thread and expects we can add things,modify and render it from there, for D3D11 it is not a problem since the implementation or driver seems to have a mutex for command lists, but on Vulkan that gives validation errors and causes crashes.
Valve has the concept of Secondary RenderContexts but doesn't fit what we need
This implements the concept of SubThreads to RenderContext, a very simple way to pass the render context around and consume it in a timely manner, it creates a new render context with the same characteristics as the parent one in a new thread and submits it when the parent context is released
Remove pragma optimize off
Only override states if target layer wants it so, otherwise subcontext just uses the default rasterizer and depth stencil state, fixes worldpanels with depth test, pass attributes from rendercontext rather than layer
Only override states if target layer wants it so, otherwise subcontext just uses the default rasterizer and depth stencil state, fixes worldpanels with depth test, pass attributes from rendercontext rather than layer
Remove pragma optimize off
Add IRenderContext::GetSubContext() to get or create a sub context for a new thread, use it in managedsceneobject
Render contexts can never be passed between threads; they can only be used on the thread that created them. The thread index will be set in the constructor and can't change after that.
This causes a problem in our current implementation of SceneCustomObject that reuses the threaded render context on the main thread and expects we can add things,modify and render it from there, for D3D11 it is not a problem since the implementation or driver seems to have a mutex for command lists, but on Vulkan that gives validation errors and causes crashes.
Valve has the concept of Secondary RenderContexts but doesn't fit what we need
This implements the concept of SubThreads to RenderContext, a very simple way to pass the render context around and consume it in a timely manner, it creates a new render context with the same characteristics as the parent one in a new thread and submits it when the parent context is released