Interview: Kaveh Nasri, Intel Open Source Driver

Interviews



From hardware to screen, Chris Thornett interviews Kaveh Nasri about Intel's extensive work on the open source driver that enables us to play games on Linux.

Linux Format: Can we start by introducing yourself and what you do, please?

Kaveh Nasri: Hello, I’m the engineering manager for Intel’s Open Source 3D graphics driver. We’re part of intel’s Open Source Technology Center (OTC) and part of Intel’s Software Services group. Our job has been, for many years, to enable Linux on Intel hardware.

We’ve recently become the No.1 contributor to the Linux kernel, in terms of the number of patches that are submitted. We have contributed greatly to the Linux ecosystem. Simply because it helps Intel silicon, and we want to make sure that people that choose to use Linux variant on our silicon can do so without problems.

What my team does is develop the graphics driver for intel’s integrated graphics, and we’ve been doing this for over seven years. Starting out with a very modest group and now we’re a size where we can keep up with the Linux demand, which wasn’t as great as before, when it comes to 3D graphics, and more and more people are using Linux in a way that needs, not just reliable graphics, but high performance graphics. This is where games come in.

If you run a spreadsheet and that’s all you’re doing on your Linux box, then 3D graphics doesn’t come into play that much. As long as your hardware graphics is basically working you can get your work done. But once you get into playing games it becomes a different story.

You don’t just need 3D graphics to work, you need it to work well, reliably. You need to be correct, you don’t want to see artefacts, jagged edges, and you also want to get good performance in terms of frame rates and so forth.

LXF: Have you increased support in recent years?

KN: It’s all based on what the market is demanding, right. More and more people are using Linux, therefore, we respond to that. By having more of a focus on it. And it’s not just our organisation doing it, there are many platform organisations in Intel that are adding to their Linux expertise and Linux support. We happen to be the Linux arm of the operation at the heart of it all.

LXF: Does this link into Mesa?

KN: Correct, our driver is based on the Mesa project, [which began in 1993]. Back then Intel decided to have a Linux driver that wasn’t just supported by the community but one that Intel actually made contributions to. There was already an open source framework available, so why not use that? That’s what we did, so basically we’ve been contributing to the Mesa project, but our focus, of course, has been how well it works on our silicon. There are other folks who use the same framework to have drivers based on Mesa work for AMD, Nvidia etc. There’s some cooperation at a small part of the stack goes on so that there are no conflicts and that the framework can be used.

Basically, our code is on Mesa3D.org, that’s where it all comes from and we have found the framework and the set up there to be very useful to us and that’s what we continue to base our driver on.

LXF: In terms of where we’re at now - have there been any particular technical challenges or landmarks that you’ve needed to get past to reach the stability that we’re seeing now?

KN: Stability has always been a hallmark of our driver. If the driver isn’t stable; it’s not useable. Our three tenets in terms of the attributes of our driver are: No.1: Correctness - we want the graphics to show up the way the author intended it to. No.2: Stability - so it doesn’t crash or have problems . No.3 is Performance. So correctness and stability have always been our two things we prioritise. So stability has never been a question, as far as we’re concerned, in the top applications that customers and end users typically use. So with gaming the extra challenge we have is performance.

...There’s a big difference between a game that runs at 50fps (frames per second) and a game that runs at 10fps. Without a special focus to ensure that our driver is working well, and also that the application using it, is using it within the specs of the API, which is OpenGL, you’re not going to get good graphics. That’s the challenge we’ve had.

This is why we’ve been working with Valve; it’s been roughly a year and half now. We found out that they were interested in bringing their games to Linux, and they live about three hours’ drive away from where we are, we’re in Portland, Oregon. They’re in the suburbs of Seattle, Washington. So basically we got in touch with them, drove up there and met their developers, and we’ve been working with them ever since. The cooperation has let us to find out what the bottlenecks are before the games get released.

They’re very pleased to have an open source driver to work with, because an open source driver, by its definition, you can look in the code if you want to know what’s going on - with a closed source driver you just can’t do that. That just makes collaboration easier, and we’ve been able to get great cooperation from the Valve engineers.

We basically start out with their games in a state of not being playable at times and by the time they put it out on Steam, so you can get it and play it, they were very playable. That’s the extra work involved. In fact, I can tell you that one of things we’ve been missing that we’ve been looking for for a long time is where do we get workloads? Where do we get applications that really stress the stack? That we can find our bottlenecks in? These games are perfect for that. They are perfect for finding novel ways in which the stack gets stressed. We have a large test suite that runs that’s also open source, it’s called Piglit . This is a set of tests that the industry uses and, again, we contribute to.

