Developing my own GEM / TTM memory allocation code for OpenChrome DRM and future DRM development projects

For the past few days, I was attending an electronics hardware trade show called DesignCon 2018 held at Santa Clara Convention Center. During that period, I brought my small OpenChrome development computer, HP 2133 mini-note, and continued to work on solving various serious blocker bugs that still exist within OpenChrome DRM in between sessions over at the Hyatt Regency next door.

Most of OpenChrome DRM code appears to have originated from xf86-video-via DDX released around Year 2011 to 2012 and possibly the ill fated VIA Technologies Chrome9 DRM that never got mainlined within the Linux kernel tree around Year 2009 to 2010. Then, a developer named James Simmons further developed OpenChrome DRM up to early Year 2015.

The biggest blocker bug that currently exists within OpenChrome DRM is a nasty bug that crashes the X.Org X Server when changing the screen resolution during runtime. Interestingly, OpenChrome DDX between Version 0.3.3 and 0.4 had the same type of a bug within the UMS (User Mode Setting) code that also crashed the X Server. I was finally able to fix this bug with OpenChrome DDX Version 0.5.

Although I should probably not criticize past developers of OpenChrome, it appears James did not really care about this vital functionality, and other maintainers failed to notice the regression (Note: this functionality worked between Version 0.3.0 to Version 0.3.2). It is funny (actually, it is not) that the same bug strikes again, but this time, it is with OpenChrome DRM.

As a self described newbie to mid-level developer (my own opinion), I must note that it is a pretty hard way to start Linux graphics device driver development with a DRM written by someone else that happened to be incomplete. Fortunately for me, I was able to start this with OpenChrome DDX, which was far easier to get the development going than to start with any DRM (i.e., it is far harder to set up and compile DRM than DDX).

It is my opinion that it is pretty hard to attract newbie developers into Linux / BSD graphics stack development due to various initial set up hurdles that discourage most people from continuing for more than a few days to weeks (I have seen this even with OpenChrome Project. There are definitely a few people who showed interest in developing OpenChrome, but disappeared soon after.).

Going back to OpenChrome DRM, again as a self described newbie to mid-level developer, it is pretty hard to fix other developer’s bug, particularly ones related to GEM (Graphics Execution Manager) and TTM (Translation Table Maps). After studying Radeon DRM for 3 days straight during my free time, I have come to the conclusion of writing my own memory allocation modules that use GEM / TTM.

After months or trying to understand why OpenChrome DRM crashes when the screen resolution is changed during runtime, I think the reason for this bug is due to memory management related issues, particularly with releasing allocated frame buffer memory. One way or another, I have spent a lot of time trying to understand what James Simmons written memory allocation code is doing, but I no longer want to waste my time fixing the bugs he has left behind.

Another motivation of why I will like to write my own memory allocation code, is due to my interest in developing other forgotten graphics devices from late 1990s to early 2000s (i.e., AGP generation graphics devices). I have described my interest in this area during my XDC2017 presentation. What I will like to do is to prove that the new memory allocation code works with OpenChrome DRM and then port it (i.e., code reuse) to DRMs for these devices.


Upgrading drm-next-4.15 branch to Linux 4.15 rc8+

I probably should have waited until I finished upgrading OpenChrome DRM code meant for Linux 4.14 rc7+ to be compilable with Linux 4.15 rc8+, but nonetheless, I pulled in Linux 4.15 rc8+, and committed it into the drm-next-4.15 branch of OpenChrome DRM upstream repository. As a result, drm-next-4.15 branch does not currently compile due to small changes made again to TTM related modules. It took me (mere) 4 hours to figure out the changes, and as I write this blog post, I am compiling Linux 4.15 rc8+ kernel in the background. I need to validate basic functionality after the new kernel port, so it might take me a day or two before I can commit the changes made to the code.

The good news here is that OpenChrome DRM is catching up to the bleeding edge of Linux kernel / DRM (Direct Rendering Manager) development. OpenChrome DRM is still a little off when it comes to using the correct version of Linux kernel for the given drm-next-x.xx branch (i.e., as of today, OpenChrome DRM’s drm-next-4.15 branch should really be called drm-next-4.17), but I should be able to remedy this in the next weeks. Anyway, I expect to move to drm-next-4.16 branch soon, and then in a few weeks, move again to drm-next-4.17 branch. Fairly soon, drm-next-4.16 or drm-next-4.17 branch will be at the same OpenChrome DRM version as the drm-next-3.19 branch (Version 3.0.71).