DevConf.us: Virtual GPUs and C/C++ Refinements

Christophe de DinechinAs DevConf.us approaches, speakers are putting the finishing touches on their talks before they set out for Boston University.

In this interview, Christophe de Dinechin takes a break from his preparations to discuss not one but the three talks that he’s giving during the inaugural edition of this conference.

Q. Let’s open with the easy one: who are you and how did you get to where you professionally are today?

A. My name is Christophe de Dinechin. I joined Red Hat in early 2017. I’m presently working on the SPICE project and on ways to render 3D accelerated graphics in virtual environments.

I have a long-standing interest in system software (compilers, kernels, virtualization) and in 3D. For example, I created the first 3D platform game for the PC, Alpha Waves, released in 1990. To give a rough idea of how old I am, that was one year before Hovertank, John Carmack’s first 3D game. Prior to Red Hat, I mostly spent 16 years with HP, working on real-time test system, C++ compilers and ABIs and initiating their Itanium virtualization project, HPVM. Then I started a small company to develop Tao3D, an open-source project which is a kind of 3D real-time LaTeX Lisp. Our bet on 3D was off, so I moved on and worked on a remarkable camera called the DxO ONE.

Q. Please tell us about your first experience with free/open source software.

A. My first involvement with open source software, mostly as a user, was using Emacs in my very first “real” job (after Alpha Waves, which I had written while I was an engineering student). Our company used a source control package developed internally in Emacs Lisp. So you had no choice but to learn Emacs in order to commit your code. I still use today a “Control-O map” that dates from that period. Interestingly, I also remember a few heated email exchanges from that time with a guy named rms about some Emacs bugs (probably around 1992 😉

I was quite interested by Linux relatively early on. My first Linux at home was, I believe, something called MkLinux, which was Linux running on top of the Mach microkernel. I think it was the first usable Linux on the Mac platform. That’s probably the first time I submitted kernel patches.

In 2000, I created my first “large” open-source project, a programming language called XL that I had been working on for a few years. Initially, it was part of a package called Mozart that aimed to provide meta-programming support for several languages. There was, for example, a Java-to-Java extensible compiler called Moka.

I still work on XL from time to time today, but it’s never been quite successful. It’s the basis for the Tao3D language, for example, and has a variant for the Internet of Things called ELFE (https://github.com/c3d/ELFE), initially called ELIoT, but some company claimed they owned the name in the IoT space.

I think that historically, my most important contribution was the C++ ABI that most compilers use nowadays. It was a collaborative effort, but I believe I played a pivotal role in starting it. My own contributions to that effort were mostly in things like C++ exception handling.

Q. Without giving too much away, what can attendees expect from your presentations?

A. I am giving three talks on three somewhat-unrelated topics.

In “Slicing a GPU – Virtually,” I will be talking about the various approaches to 3D virtualization, and discuss the trade-offs in terms of performance, software compatibility, etc. I think that it’s a relatively easy, high-level talk. I don’t plan to go deep in the technical details. I will talk a little bit about SPICE there, and about the issues related to remove viewing real-time 3D content.

Then “A flight recorder for C and C++ programs” discusses a very small library that acts as a printf replacement and gives you detailed post-mortem data. In short, you record what you program does, and if it crashes, you get a history of what happened prior to the crash. But it can also act as a tracing library or help you graph values in your program in real-time. I use this in SPICE on a regular basis for example to understand what is really going on in the system. This talk should be of interest to anybody developing in C or C++. I would add “whoever used printf for debugging,” but in my opinion, that’s practically everybody.

Finally, “Auto-configuration using make” is a “venting my frustration” kind of talk, meaning that I expect it to be somewhat more funny and controversial than the other two. Don’t get me wrong, I really present a useful tool as well. But my frustration here is that I am appalled by the way most C / C++ open source software is built today. I believe that autoconf and the like are painfully failing to solve a problem that we no longer have anyway. Tentative replacements such as ninja or cmake are largely over-engineered in my opinion. What I present here is how a very short set of makefile includes allows me to build SPICE much faster and with make-only descriptions that are much simpler. So my intent here is to convince you that it’s worth trying at least if you start a new project.

Q. When approaching the subject of your talk, what do you feel are the most challenging issues?

A. For “Slicing a GPU – Virtually,” the primary challenge is finding your way in a vast catalog of solutions. There is no single answer, you need to make an informed decision that is still fundamentally complex – although I expect things to settle down within the next 5 years. So the main issue is to paint a map that is neither too detailed nor too broad.

For “A flight recorder for C and C++ programs,” I often get a feedback that “oh, but I don’t need this or that feature of the library”, so people thing it’s overkill. The challenge for me is to convince people that yes, they actually need it, and that no, it’s not confusion on my part to put together unrelated things, but that I’m really talking about facets of a single problem.

Finally, “Auto-configuration using make,“ the main challenge is the competition is really entrenched. I first need to root out what I think are false beliefs about the necessity to do things this or that way. I did it using Monty Python, and I hope that whoever attends the talk will like that part. There is also a practical issue that the package is still young, so there are bugs or missing features. I’m for example not satisfied of what happens when you get your makefiles wrong (whether in my approach or with automake).

No Comments / Read more

About Brian Proffitt

Brian Proffitt is the Principal Community Analyst for Open Source and Standards team at Red Hat, responsible for community content, onboarding, and open source consulting. A former technology journalist, Brian is also a graduate lecturer at the University of Notre Dame. Follow him on Twitter @TheTechScribe

Leave a Reply

Your email address will not be published. Required fields are marked *