Blender and gallium on haiku

Maybe there is a work-around? Like with some of the OpenGL demos?

That llvmpipe with gallium sounds very interesting. Mesa is usually 1 to 5 fps for games. If llvmpipe supported multicore then it would be very cool to have and use for now. Until someday when Haiku can get real hardware 3D drivers.

up

Information below relates to using llvmpipe (for OpenGL):

The Gallium3D LLVMpipe driver does not touch the GPU, so it can be run with any graphics card. However, for efficient performance, you will want to be running a 64-bit operating system and a CPU that supports SSE2.0 or better. LLVM can take advantage of SSE3 and SSE4 extensions too, which will result in even greater performance. To no surprise, the better the CPU you have, the better LLVMpipe will perform. The more cores that the CPU has, the better the performance will be too, as the rasterizer supports threading and tiling. If you are running a high-end Intel Core 2 Duo/Quad, an Intel Core i3/i5/i7, Intel Xeon, AMD Athlon II X4, AMD Phenom II, or AMD Opteron your CPU should be adequate.

llvmpipe with Core i7 test:
http://www.phoronix.com/scan.php?page=article&item=gallium3d_llvmpipe&num=3

Mesa R300 (hardware OpenGL driver - uses GPU)
Gallium 3D R300 (hardware OpenGL driver - uses GPU)
llvmpipe (software OpenGL - uses lots of CPU for better performance)

*Mesa Software OpenGL not included in benchmark:
We did not compare the performance to the traditional software Mesa rasterizer in this benchmarking since it is incapable of running any of our OpenGL benchmarks beyond a couple frames per second.

My conclusion:
llvmpipe places the OpenGL burden on the CPU (higher usage). It is way better than Mesa software OpenGL but not the same as hardware OpenGL. Still, good way to start until 3D drivers are created for Haiku.

Gallium 3D rules! For 10% of CPU it really pushed up the fps in OpenArena test. In almost all test resolutions, double or more fps than Mesa R300.

Huum.. I thought that you had one copy of that lib

Yes.. I saw that commits..

But to build, you have to do download of the entire branch.....

...and what about OpenCL ?

Check out this interesting article (and comments too) about it.

up

Yeah, thanks! I got the same results here.

Including the black screen of death (SDL+OpenGL)

~/Desktop/lesson05> lesson05
CALLED: SoftPipeRenderer::SoftPipeRenderer(BGLView*, ulong, BGLDispatcher*)
hsp_init time: 0.000000.
ColorSpace:     B_RGB32
context:        1
hsp_create_layer_context time: 0.000000.
BRect(l:0.0, t:0.0, r:1023.0, b:767.0)
Kill Thread

What leads me to think that is a bad BWindow implementation on SDL video driver

However, TinyGL is not a worst thing (there's a BGLView implementation already done)

perhaps that could bring more faster results

Yeah.. I already did it

http://ports.haiku-files.org/ticket/268 (please see the screenshots)
and
http://dev.haiku-os.org/ticket/3191

axeld said that could be a SDL port problem.. but I can't remmember if in BeOS was the same thing... (my hardware is not suitable)

the Kill Thread is me :D

About TinyGL, the morphOS website displays Neverball and more games that are impossible bring for Haiku now.. (Neverball builds, but the black screen appears)

let sit and wait :(

Another thing: In early versions, Quake III arena was playable, but not now
See:
http://gallery.sikosis.com/main.php?g2_itemId=43
and
http://dev.haiku-os.org/ticket/3163

Could you test?

I built Neverball on Zeta or BeOS and it worked. Pretty sure it played real slow (2 to 3 fps) but was working. That's why I wanted you to test with BeOS to double check.

I tested out BeOS Quake 3 on gcc2 Haiku and it works but:
1) the game wants to connect to the internet and is failing with the same message showing over and over
2) I only get 2 to 5 fps. Very unplayable; too slow.

Quake 3 does not work with gcc4 Haiku! Complains about missing Mesa (OpenGL) renderer. Requires gcc2 renderer.

In the screenshot sikosis was getting 21 fps in Quake3. Wish I knew his hardware setup and settings.

I also downloaded Quake 3 source, made quick fix and compiled it for gcc2 Haiku. Quake3 (Haiku) starts full screen. Has distorted sound and still trying to connect to the internet. Same thing happens with BeOS version. I haven't spent any time looking into what is going on.

This was quick so I have to spend more time to test it out if I think it is worth it.

Edit:
Post above slightly updated.

Quake3 actually does have sound. BeOS & Haiku versions have distorted audio but BeOS one is worse with a buzz to it (annoying).

I enabled fastest settings in graphics and was able to get 9 to 14 fps for game play. Still too slow but better than 2 to 5 I had before.

Anywhere that offers binaries of the Quake 3 engine for BeOS should be able to give you the source code because it is licensed under the GNU GPL which requires this.

This is a big problem for Haiku. No hardware 3D. But one that needn't be insurmountable. The answer to this problem lies in completely circumventing the problem itself. In other words... stop trying to write drivers to access hardware accelerated 3D in the video cards we have in our systems that the video card companies aren't going to ever give us the specs to...

I'm sure you're scratching your head, going, "What the... huh? How can that possibly solve our problem?"

The answer is simple... if you can't figure out how to write hardware accelerated 3D drivers for video cards that other's make... MAKE YOUR OWN VIDEO CARD!

Now, what I propose may seem insane, but it really isn't. It's simply creating a work-around solution that will, in all likelihood, provide what we want (playable 3D gaming), in a way that let's us define exactly what the card can do and how fast it can do it.

Now, before you start telling me that designing a video card takes millions of dollars and fabs to create the chips and all that stuff, let me tell you that the hardware portion of the answer is likely right where you're reading this and the initial code to make it function is only a download away.

If I have your interest piqued, do reply and/or Email me. You're not gonna believe the answer... it's a very primitive solution, conceptually, but (in theory) it should work faster than the current software solution we're having to use presently.

I just need someone (or a couple people) willing and able to give it a try...

I think to combat this / get one up on linux we need to focus ALL of our effort in terms of the graphics server on making the generic graphics driver the best it can be. Add a softpipe to the system, get OpenGL/tinyGL up and running. the key lies in a universal solution for graphics. in its current state the generic VESA driver is massively powerful in haiku why not build on that.

In what?

The TinyGL in MorphOS definitely seems better than the original. But how is it better than OpenGL? How would it work better as a general solution? If anyone who knows more about the TinyGL used in MorphOS could share the knowledge, it'd be appreciated.

Only fix compilation issues...

and bring-to-update the current functions

because TinyGL already have an BGLView implementation :D

-

but Again, it's better fix SDL+OpenGL issues... I'm not a coder
but I know that with a little effort, this could be done

I did not know that even AROS gallium port is surpassing Haiku...

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

http://ports.haiku-files.org/ticket/371

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
http://www.youtube.com/watch?v=YozKvRwlzV4

Yes, great seeing Aros with hardware accelerated 3d. This bodes well for a 3d accelerated Haiku in the (hopefully) near future aswell.

Mesa port is done :D

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

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.