The probability of hw-accelerated graphics in a hobby os

[RadikalRane]

It's been a long time since I made a post on these forums, mostly because I lost track of my OS project because of university work, other projects, and lack of code documentation (stupid me)

As a form of unofficial uni-research (with lots of interest from various professors) I'm now doing a world-simulation engine, which could also be used as a game engine
I'm going to spare you all the details of this project, but the thought crossed my mind of how cool it would be to have this project running on a homemade OS (I'm probably not the first one to have this kind of idea)

Now, I know what you're going to say, and I do realize that obtaining the right information on how to write drivers for modern graphics cards is close to impossible, and I want to assure you that this is all purely theoretical and that I have no actual intent of attempting to write an OS with hardware accelerated graphics

So, on topic, what has the hobby OS development community achieved in terms of HW-accelerated graphics? Are we already able to actually support for example an OpenGL implementation actually running on a GPU (modern, or outdated), or is this still something to 'dream' about?

[Solar]

The magical word here is "manpower".

If your hobby OS is a one-man show, there is little to no chance you'll ever get even your hardware fully supported. By the time the drivers are halfway stable, you'll buy a new computer and start over.

You effectively have only two chances:

1) Somehow tapping into an already-existing driver base. Very difficult: The two largest driver bases out there (Windows and Linux) have zero interest in sharing with you. You would have to emulate their driver interfaces (and, by consequence, quite some of their architecture), at which point you will find it difficult to be different. Other driver bases, which do keep shareability in mind, are not exactly big driver bases (UDI, CDI, ...), and in any way don't provide 3D hardware accelerated graphics at this point of time (AFAIK).

2) Getting enough people interested in your hobby OS to get your own driver base established. (This might overlap with "shareable driver base" above.) This is also very difficult, because the Holy War of the Operating Systems has divided the world in Black and White (Windows / Linux, or Linux / Windows depending on which side you are on), and the vast majority of people that have the skill to do driver development are firmly entrenched in one of the two camps.

The rest is developing their own OS and share your problem.

[Brynet-Inc]

For at least AMD/ATI, Intel, VIA.. there is some documentation and code.

nVidia is pretty much hopeless, you might be able to gleam some basic understanding of modesetting, but that's about it.

There are other more important areas of your OS you'll want to work on before worrying about accelerated graphics and fancy effects..

[RadikalRane]

As mentioned in the OP, I'm not interested at all in writing an OS with support for accelerated graphics, I was just curious about what has already been achieved by the community

[Brynet-Inc]

As mentioned in the OP, I'm not interested at all in writing an OS with support for accelerated graphics, I was just curious about what has already been achieved by the community

The "community" isn't that well organized, has anyone done it yet? not a clue.

[Tosi]

Last time I tried it, the Linux driver for nVidia cards, nouveau, only supported 2d acceleration. Not only that, I stopped using it because it kept crashing on me. So the only other choices are a proprietary driver from nVidia, which does support 3d acceleration and is relatively stable, or a generic driver which does most things in software, and is very stable. If Linux, which has been around for a while now, and has expended tons of man-hours, has only gotten this far, don't expect to get very far with 3d hardware acceleration in a hobby OS. The main reasons being that developing drivers for even the most common cards would take a lot of time, and the documentation for many cards is practically non-existent outside of modesetting and some basic 2d acceleration.

[Hangin10]

Not to mention many of the documents that exist (like many official specs) assume that the reader already knows how a modern card works. A list of register bits doesn't help if you don't already know in general what you need to do in order to, for example, change modes. AMD's docs in particular leave out necessary registers even though the register is mentioned several places in the document for its effects on other registers.

[Combuster]

If you need to know I have hardware acceleration functionality for Mach64 and Trio64-based chipsets, and very primitive 3D acceleration for 3D Rage and Voodoo chipsets. I also have basic access to the GPU of the V2x00, but haven't yet integrated some custom firmware to offload rendering to it (apart from the fact that I have no usable information on the coprocessors which are normally responsible for the rendering).

All of the above are relatively old chipsets, but it is basically about what you are opting to do: the more modern the chip, the more trouble you have getting it to work. The source is available, and unlike the linux developers, I don't mind answering questions even if it's not about my own os.

If you need manuals, the VGA is very well documented, VBE has a good open specification, and 3dfx does a fairly good job. All the other things I have seen and tried are crap in comparison (for example, intel having manuals is largely propaganda: of all the 8xx and 9xx chips out there, only the i82965 is documented, and it does not contain the information you need to program all the older ones - it appears that AMD is doing a better job at it).

[OSwhatever]

Speaking of which, driver development for HW companies takes up a lot of resources especially if you're going to support Windows, Linux, Mac and so on. If you have a HW and want to support any kind of OS that might exist and also will exist, how about distributing a library that enables you to implement the driver in any driver infrastructure. Since companies are reluctant to distribute source code, how about distribute the object code instead.

This is of course easier said than done. The difficulty lies in defining such library so that it can be used in any driver architecture. However, if the industry gets the experience doing this, it would be a benefit for both the company and the end user. This would make the long term support much better while also helping the company widening its customer base.

[Kevin]

Speaking of which, driver development for HW companies takes up a lot of resources especially if you're going to support Windows, Linux, Mac and so on.

Well, reality is, there is no "and so on". Problem solved.

If you have a HW and want to support any kind of OS that might exist and also will exist, how about distributing a library that enables you to implement the driver in any driver infrastructure.

That's basically what CDI/UDI try to achieve. Don't count on the hardware vendors, though, if anything it's something that works for sharing third-party drivers (i.e. you may be able to use the same drivers as a different hobby OS).