We have a vast set of tests we run and we have many applications we run, but nothing has been, up until the Valve games came along. nothing has existed at the class of stress and demand that was put on the graphics system likes these sophisticated games. So it’s really exciting.

LXF: Interesting that it’s load testing...

KN: Absolutely, one of things that we strive for is the focus on the user experience … At the end of the day, if the end user using the stack is not happy with the experience they are getting no high benchmark is going to make them happy. They’re going to walk away and say, OK, I’m not going to use this architecture anymore because it just doesn’t work.

LXF: Yes, the end user doesn’t care to a large extent how it works, they just want a good experience.

LXF:What were the bottlenecks you encountered with the Valve games?

KN: We didn’t find that any general area was lagging. One thing we learned from these games, and it’s not that different in Windows, the devil is in the details.

Basically, what we learned was that ‘this specific game uses this API in this sort of a manner’, maybe it expects really big buffers [for instance] , right, maybe it makes a specific call in a second of gameplay 10,000 times, when we really only expected it to be called 10 times. You see what I’m saying, it’s not one area we found it this is really an efficient way to solve it. It was the little details.

What makes optimisation for these games tough and time-consuming is the fact that every game is different. It’s not that you can do it for one game and every game necessarily benefits. If you have major problems in your stack with performance then that may be the case, but we really never found that. It was basically that we really didn’t think this is a call that they would make a lot. We knew this specific call was slow but we really didn’t think about optimising it as we didn’t think people would use it very much, in terms of how often they would use it. But then for whatever reason they did.

You know, game development is a lot like art. There’s a lot of personal opinion involved. One person doing it a certain way can have a very good argument and another person would argue, no no no, you shouldn’t use this call you should use this other call, because that’s a much better way of doing it, right. So what we try not to do is go tell them how to write their code. We try to figure out how they’ve gotten to where they are.

There are cases where we’ve argued if you use this other method you’ll get better performance on Intel silicon, and there are times where they’ve said, OK, that makes sense, we’ll go do that. We’ve not found any major flaws in the games or big flaws in our driver. It’s been a lot of little things but they add up to a lot. You could find one of those calls that instead of being called 10 times a second is being called 10,000 times - you fix that and all of a sudden your frame rate doubles. And we’ve seen that a lot.

LXF: So you does that mean you should be taking some of the credit for the Left 4 Dead 2 results?

KN: Well, *laughs* I don’t want to say that, because I don’t want people to think that we’re not... I think the credit goes to the spirit of cooperation between the Valve engineers and our guys.

LXF: That’s very generous of you.

KN: *laughs* You could argue that if the credit goes to us then our code was no good to begin with. What’s really encouraging for us is that they were really open to talk to us and responded to our emails, and so we were, of course, eager to work with them. We found a really good working relationship, with these folks, who really just wanted to make sure their games worked well.

We worked towards a common goal, we don’t keep score of whose fault was it. It doesn’t matter, at the end of the day we’re trying to get a good user experience. A lot of those optimisations are general things that other games will be helped with.

LXF: Is OpenGL critical to the whole success of getting games to run on Linux?

KN: From my viewpoint, there’s absolutely nothing but OpenGL. In the graphics world we have DirectX, you have OpenGL and you have a bunch of other APIs that are very narrow in what they are used for. OpenGL – like any well defined standard API – allows people not to worry about the nitty-gritty details of what GPU they’re running on.

It’s served it’s purpose really well, especially, I think, the later versions of OpenGL are very good. People like Valve who have started out in the DirectX world are finding that OpenGL is actually very useful and viable for gaming. I think that’s one of the things we’ve shown – OpenGL is viable for gaming no matter what platform you’re on. We happen to be on Linux, but there are people who use it on Windows as well. So basically, as far as we’re concerned it’s nothing but OpenGL.

LXF: OpenGL is a way to start the ball rolling, but is it actually foundational to gaming on Linux?

KN: When looking at OpenGL can be easy to assume that because it sits higher in the stack that it’s not as efficient as other alternatives. In fact, Nvidia presentation noted that it was still better than X. Without a doubt, it’s by no means a stopgap. Once you get out of the Windows world, OpenGL is the game.

You should follow us on Identi.ca or Twitter


Your comments

Post new comment

CAPTCHA
We can't accept links (unless you obfuscate them). You also need to negotiate the following CAPTCHA...

Username:   Password:
Create Account | About TuxRadar