I did not know that even AROS gallium port is surpassing Haiku…
Right now it seems like people want to do everything at the same time when it comes to video drivers. One is trying to make a compatibility layer for binary blobs in Linux, one (or more?) is trying to get Gallium3D over to Haiku, and now it seems there might be people trying with TinyGL as well. I think we need some direction. What are we trying to accomplish and how do we go about it as good as possible?
I personally think Gallium3D is the way to go. It already has drivers for modern ATI and nVidia cards, and it seems to be a good framework in the way that drivers only expose hardware functions to Gallium3D and then API’s like OpenGL are supported since the support is already in Gallium3D itself. In theory, we could even use Direct3D in Haiku, if only Gallium3D supports it. 
If anyone knows anything about the TinyGL used in MorphOS that you would like to share though, please do so. It might be awesome but I know almost nothing about it.
I don’t know too much about MorphOS
is someone working on TinyGL for Haiku?
I once give a try… without success…
Firstly create a shared lib is needed
after, update it with Mesa recent changes
This TinyGL is a completely different beast. From MorphOS’s website:
TinyGL was originally created by Fabrice Bellard as a subset of OpenGL® for embedded systems and games. It was designed with no hardware acceleration in mind at this time. Only the main OpenGL calls were implemented.
The MorphOS version of TinyGL is only loosely based on the original implementation. It was rewritten to take full advantage of 3D hardware acceleration. Furthermore, it contains several carefully chosen MESA features. TinyGL on MorphOS provides a much richer feature set and surpasses the original’s speed at the same time.
-
Big set of implemented functions with high degree of OpenGL® compliance
-
Easy to use system layer API
-
Highly configurable
-
Fast and robust pipeline which was tightly optimized for lots of common cases
-
Non-blocking rendering (no context locking required)
-
Multitexturing, mipmapping and palette texture handling
-
Cube mapping
-
Stencil buffer
-
Vertex arrays
-
Display lists
-
User clipping planes
-
Selection buffer
-
Evaluators
-
GLUT implementation
-
All primitives are supported, including lines and points (smooth or not) of variable sizes.
The TinyGL developer kit is available for download on the MDC (MorphOS Developer Connection) website.
I can’t make out a lot, but I do understand that this seems a lot better than the original, feature-wise. What the point of supporting any of these two would be if we could get real OpenGL support, however, I don’t know.
They do have hardware acceleration based on gallium3d + nouveau driver
http://web.aros3d.org/index.php/projects
here is the bounty that is completed
http://amigaworld.net/modules/news/article.php?storyid=5547
and here is one of the demos running on nouveau : Lugaru
1 Like
Looks awesome. It should be ported to Haiku as well.
Yes, great seeing Aros with hardware accelerated 3d. This bodes well for a 3d accelerated Haiku in the (hopefully) near future aswell.
awwwww i want lugaru and blender in haiku…ArOs dont like to me 
… haiku and 3d!
haiku are the best…but we really need 3d
how are the state on the port of Mesa? is done?
softpipe driver … Wip?
Gallium3D nouveau driver NOP?? WIP??
AGP support ???
3D accelerated app_server???
what are the status on this?
Mesa port is done 
Are missing some recent game functions…
Softpipe renderer is working, but have 1/3 of Mesa renderer speed and some visual issues. To test, please see the download link of my previous comment above.
Gallium3D driver is not ready yet
AGP is ok since 2006
3D app_server is for R2 only
Then i can compile the last version of mesa in haiku withaout any problem?.. thats is great! then the next step are? optimization of Mesa soft pipe renderer? generate the soft pipe gallium3d? make Gallium drivers?
mmm thats parcial port of gallium can help for do this, no? are more hard than i think?
i am really learning so much things with this thread.
For me the 3d drivers on Haiku could be the more big news later of Alpha1 release.
There is no Haiku port of Mesa to compile.
Instead, Haiku comes with an OpenGL kit (libGL.so, libglut.so symlink, public GL headers, add-ons API) which use Mesa 7.x (can’t remember the extact version):
-
libGL.so contains and rely on Mesa GLAPI dispatching code
-
libGL.so contains and rely on Mesa GLU implementation (which is SGI’s one in fact)
-
libGL.so contains and rely on Mesa GLUT implementation (which lacks recent Game extensions as mentioned above)
-
libGL.so contains GLRenderer, GLRendererRoster, GLAPIDispatcher and GLView base classes.
The later delegates all the ugly stuffs to a GLRenderer object, which is bound to GLAPIDispatcher (a wrapper object around the mentioned Mesa GLAPI) at GLView init. The GLRendererRoster object manage renderer add-on(s), providing one at GLView’s demand. -
Mesa Software Renderer add-on contains and rely the Mesa software rasterizer, wrapped into a GLRenderer object.
-
The softpipe renderer add-on from the Galluim3D branch contains and rely on Gallium3D softpipe renderer, wrapped into a GLRenderer object.
Yes, I know, it’s overly complex. And consider that it’s way more simpler in Haiku implementation than on Linux, where DRM, DRI, DRI2 and X drivers are involved too. For HW 3D support, it will complexify a bit more, for sure.
Optimizing the Mesa software renderer will be hard, as it’s already well done since years by Mesa developers. What’s lacking is using the threading power, but except the multi-bands branch (which split the rendering in several bands and threads) of latest Mesa versions (not sure it has been merged into trunk yet, though), there is not much to expect here.
Switching to Gallium API (which needs Mesa too) in order to get as free the LLVM-optimized-and-multithreaded soft pipe (dubbed llvmpipe) will give us a far quicker software renderer than currently. But it will be long away still from what kind of performance people and 3D apps are asking today: hardware accelerated 3D. Software renderers are poorman fallback solutions now, pratically useless.
The port of Gallium to Haiku is the way to go no doubt, and is already in progress. It will gives us really useable 3D support. What’s lacking is free time and, most probably, a second worker to help Arthur carrying this heavy task. Maybe a GCoS next year, or some HCD (Haiku Coding Drive)…
Switching app_server to use OpenGL is definitively not yet scheduled, and depends on HW 3D support availability. There is no point to start it without.
I agree, apart from a reference standpoint (and perhaps very simple desktop compositing) I see little use of software rendering since it will always (with or without llvm recompiling of gpu shaders) be too slow in practice. A Haiku code drive for Gallium would probably yield alot of interest (worked for Aros) but obviously someone must be able/have time to actually pick up the gauntlet.
PLIB has been ported!
http://haikuware.com/directory/view-details/development/class-libraries/plib-libraries-examples
Tunestone, I done the VegaStrike port using GLUT…
If I post here, you could test in the latest build?
Seems that my pc is not recognizing the resolution modes …
the binaries is about 27MB
but you should download game data (430 mb)
Michael, I should be able to spend a little time to check it out.
How about testing BilliardGL instead? Do you have a build of that?
phoudin said BilliardGL works for him:
http://dev.haiku-os.org/ticket/6266#comment:13
but not for you:
http://dev.haiku-os.org/ticket/6266#comment:15
PS Better to start new thread on GLUT because this does not really relate to galluim or Blender
amd developerzone has tons of hardware info.
How is going all? 
blender 2.11, when can be Blender 2.49? or maybe 2.5!!
http://cgit.freedesktop.org/mesa/mesa/tree/progs?h=gallium-0.2 Here i saw a beos directory and that make me think in if this can work on haiku and i wanna know wich is the state of that port.
How important is (open)GL to 3D software?
Looking at the AGC demos I have to wonder if a simplified GL or other API could be used write usable 3D programs? Looking at OpenGL it seems to have a ton of features that most people don’t need.
Well, obviously what you need is very subjective. However if Haiku is ever going to be able to use programs like Blender, a subset of OpenGL won’t do. OpenGL is the defacto standard when it comes to 3D modeling/rendering software, it’s only in the games sector that it’s superceeded by Direct3d which likely has very much to do with windows being the dominate pc games platform.
re Blender and OpenGL. From the Blender FAQ it says you can get up to 4X speedup when using Blender with a supported video card and OpenGL. However, you could also get a 4X speedup running Blender with a quad processer. So the question is can you run Blender without OpenGL??