OSDev.org

cb88 wrote:nouveu supports 3D for some definition of usable on many cards

Ok, I was wrong. I thought because my GTX 580 was software-rendered that there was only "experimental 3D support," not for-real average-user 3D acceleration. Ok, nouveau does have 3D acceleration, it's just pretty slow still:

http://www.phoronix.com/scan.php?page=a ... flip&num=1
http://www.geeks3d.com/20120110/linux-m ... 0-gtx-580/
http://www.phoronix.com/scan.php?page=a ... um3d_first

Edit: I use nouveau for my box, so I want nouveau to succeed. I figure that will happen if a lot more people start using it. Maybe you should get an nVidia card after all and try to get it to work!

I personally know a nouveau developer, and I think I'll abuse him for a bit to get my own native NV driver running sometime

That said, NV is such a freakingly complicated chip that driver functionalities get added bit by bit. Heck, you even need to access the onboard ROM even with a native driver since every producer configures the chip in his own way. Then overclock so it has processing power beyond basic sequencing, then load shaders and whatnot. If your card is aged a year or two, you'll probably can get 3D support.

Then there's the radeons which have a firmware thing you'll have to deal with.

Then there's intel, and for i8xx/i9xx the documentation was occasionally off sufficiently that it was just as unreliable (and I heard the devs pretty much operate on reversing and actual intel employees).

IMO, The three represent the choice between lawful, neutral, and chaotic evil.

------------

Back to the starters:
A voodoo 1 is an exceptionally interesting device. It's actually easier to program than a VGA, has minimal differences between the opengl and native interfaces, and if you don't daisychain it you can even test multihead support. In other words, the voodoo 1 specific parts are going to appear like a dummy driver compared to all the framework you will need anyway.

Well since you mentioned the voodoo one I was looking for documentation... is there any besides the open source drivers for it? I found alot of historical information but thats about it. Probably just looking in the wrong places.

Hi,

cb88 wrote:Well since you mentioned the voodoo one I was looking for documentation... is there any besides the open source drivers for it? I found alot of historical information but thats about it. Probably just looking in the wrong places.

I did a little searching and found links to the specs for several versions of "3dfx voodoo" video cards.

I've also got a book called Programmer's Guide to the EGA, VGA, and Super VGA Cards, which is a large and badly structured book, that contains a lot of information for old video cards.

I'd recommend gathering as many video card specs as you can (e.g. old stuff, Intel and ATI) and browsing through them. Then looking at the features supported by these cards and modern graphics APIs (OpenGL, DirectX) to determine what features you expect an OS's native video driver to support. Once you've researched, designed and documented the native video driver API for your OS; implement a "framebuffer" driver with software rendering, and develop some test applications (possibly including GUI/window management, page layout code, widgets, etc).

After that, I'd start with a "dual video card" system. The idea is that you'd use your existing/working "framebuffer" driver on the first video card to see what you're doing while you experiment with the driver for the second video card. For example, you might start with a dummy driver (with little more than a "get/set register" interface) and an application that uses the dummy driver to let you view the second video card's registers and modify them manually. Then you'd use your application/tool to figure out how to set video modes, and debug the driver's code when setting a video mode goes wrong; and then keep using the application/tool to figure out 2D acceleration, etc.

If you try to develop a video driver on a "single video card" system, then you will be working blind; and there's also a greater risk of making mistakes/assumptions that prevent the video driver from working correctly when the video card isn't the first/primary video card (e.g. inadequate initialisation code that "works" when the card is the first/primary card because you were lucky and the firmware happened to leave something initialised).


Cheers,

Brendan

Brendan wrote:After that, I'd start with a "dual video card" system. The idea is that you'd use your existing/working "framebuffer" driver on the first video card to see what you're doing while you experiment with the driver for the second video card. For example, you might start with a dummy driver (with little more than a "get/set register" interface) and an application that uses the dummy driver to let you view the second video card's registers and modify them manually. Then you'd use your application/tool to figure out how to set video modes, and debug the driver's code when setting a video mode goes wrong; and then keep using the application/tool to figure out 2D acceleration, etc.

If you try to develop a video driver on a "single video card" system, then you will be working blind; and there's also a greater risk of making mistakes/assumptions that prevent the video driver from working correctly when the video card isn't the first/primary video card (e.g. inadequate initialisation code that "works" when the card is the first/primary card because you were lucky and the firmware happened to leave something initialised).

Alternatively, rather than a dual GPU system... you could just run your experimentation interface over the serial port. Of course, this unfortunately won't tell you what the firmware left initialised... but every video card today is initialised by executing bytecode stored in its ROM anyway