I'm into something about writing a "Mock GPU driver" for *nix based systems. What I mean is that, simply I want to write a driver (Behind X-server obviously) to answer X's API calls with some debugging messages.

In other words I want to fool *nix system about having an actual GPU. So I can make a test-bed for GUI-accelerated packages in console based systems.

Right now, if I execute a GUI-accelerated package in *nix console based systems; it'll simply dies due to lack of a real GPU (or a GPU driver better I'd say).

So I want to know:

  • Is it even possible? (Writing a GPU driver to fool *nix about having an actual GPU)
  • What resources do you recommend before getting my hands dirty in code?
  • Is there any similar projects around the net?

PS: I'm an experienced ANSI-C programmer but I don't have any clue in real Kernel/Driver development under *nix (read some tutorials about USB driver development though), so any resources about these areas will be really appreciated as well. Thanks in advance.

  • 3
    Are you sure you need to create one from scratch? Does the Virtual X server not work for what you need? Check it out, it's called Xvfb – Tim Jul 26 '12 at 17:55
  • @Tim Xvfb is for debugging purposes and built inside X-server, for X-server, correct me if I'm wrong. I need something universal. a real Mock driver. just like Mock drivers for networking. – sepehrl Jul 27 '12 at 6:29

Given your requirements, it seems likely to me that you may not need to write your own driver. You may be able to use llvmpipe, which I believe conforms to your requirements. In particular, it is a "real driver" by some meanings of the word, and it does not require that X11 be running.

llvmpipe creates what might be called a virtual GPU that interprets OpenGL shaders by converting them on-the-fly to machine language for your CPU and runs it. It uses parts of the LLVM infrastructure to accomplish this.

However, it might not meet your needs, since what is actually going on is that llvmpipe is linked against by the binaries calling it. In other words, this is not a real, live, running-in-the-kernel driver. Instead, it creates an alternative libGL.so which interprets your OpenGL shaders.

If you're not able to compile your 3D graphics accelerated program from source, you probably cannot use llvmpipe to good effect. (But you want this to help with debugging your own programs, so that shouldn't be a problem.)

You might want to provide more information about what you need, in your question. In particular: Why do you need to debug your code from the driver side? Why can't you put the necessary debugging code in your program itself (or in your programs themselves)? Both X libraries and OpenGL libraries provide information about what went wrong, when a call fails. Why can't you use that information--plus kernel messages--in your program to facilitate debugging? And why would you expect that debugging information you get on the driver side, with a virtual driver implemented in the kernel, would correspond to what actually happens on real computers? More importantly, why would you assume that if your program produces low-level problems, those problems would be the same for different GPU's and drivers when it's run in the real world? You may have perfectly good answers to these questions (plus maybe I'm missing something), but I think it would be easier to answer your question if you explained this.

(By the way, one interesting application of llvmpipe is to enable graphical user interfaces to be written only in 3D-accelerated versions, but still run on computers without 3D acceleration. Theoretically this should facilitate running GNOME Shell without 3D acceleration, though some development work might be necessary to make it actually work; I think GNOME Shell makes some assumptions relating to compositing that might not be automatically fulfilled. Also, there are apparently some performance problems. A real-world instance of this that actually works is Unity, which in Ubuntu 12.10 will come in just one version, and be able to run on top of llvmpipe instead of there being a separate "Unity 2D" implementation.)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.