Yeah! THAT's the spirit!
The folks already DOING the drivers may have reverse engineered some or quite a bit of it by now, so you won't be starting from scratch.
What do you say?

Just to add, I've been wanting this "pedal to the metal" info for 3D cards almost as soon as they started coming out, but no one has been able to help me - they all went either the Open GL or D3D way. But that's not the demoscener spirit, I want the *basic* info - such as, the card has memory for holding textures, right? Can that memory be used for anything then? I've already heard of people programming spreadsheets and whatever, to run on GPUs.....?
What does the phrase "Hardware transformation and lighting" exactly MEAN?

Well, the phrase "hardware transformation and lighting" means very little since the advent of programmable "shaders" in OpenGL and D3D, because you [can] do all transformation and lighting in your own [shader] programs. However - and this IS important in a few contexts - the 3D graphics cards still contain some very real ("hard") hardware aspects to perform certain simple, low-level highly repetitious processes specific to graphics rendering. Still, those aspects can be bypassed to perform non-rendering processes, which is increasingly what GPUs do.

When you program with "shaders" (or GPUPU languages like OpenCL/CUDA) the memory on the graphics card can serve any purpose you [shader] programs wish.

Frankly, it is STUPID that OpenCL and CUDA are being developed - those capabilities should be part of the already-existing [shader] languages. But then again, nobody ever asks me until it is too late [cuz I don't work at nvidia].

One of the advantages of my engine [for demo scene purposes and others] is that it provides a very fast/compact/efficient way to issue [graphics and other] commands !!! without knowing or caring what is the interface to the hardware !!!. Therefore, my engine may perform its graphics [and GPUPU] functions on OpenGL [and OpenCL/CUDA] initially, but if and when I/someone figures out how to drive the video cards directly, the engine would simply become faster (but continue to accept the same commands, and function identially). This kind of interface never breaks, and never needs an overhaul - because the commands deal with fundamental/enduring concepts, not implementation-specific architecture quirks.

Sorry, but the work I am doing is far too important to abandon [even temporarily] unless I had complete graphics card specs to work with. I have reverse engineered a couple things in my day, and though it can be satisfying in the end, it is brutally difficult and time-consuming. I don't have that kind of time, which my personal messages should explain - hopefully!