GraphicsDevice is responsible to use the right context.
Directx12 vs opengl 4.4 code#
It's easy to convert existing code by wrapping it into a DrawAsync() action or BeginDeferred()/ EndDeferred(). GraphicsDevice has to forward all context related updates to the current content through getters/setters. The main difference from #2772 is that GraphicsDevice will not inherit from GraphicsContext and we don't need to expose GraphicsContext and its methods. We must also wrap DeviceContext along with Dirty flags, Vertex/Index buffers into a separate GraphicsContext Class. This can be done by changing _d3dContext into private static DeviceContext _d3dContext. The idea is to let GraphicsDevice provide the current context on a per thread basis. GraphicsDevice.Execute() awaits for t1result and execute it on the immediate context. It could accept an action, an IDrawable or a delegate with signature DrawDelegate(GameTime). GraphicsDevice.DrawAsync() will run test1.Draw() on a separate thread/context and return a Task. do other drawing on the main thread/context Var t1result = GraphicsDevice.DrawAsync(() => ) It would be nice to support both this new API and our existing one at the same time, but we could just make a clean break if we feel confident about it. The next bigger step is designing a new graphics API for MonoGame that better aligns with Vulkan/DX12/Metal features. Likely this will also require support in the content pipeline for new shader formats as well. There are potentially (I will know for sure soon) some performance benefits to be gained just by doing that. The most immediate thing would be shoehorning these into our existing XNA style APIs.
This makes MonoGame even more useful to developers if we support them well. These new APIs are more verbose and require more setup code to do similar things as previous graphics libraries. We need to plan how we want to approach supporting the new graphics APIs: Vulkan, DirectX 12, and Metal.
0 kommentar(er)
