Haikuware News & Blogs
Spread your news, software reviews, comments, & ideas about Haiku!
I've made a lot of progress over the last few weeks, here is the latest statuses layed over the bullet points posted here.
Update Mesa3D / aka Gallium3D to current and work on getting changes accepted in Mesa upstream
This is 99% done. The latest Mesa upstream now compiles under Haiku gcc4 with a patched makefile. I am working on getting a scons build script working. scons is the build system Mesa seems to be moving to, and they voiced in the ML that would perfer to not accept new Makefiles. There is a scons port on haikuports, so this shouldn't be a big deal.
Get stock Mesa3D into the build system somehow so it is pulled / extracted prior to compiling opengl kit
I am glad to confirm this is 100% done. (yay!) Right now the Haiku build system pulls external pacakges for Mesa, and compiles using them.
- Haiku gcc2
The Haiku GCC2 images pull a compiled Mesa 7.8.2 Optional Package. I went with 7.8.2 because this is the *very* last upstream version of Mesa I could get to compile without Haiku keeping a complete fork. After 7.8.2, glsl was introduced which is C++ and is *not* gcc2 friendly. - Haiku gcc4
The Haiku GCC4 images pull a compiled Mesa 8.0 Optional Package. Upstream Mesa has accepted several Haiku patches and I am happy to report it looks like Mesa 8.0 should build under Haiku with very little assistance.
Ensure new Mesa3D based opengl kit works and software rendering occurs (this gets us back to square one with the new Mesa version compiled from upstream.)
This is mostly complete. I am not going to accept the first portion of the bounty however until things are 100% what they were... there are a few quirks in GL rendering I want to address before calling this one done...
- GLTeapot 's handle and spout have some odd depth issues... unsure if this is due to GLTeapot being old code, or if it is due to the Mesa software rendering driver.
- Haiku3d has some instances of leaving a trail. (see http://twitpic.com/85vthm) I do have reports it is working 100% for other people however on 32bpp.. so I think it's a color space issue.
- Right now we only do single buffer rendering, double buffer causes crashing of GL apps.
- The Teapot flashes red when you mouse over it.. this may be related to the single buffering, I am not sure however.
Get at least one Gallium3D Hardware driver working / rendering.
Not started yet, the door is now open as we have stock Mesa running. Right now we are using what Mesa calls their "Software rasterization" engine. I am planning on checking out what others have done in the past for Gallium3D software pipe rendering... it would be a good spot to start.
Get two Gallium3D Hardware drivers working / rendering.
Lets get one working first :)
Thats all for now, thanks for the support everyone one who has helped thus far... and a big thank you to the Mesa project folks for putting up with me and my Haiku patches :D
-- Alexander von Gluck

Comments
Thanks Alex. This is excellent news. Can't wait to test some games.
When the mouse is over, the full flat red teapot means that the stencil buffer content is somehow accessed as the color buffer.
As the depth buffer seems wrong too, I suspect that the renderer buffers are not set as they should be yet.
Or buffer format is not what it should be.
Otherwise, it's looking promising.
my teapot is still spinning at 300fps as before on my notebook and a bit slower on my P4 at 130 was at 170 before
thx great to see so fast resutlts
Go Alex!!
RSS feed for comments to this post