When drawing a scene with 6 textured triangles (red, green, blue, red, green, blue), the sequence of events would look like this: Mission accomplished, it was really slow! For each draw call, we were setting the entire pipeline state, filling the descriptor heaps, recording the draw command, immediately executing the command list, and waiting for it to finish.
#Mesa opengl 4.6 driver#
Our initial implementation of the driver was as straightforward as possible, as we wanted to validate our approach and not focus too much on performance early on. This is one of the biggest sources of impedance mismatch when translating from GL, where applications set global state parameters and the final state is only known when a draw call is submitted. Like DirectX command lists, Vulkan pipelines are immutable once created and recorded. Vulkan follows a similar model, with VkPipeline objects encapsulating state such as image formats, render-target attachments, blend modes, and shaders all bounded into a single object. (de)compression) and that the cache is coherent. The exact details of the transition vary from hardware to hardware, but it would minimally makes sure that all writes to the texture are completed, that the resource has the proper layout (e.g. For example, before sampling from a texture, we need to make sure that the source is in the D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE state. Transition barriers are required to garantee the proper state for a command.
But before we can record drawing commands, we first need to set some state on the command list. clearing the render target, draw calls, etc.) into a ID3D12GraphicsCommandList and then call Execute() to actually process the commands. In order to better understand the next sections, let's dive a little more into the details of DirectX 12.ĭirectX 12 requires that we record commands (e.g.
We added a new implementation using DXGI Swapchains. Internally, an existing implementation of the windowing system was using GDI (Graphics Device Interface) to actually display the rendered frames on the screen. I'm not gonna focus on the NIR-to-DXIL compiler here as it definitely deserves its own blog post.įinally, a different component of Mesa, the WGL State tracker, is handling WGL calls (API between OpenGL and the windowing system interface of Windows).
We use that representation to produce the DXIL bytecode consumed by DirectX. Mesa will also translate GLSL shaders into an intermediate representation named NIR. On the shader side, the state tracker is able to convert OpenGL fixed-functions, traditionally implemented directly by the hardware, into shaders. The "D3D12 Driver" is thus an implementation of that interface. The Mesa state tracker is responsible for translating OpenGL state (blend modes, texture state, etc) and drawing commands (like glDrawArrays and glDrawPixels) into objects and operations that map well to modern GPU hardware features (Gallium API). People familiar with that project will therefore experience a strong déjà-vu feeling when looking at the architecture of our current effort: Zink, a project started by Erik Faye-Lund, has already proven that we could achieve a similar goal: translating OpenGL to a lower-level graphics API (s/Vulkan/DirectX12/). In the initial steps of this project, we quickly realized that the best way forward was to build on top of Mesa. Time for a summer update! In this blog post, I will explain a little more about the OpenGL part of this work and more specifically the steps that have been taken to improve the performance of the OpenGL-On-D3D12 driver.
Earlier this year, we announced a new project in partnership with Microsoft: the implementation of OpenCL and OpenGL to DirectX 12 translation layers ( Git repository).