Posts

Showing posts from 2014

SchaeferGL - BOOST & C String Methods

I've had to work multiple weekends which has delayed progress on SchaeferGL. However, i've been able to resolve more build errors. After switching the collections over to standard C++ collections I've also needed to update all of the for each loops (an effort which is still in progress). ToGL uses custom Valve macros to handle for each loops and there are different versions. I've been replacing them with the for each macro from the boost library. I've used it in the past and it has worked well for me. I've not used it in a project a performance sensitive as this one so once SchaeferGL builds I'll need to review the performance of this implementation choice. Another item that I've been working on is replacing the custom string methods with standard C string methods. One exception is a custom version that includes the length to compare. I'm using "memcmp" for that purpose. These like the for each loops will need to be reviewed for performanc…

SchaeferGL - Continued

This will be a fairly short post but I should have more to share next week.

Work on SchaeferGL is still in progress. I am still in the process of getting the ToGL code to a point where it will build. I've also made a little progress on ABI compatibility. Originally I was using the interface classes from my State-Tracker attempt, however that setup isn't compatible with the native implementation. I'm now using the appropriate COM interfaces. Another piece I've been working on is ToGL's usage of containers. There are custom Valve containers that are in use in the code base but not included. I've been slowly switching those over to STL containers as part of my effort to make it compile. It's difficult to gauge how close I am because after a point the compiler stops trying so fixing build errors reveals more errors. I'm hopeful that I'll be able to get it to build this month.

Thanks for reading.

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 …

Direct3D on Linux via Gallium State Tracker

In my previous post I talked a little bit about a state tracker that I discovered that claims big gains in performance for Direct3D 9 games running under Wine. I was planning on waiting for Wayland but I wanted to test this thing out. I converted my guest PC into a Peppermint Linux machine. The open source AMD graphics driver has direct rendering support for it's graphics card so it makes a good test machine. Unfortunately neither the nine state tracker nor the wine patches made it into their respective upstream projects. What this means is compiling code from source and installing the libraries & headers yourself. It's a shame because this seems like a good enhancement but it only applies to Linux (Wine is cross-platform) and only to open source drivers so this hasn't received the interest I think it deserves. Below are the steps I've taken so far to get this up and running.Download and extract the modified Mesa-3D and wine source. https://github.com/chrisbmr/Mesa…

Linux & Everquest 2

There are some interesting things going on with Linux recently. One of the big changes is that most major distributions are phasing out X server in favor of Wayland or in the case of Ubuntu mir. To see what all the fuss was about I started doing some reading on the Linux graphics stack. While looking into that I also found about Gallium3D which is an API/framework for graphics drivers. The importance of this to me is that I found out that there is a state tracker (basically a front end API that plugs into Gallium3D) for Direct3D 9. In addition there are patches for WINE (a Windows compatibility layer) that bypass WINE's Direct3D implementation can call this fancy new state tracker. The articles I saw were claiming double or better performance. The hitch is that the closed source drivers from Nvidia and AMD aren't Gallium3D compliant. The good news is that Open source graphics driver support seems to be much better than the last time I fiddled with it. Overall with an open sour…