Posts

Showing posts from August, 2014

SchaeferGL - The New Plan

I managed to create all of the interfaces I needed and had started work in the Gallium3D state tracker when I ran into some problems. The first thing that I ran into is huge inconsistencies in driver performance. Because of this issue only a limited number of AMD graphics cards would actually benefit from the design I proposed. In addition Direct3D is designed to work with Windows windows when running in a window. I could hack around that but I suspect that would be a brittle integration. The other issue I've run into is the lack of documentation for Gallium3D. I've found a couple places to look but one is incomplete and the other is basically just a listing of methods and structures with almost no comments let alone usage examples. All of these issues have led me to take another look at the purpose of this project. The end goal of SchaeferGL is to allow D3D9 games such as EQ2 to run on Linux with good performance. My original assumption was that the approach that Wine took t…

SchaeferGL

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 …