Hardware accelerated 3D graphics on RISC OS took a step closer to reality, thanks to Simon Wilson. He claims to have ported Mesa 3.2, a 3D graphics library that sports an OpenGL software interface. More importantly, he says he has also ported an Nvidia graphics accelerator from BeOS to harness the GeForce2 video card in the Iyonix to plot graphics fast in hardware.
The post talked about porting over a driver from BeOS. But I have a more general question of how much register level specs have been gleaned over the years. I guess some stuff has been reverse-engineered over the years (to my knowledge Nvidia has never released source for any of their drivers) and various other bits of info have slipped out.
So this really affects all OSes which don’t have official Nvidia support. Is it more of a question of there being x percentage of functionality of the cards that have been acquired over the years?
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
Hope that is a typo, Mesa 3.2 was released on April 24, 2000. Current version is 6.2.1
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, some people are happy to have Quake running. Baby steps you know
I suspect RiscOS has had 3D acceleration for years.
RISC OS however is just getting it (and I sold both my boxes yesterday!)
ATI used to give out their register-level specifications and had open source drivers for a while, and 3dfx gave out their register-level specs, but to my knowledge Nvidia never has.
Are these people reverse-engineering Nvidia drivers or how are they getting the info?
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.
off topic, but does anyone know where i can download / tryout this virtual-rpc adjust / se emulator ???
riscos emulator for thoose that didnt know.
I noticed lately that it seem a number of alt.OSs seem to depend of on Hakui’s opensource to get things started.
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. Everyone else seems to depend on wrappers around Windows drivers or used closed sourced drivers for the card.
Same with file systems. While there are some interesting open source journaled filesystems out there the only ones that offer both journaling, advance file attributes and live queries at the same time seem to be based on OpenBFS.
I am always surprised no-one ported OpenTracker to another OS.
And I just full of it? If not what else do you think people will port from Haiku in the future?
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
More info about DRI and drivers can be found here:
http://dri.freedesktop.org/wiki/
skyos file system is a fork open beos file system