OSNews

You can find out a lot of info on Rudolf's homepage.
He is the one who has done all of this work.

http://web.inter.nl.net/users/be-hold/

it is amazing how much he has been able to accomplish

No that's not a typo.

Rudolfs BeOS-nvidia work is based on UtahGLX, the first attempt with 3d acc for X11. UtahGLX used Mesa 3 for it's acceleration. Rudolf has stated that he will move to Mesa 6 soon. A framework for loading 3d drivers dynamically (BeOS style) will also be implemented and put into Mesa and Haiku CVS.

All current development is happening on DRM/DRI/mesa6.

Whenever Xegl is ready, it should be simpler to port to other OSes than the current DRI/x pair. Xegl isolates most of the OS specific code into the fbdev/DRM device drivers.

But isn't the point of Ruldolf's driver project to make an OPEN-SOURCE 3d driver? -- from what I understand the DRM/DRI device drivers rely on a binary driver compiled and distributed by the vendor - which locks it into a specific model and architecture.

Rudolf's driver is independent of any code provided by nVidia, and he has done much work to reverse-engineer the video cards for his own 2d/3d acceleration drivers.

DRM/DRI isn't dependent on binary drivers. Indeed, NVIDIA's binary drivers don't even use the DRI/DRM. On the other hand, open source DRI drivers exist for a number of chipsets, including Radeons.

>DRM/DRI isn't dependent on binary drivers. Indeed, NVIDIA's binary drivers don't even use the DRI/DRM.
>On the other hand, open source DRI drivers exist for a number of chipsets, including Radeons.

They do? With Hardware accelerated 3D graphics? I have never heard of any. Could you supply a URL to one that is not the BeOS/RISC one under development please?

Hey Lumbergh,

No, the original code comes from the UtahGLX project.
I believe Nvidia themselves were involved in it.
(John Carmack did some work on it too!)

One must note this though:
-The nvidia UtahGLX driver was in an early state of life.
Much was still not implemented and maybe even some stuff can't be figured out from this driver.

-It only supports the first generation of Nvidia HW.
TNT1 to Geforce 2 (and GF4MX but that's essentially GF2 with faster clock.)

Ok, that makes sense. In fact, I now remember Carmack talking in his .plan about his UtahGLX work. I guess this would have been right after the release of quake3....when he tends to get into alternative projects.

Porting OpenTracker is far more complicated, actually, than porting a display driver. Why is that?
There are a few reasons, actually. For one thing, BeOS has a threading/application design/implementation model that, AFAIK, has only Syllable and its parent with a matching or almost identical model. If you take out the B out of the names of the classes OpenTracker uses from the Interface Kit and other things, it would likely largely compile.

However, above and beyond that, is that (though this isn't as big of an item as it could be) it uses some undocumented BeOS API's that are not officially supported, and may change. At this point, it's likely that perhaps only yellowTab would change them, if you consider Zeta the heir apparent to BeOS 5.03. Then again, Zeta is likely in the future to replace more portions of its codebase and libraries with those developed for Haiku.

And the last meaningful thing: OpenTracker is a snarled piece of code for anything that was part of OpenTracker when it was released. Anything that started out in OpenTracker itself (that is, the vector icons did NOT start out in OpenTracker, and use a pre-existing library) is cyclically dependent on itself, to where less than 1% of the original OpenTracker code can be reused without a lot of hacking at the source. Supposedly, Tracker was published as OSS under the thoughts and hopes the code would be reused in other BeOS software. The reality, because of the structure, is that the only reuse of the code has been in branches of a full OpenTracker itself, because almost all of the code is completely spaghettified, and it isn't worth the bother to try to reuse it.

OpenTracker should be completely replaced with something that does at least as much as OpenTracker currently does, but written with a fresh design with no code from the old Tracker, with using notes about the file handling in terms of copying files with all the attributes, etc. that make OpenTracker distinct from most other file managers. This will, of course, likely cause some breakage of applications that use BFilePanel, the file selection dialog that's used as part of the standard BeOS API: this is exported from the OpenTracker executable, such that an application that uses a it effectively brings in almost all of the code of OpenTracker into its address space, just to allow a common file dialog for opening and saving files. Perhaps this is something that will happen with Haiku R2, which may very likely have major API changes anyway, besides likely using a more recent version of gcc where the C++ ABI is different from that of gcc 2.9x.

>Porting OpenTracker is far more complicated, actually, than porting a display driver.

Thanks for the informative reply. I guess I have been fooled by the number of diffirent OpenTrackers into thinking it's code must be easy to understand/change. I have only looked at the code once, and then I was over looking for the find function to see if I could add features to the queries. I guess that is your point, even with a maze of code it is possible to add functions, but that does not mean understand the total code and porting it is easy.

And yes, I too am looking forward to the day that Haiku is compiled with a more up-to-date compiler, BeOS is pretty fast for the things I do now, an update compiler should make it sing.

Not that Haiku is doing it all, but the only open-source Hardware accelerated 3D graphics code I have heard about has been Haiku's.

You've never heard about the Direct Rendering Infrastructure? http://dri.freedesktop.org/wiki/

Adam

Nope, until this thread earlier pointed it out to me I had not. I am just now trying to plow my way thru it right.

PS. Thank you everyone for the non-flaming replies - I learnt something new, which is always good