Haiku OpenGL Kit
Maxim: Tell us about yourself ?
Artur: I'm a 27 years old, working as a game developer in GameLion Studios, long time BeOS user and almost 2-3 years Haiku developer :)
Maxim: What is current OpenGL state in Haiku ?
Artur: OpenGL state in Haiku OpenGL Kit is so simple that even Windows GL API beat us in that manner it was designed 10-12 years ago, without current GPU's multi-threading rendering etc. My plan if nobody beats me is to implement TTM memory menager in kernel, then port DRM on kernel side, provide a simple test cases which shows that it works and then rewrite from scratch Haiku OpenGL kit but as a base use Apple's OpenGL framework. It's mature, well designed and great :)
For example, current implementation of OpenGL Kit doesn't allow you to have more contexts, and for example, current engines uses multiple threads in their engines and in current design you can't divide application to use multiple context, for example one to render, one to process, one to physics etc.
Maxim: Tell us about Gallium3D in Haiku ?
Artur: softpipe in Ggallium3D takes a role of a reference driver. If you want to write driver for gallium you can take a look at softpipe. It's a pure software implementation, designed without performance in mind but as a reference. It doesn't touch GPU, and works only on cpu. There is a fork of softpipe, called llvmpipe, which uses LLVM to produce highly optimized multithreaded code, which on linux (pure software without GPU) can play Open Arena game at 32 fps on 800x600. It's pretty amazing, pure mesa have performance at 3-5 fps.
First I need to implement TTM and DRM, then I could focus on bringing OpenGL kit up to date. TTM is an API for managing memory on GPU's, DRM is a direct rendering manager, kernel side implementation of how to talk to graphics card, popular on Linux. I'm using code from FreeBSD and some parts from Linux. But lately I'm trying to get more from Linux as FreeBSD port of Mesa and GL stack at all isn't complete as much as Linux ones. But there are limits, for example linux GL stack on kernel side (DRM) is GPL'ed and on Haiku we are focusing on having much not GPL code as we can.
Maxim: You mentioned LLVM. Will you use it ?
Artur: LLVM is a Low Level Virtual Machine, it's another topic, but it allows to generate higly optimized code for cpu. Nope, i'm not planning to use it.
Maxim: What GPU will be accelerated first in plans ?
Artur: What GPU ? Which I have, nVidia :D If we're going to provide an OpenGL Kit, it should be a fully accelerated by GPU, not a software implementation. But really, my plans are first to use VMware vGPU driver and if it works, then try with real hardware. VMware vGPU is a virtual GPU architecture, which translates guests OpenGL calls into native calls from hosts, so you can get native performance from your nvidia card running on linux on your Haiku runned from VMware.
Maxim: Will Haiku support Linux DRM drivers ?
Artur: If we don't want to reinvent the wheel on haiku, we should implement DRM on our side and use stable, bug-free linux drivers. TTM and DRM are to be implemented as kernel mode code. And Haiku DRM will provide DRM API that is compatible on source level with Linux DRM drivers, similar as it was done by our colleages with FreeBSD network compatibility layer which we have for network drivers.