SciTech Software, Inc. today announced the intention to release the bulk of its proprietary device driver development tools under a new dual license structure. SciTech’s commercially available graphics driver pack, SciTech SNAP Graphics, currently supports nearly 180 graphics chip sets on multiple OS’es with full 2D acceleration. Access to all existing SciTech SNAP drivers will remain available under SciTech’s commercial license and will not be Open Sourced due to existing NDA’s with chip vendors.However, anyone choosing to utilize the SciTech SNAP development tools will have the ability to study GPL samples of SciTech SNAP drivers in the DDK. The dual license will allow developers the ability to quickly tap into this fully plug-and-play support base with little effort.
Our Take: The part that is useful (the drivers) are not getting open sourced. This “openess” will be useless for OSes that already do not support SciTech SNAP (eg. BeOS, FreeBSD, Solaris etc).
If I recall exactly, Scitech drivers are in there own binary format. It looks like they open the tools/technology sources, but not all drivers. Having the source code of their tools should be enough to implement support of their drivers in any x86 OS.
If that is the case, then it might work for some OSes…
But BeOS will have hard time to get a port though. This PC-runtime kind of thing that SNAP does, is really difficult to get implemented on BeOS, because of the way its kernel is made and because of the way it accesses the BIOS…
This will help even a teeny bit.
Any information is valuable information at this point.
On the note of device drivers, I don’t quite get it why alternative OS advocates don’t just get crazy about Project UDI (www.projectudi.org, shameless plug) – they offer a driver architecture that allows binary (!) compatible drivers for any OS supporting that architecture.
They already have SCSI and LAN, with USB coming up. GFX and sound are not yet supported, but I for one will make every effort into that direction since the whole idea of binary compatible drivers is one that should water anybody’s mouth (except those Redmond guys, of course).
Repeat, that’s the one approach that should make the one major issue in creating alternative OS – drivers – a non-issue. Shame it’s so little known / supported yet.
The reason why UDI will never happen is because the FSF and RMS in particular do not like it.
WTF? I hear you say. Read this then.
http://www.gnu.org/philosophy/udi.html
All these **OFF-TOPIC** comments have been moderated down.
If you continue bashing, your posts will also get moded down and if you continue doing it, you will get your IP banned. If you want to bash RMS, you should wait for when we will have a story about GPL or something. Then freely, express your opinion about RMS or whatever related to him and FSF.
If you want to comment HERE though, make sure you talk about SciTech and gfx driver development and nothing else.
Point taken, Eugenia. (Wow. I did not get the impression it was *that* far off-topic to get you worked up. Sorry.
)
OK, talk about gfx driver development. I have to admit that is one of my “blind spots”. Is there anybody around that could give me some mentoring (preferred) or literature recommendations (accepted) on gfx drivers, 3D acceleration, etc.?
(Note: I don’t believe in “the source is the documentation”, so please don’t point me to some gfx.c. What I am looking for is the theory behind it.)
Well, I hate to break it to you, but you’re going to have to read the source. There are few to none nice “GFX Driver Tutorials” out there. However, there are some useful resources that might help.
1) Hardware manuals. 3dfx, ATI, Matrox, and Intel have free register-level specs. Go to each companies website for info. I suggest getting yourself a Voodoo3, downloading the spec (voodoo3_spec.pdf, Google for it) and doing some hacking. The Voodoo3 architecture is very high level and nicely parallels APIs like Glide and OpenGL.
2) DRI documentation. dri.sourceforge.net Read all the docs on the site, and when you’re done, read the drivers. The architecture docs are quite good, and should make it much easier to at least understand at a high level how the drivers work.
3) DDKs. Look at the Device Driver Kits for Windows, QNX, and XFree86. The QNX DDK has an article “Writing Graphics Drivers” and some nice example drivers for i810 and 3dfx. The XFree86 docs have some good information about CRT timings and whatnot, which is more complex than the 3D part. I’m not joking. In the Matrox docs, equal amounts of pages (about 1/3 of the document each) are devoted to the 3D interface and the CRT mode setting information.
4) Read the XFree86 graphics drivers. They’re really not that hard to follow. The NVIDIA driver in particular is concentrated in only a few source files, which makes it much easier to read.
Now if you want a *really* interesting graphics-driver related project, write a driver loader for XFree86 drivers. There’s a very tightly defined API for XFree86 graphics drivers, and they way they are designed makes them binary comaptible in any x86 OS. That, IMHO, would be a far more useful project that writing yet another graphics driver.
From the looks of it Scitech SNAP Graphics already offers *existing* binaries for 180 graphic chipsets – I might have missed something but if this is in fact the case alternate OS vendors have just gained some serious ground on the big boys. Not even the UDI project currently offer this type of out of wide sweeping support – perhaps Scitech should be teaming up with UDI…
Now for the real question where did these guys come from and why have I not heard of them before?
Amongst other things, SciTech is the main provider of OS/2 video drivers. It produces a cut-down version of its drivers in an agreement with IBM who publish these gratis for OS/2 users, rather than IBM having to write the drivers itself.
SciTech also produces for other platforms but this seems to be less well-known outside of OS/2. At one stage, this also included Linux and BeOS, but I don’t think they ever took off and were dropped.
Although they don’t offer 3D acceleration (not a main sticking point for a business OS), their drivers do have some advantages, for example:
I can run my Matrox G400 on my 19″ monitor at 1400×1050 which is an optimum resolution. Using Matrox’ own drivers gives me the choice of 1600×1200 or 1280×1024.
Fine tuning of the above and refresh rates to the nearest 0.1Hz.
They are probably best known for their Display Doctor utility which was supposed to allow maximum 2-D performance for supported videocards.
It now appears to have been supplanted by their SNAP architecture.
according to a source at scitech a Linux version of SNAP is in the works and will offer full 2D acceleration, Plug and play and full binary compatibility for more than 180 different chipsets