Thursday, 13 May 2010 10:41
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.
Top Downloads in 30 Days
Free Heroes of Might and Magic II
ATI Rage 128 Pro Ultra Driver
SDLGameLibraries GCC4
FirefoxSearch Files
Newest Files
Sep 2 |
Chat |
| Sep 2 |
BeScreenCapture for Haiku |
| Sep 1 |
FreeGrep |
| Aug 31 |
Online Selling Assistant |
| Aug 30 |
Caya+MSN rev255 |
Comments
I left a comment there
waiting for a reply from Artur
http://community.livejournal.com/kernel_being/1520.html
So the comments are really was lost. Sorry for that. My bad. But in-general questions are not addressed to me, but to Artur.
As I see you guys are not satisfied with Artur's work or something ? :)
"I agree with you: Currently, haiku opengl implementation is far behind Win95. I remember when I played ActuaSoccer in Win95 ;)
Actually, the only thing that OpenGL kit does is rendering (more or less well) Teapod demo.
But I want to know when your code goes to SVN repository.. a timeline is a good idea. OpenGL kit is an open area since Haiku started. I remember when Michael Phipps told about it in the first series os OpenBeOS newsletters (Yes, I have it still).
Because:
1 - There's nothing more to do in Haiku for (R1Alpha2) now in games area, which can attract more users, more ported libs, and bring more funcionality to the system.
Beyond that, all possible 2D games was ported already. Then:
2 - There are a thousand 3D games that builds fine in Haiku, but not run because OpenGL Kit is incapable to show any 3D activity. Openarena like you said, is a good example. DreamChess, OpenCity, Freedroid too. And much more that I tested by myself, that could ship today for Haiku with more effort in OpenGL. Comes in my mind Gens emulator:
http://img697.imageshack.us/img697/9506/screenshot1qx.png
3 - SDL, that uses OpenGL as backend, don't show any 3D images too.
http://ports.haiku-files.org/attachment/ticket/268/screenshot3.png
This is black screen that appear in all 3D games that uses SDL
4 - Apple OpenGL framework approach is a nice thing. If you succeed, I can see TORCS and Flightgear in a couple of weeks running on Haiku, which depends of OpenSceneGraph library and PLIB.
Please continue with your progress, is very important for us.
Best wishes,
Michael"
All is correct
Sad that lost Michael's comments :(
Future is very promising :)
Ye! Blender would be very cool!!!
virtual world game, or is the licence fort it not open?
It looks like the Second Life viewer software could be compatible with Haiku:
http://develop.secondlife.com/develop-on-sl-platform/viewer-licensing/
and the FLOSS (free/libre open source software) allowing MIT compatibility:
http://develop.secondlife.com/develop-on-sl-platform/viewer-licensing/floss/
I don't know how difficult it would be porting the source. I am not a developer. but I read that cmake is used to make it easier, at least for linux distros.
Porting something like this could give more incentive for OpenGl.
Although it might seem premature. It depends how easy it would be.
We have to wait a better opengl implementation.
Isn't that because SDL and all the other OpenGL apps were badly ported, instead of a broken OpenGL implementation?
Could be both! But please do a simple test here
ports.haiku-files.org/ticket/268
RSS feed for comments to this post