In my last post I covered my attempt to use the NINE state tracker. Since then I've tried a few more things but the results are the same. During this time I've made some observations. One observation is that every version of this modification I've seen has two pieces a customized Mesa branch and a customized WINE branch. Both of these have to be updated every time either project is updated and versions that match what is packaged in distributions should be kept to allow them to function on binary package based distributions. I think a different approach is in order. What I'm proposing is that the state tracker be separate from Gallium3D/Mesa and that the WINE patches be developed separately. The state tracker needs to have Mesa sources to build of course but having it's source tree be separate means that as long as the screen, pipe, and winsys interfaces stay the same updates to Mesa won't break the state tracker. Also with NINE the WINE patches were basically part of the same project because you couldn't use the state tracker without it (by design). There are several issues here starting with the inability to do unit testing or performance tuning without using WINE. In addition the same issue exists with WINE that exists with Gallium3D/Mesa in that a custom patch set has to be maintained. With all of these logistical issues it is no wonder that developers pick up this state tracker and after getting it to a functional state stop working on it. The creator and subsequent maintainers of NINE have done some good work but I think a different approach is required to make D3D9 support on Linux a reality.

My proposed solution is to create a stand-alone Direct3D9 state tracker that is exposed to native Linux developers and is maintained separate from the Mesa source tree. The plan is to allow this to be a separate package that can be installed in Linux systems for applications to link against. The expectation here is that with this API available to developers that WINE patches that may actually be accepted into trunk will surface to use this library when it is available on the target system. This also means that this library could be extended to support platforms were Gallium3D is not available by creating alternate IDirect3D implementations. Another purpose of exposing this API to native Linux developers is quick ports. The NINE state tracker was designed to force usage through WINE so that Linux developers would be discouraged from using it. I'm of the opinion that exposing this library allows better testing to be done against the state tracker and allows IP holders a means of performing quick ports to Linux. More applications using the stack means that it will receive more robust testing. In addition this could provide more revenue opportunities for IP holders and more high quality games for Linux users. Overall this approach provides better division of labor and lends itself better to package management and distribution.

The solution I'm proposing isn't just an idea I've started work on this new state tracker and I'm calling it SchaeferGL (I'm not an egomaniac I promise). So far I've created the interfaces and have coded the method to fetch adapter capabilities. I'm using Gallium3D and MSDN documentation and I'm using the D3D10, D3D11, and D3D9 attempts as reference implementations. My intention was to be able to fire up a window and set a background color by this point but it looks like I'll need another week to hit that milestone. I'm estimating that it will take me 1 year to complete my initial implementation and I've mapped out deliverables for each week. All of my code is posted on GitHub and is released under the terms of the LGPL. This should allow both open source and proprietary development against this state tracker. So far my experience has been that the Gallium3D documentation needs allot of work in fact if I wasn't able to pull up the implementation for methods I'm not sure I would be able to do this project. That being said so far there seems to be good parallels between what I need to do for Direct3D9 and the screen/pipe methods. Also I've noticed that the Linux distribution I'm using doesn't have Mesa headers installed in /usr/include/ so currently I'm referencing a folder in my home directory that contains a clone of the Mesa Git repository. I plan to post updates here as I reach milestones and document the difficulties I face in implementing this state tracker for posterity.


Popular posts from this blog

VK9 - Milestone8 Completed

VK9 - Milestone13 Completed

VK9 - Milestone16 Completed