SciTech SNAP Graphics for Linux is a simple to use, easy to configure alternative to XFree86 Graphics Drivers. This latest release supports 125 graphics cards on multiple Linux distributions with full 2D acceleration and adds support for the latest hardware from ATI.
Still waiting.. (Note: I am not faulting SciTech in any way for not supporting IGP, one of these days ATI will see that people that use OS’s other than Windows on their notebooks want support too.)
Where am I, is this earth??
Do u want drivers for ATI IGP ? I can send a binaries.
2D + 3D
Ive tried it and they didnt work at all with my voodoo3 card.
=/
risky77: if RC1 still doesn’t work on your Voodoo3, please report the problem on the newsgroup listed in the readme file.
risky77: As Steve said, if RC1 still doesn’t work on your Voodoo3, please provide us with detailed information about your system configuration and graphics card. The RC1 release works on all the 3dfx Banshee and 3dfx Voodoo3/4/5 cards that we have in our labs. If yours is not working, it could be a compatibility issue with your specific distro or your particular graphics card. If we have complete information about your problem, we have can look at fixing the problem. If we never hear from you except “forget it, my voodoo3 doesn’t work”, there is no way we can ever fix it to make it work!
being a techy person, but not (yet) very linux savvy I don’t really see why these drivers are better (or worse) than the xfree86 ones? (apart from no 3d support)
anyone care to explain?
???
How? I have 2D now, and it’s accelerated.. How are you doing 2D and 3D?
I would certainly like a XFree86 driver for my ATI Radeon IGP340M that supports 2D and 3D. Could you please tell me where to get one?
Can you contact me at paul(underdcore)totterman[at]yahoo(dot[com]) ?
2d support is cool if that’s all you are looking for but what I want and need is full 3d support as well. Especially for my Radeon 9700 Pro card. Since ATI driver support is nowhere near Nvidia’s level of support in Linux. Despite that I have heard that they are doing beta tests for new Catalist ( <– arg..spelling ! )drivers for Linux.
If it had 3d support, I play a lot of 3d games on linux and I couldn’t live without 3d. But, this still sounds cool.
Since the SciTech people are looking: Is there anyone looking into a FreeBSD port (or even taken an estimate of the effort)?
Does this support Xinerama? If so, what’s the performance like?
Because, it is very fast. You can check the benchmark in their website. They are working on 3D support if I remember it correct.
They are working on Linux first and if it’s worth, then they might work on port to FreeBSD. I think, I remember one of SciTech team made the comment in here long time ago.
Well the cool part of SNAP is its layered strucutre of its device drivers. They have wrapped all low end 2d-primitive functions. This layer may be wrapped by the device driver, your chipset on the one side – and from the “gui” from the other side….
e.g. IBM licensed SNAP for OS/2 -> so even aged OS/2 as up2date graphic driver support. SciTech wrapped their SNAP towards PM-OS/2-calls.
If the NOW wrapp these calls against X11 – they to have a complete driver set – asl they can reuse all low-level-graphic-bindings (towards the diffrent chipsets)…
This IS an interesting way -> ONE “driver” for now TWO diffrent systems X11 and OS/2… The wrapper part is the bridge 🙂
Now imagine to wrap other systems also… even Windows, QNX… the only thing you have to do is the wrapper for each system (ONE time) and implemant the low-level functions fort your chipset (also only ONE time)…
-> you’ll receive support for a bunch of OS’s all accelereted….
2D already in latest Xfree CVS.
And for 3D there are patches.
AGP already in 2.6 and ac kernels.
look discussion at “http://bugs.xfree86.org/show_bug.cgi?id=314“
ptman:
I sent you drivers.
this is also interesing for companies:
if Scitech has suppor from Intel for the OS/2 development drivers -> you’ll also recieve dirver support for Linux 🙂
and vice versa!!!
Companies like Matrox, ATI may coporate with Scitech – once the low-level part is done – all systems will benefit from it…
SWEET
send to aitvo at fewt dot com
Thx much!
A nice benefit of SciTech SNAP Graphics is that if you are usnig, lets say XFree86 4.0.2 and want to utilize the latest Radeon graphics card you now can and without the need to upgrade Linux or Xfree – in short SNAP decouples XFree version dependencies from the drivers.
They are working on Linux first
Well what about an estimate of the effort to port the Linux driver part. From what I understand of the nucleus architecture there should only be a small part of SNAP that would need porting. Would it be possible for someone outside SciTech port (or wrap) the Linux driver to BSD?
I think this really depends on your perspective. For a single home user/system if you like the idea of getting under the hood of your driver to configure, and or tweak it for use on your specific system then Xfree is still a viable option for you (although you can also do this with SNAP). However, if you’re like me and simply want to install a driver and forget it then SciTech SNAP is a great choice.
For a large corporate enterprise manager (we regularly work with customers that have thousands of divergent machines on their enterprise) the last thing they want to do is worry about which graphics hardware is installed on which systems – With SciTech SNAP they can simply qualify a single image (in relation to graphics HW) and deploy the same driver across all machines on the network. This provides tremendous cost advantages.
as a rule of thumb we estimate that a shell driver for a specific OS can be written in as little as a 1000 lines of code. To get a better idea as to what’s involved take a look at the SciTech SNAP SDK documentation….
http://www.scitechsoft.com/docs/snap_ga/index.html
or contact the folks at http://www.Rocklyte.com for first hand feedback.
As for a SciTech SNAP Graphics for FreeBSD, I can only say that this is planned but no details have been released.
I really don’t think paying for hardware support is the way forward. Companies should get off their a** and develop their own drivers for Linux.
However I guess in the meantime it’s pretty cool.
Does anyone know how it compares to XiG’s accelerated X-server?
Thanks for your support and understanding on the cost issue – Rest assured that we do all we can to keep the price low, and still be in a position to keep the lights on, the Mtn. Dew flowing and our QA team well equipped with HW. – Cheers!
PS If it helps think of the cost as a donation;)
Tough to compare the two, as I recall XiG requires the use/installation of a non-standard X server in order to function (does not work with Xfree86). Where as SciTech SNAP Graphics for Linux allows for complete plug-n-play compatibility within the framework of XFree86 and supports all versions from 4.0.2 and later.
Re: why is this better
“Being a techy person, but not (yet) very linux savvy I don’t really see why these drivers are better (or worse) than the xfree86 ones? (apart from no 3d support) anyone care to explain?”
As many people have pointed out the SNAP Graphics drivers do not yet support 3D, so the focus of our drivers at this particular point in time is for enterprise and embedded/industrial systems customers. Ie: customers who do not need 3D support. For this class of customer SNAP has huge benefits over the standard XFree86 in two important areas:
1. You can deploy a single device driver package across your entire enterprise that supports nearly all the graphics cards on the market out of the box. Simplified maintenance and a ‘one stop shop’ for graphics device driver support is a huge plus for sys admins trying to manage tons of Linux machines.
2. SciTech SNAP Graphics supports not just all the major distros but also *all* versions of XFree86 from 4.0.2 up to the latest 4.3.0 release. Hence a sys admin who has multiple distros on their network as well as potentially multiple versions of XFree86 installed need only look to a single package to support their users.
Of course another major plus to the drivers is that our drivers are fully certified and tested on all the graphics hardware we support. We have a unique device driver certification system that allows us to ship pre-certified and tested binaries, while with XFree86 you have to compile the drivers any time you wish to use them. Every time you compile something, there is a chance that it could be broken and you cannot know unless you test *every* graphics card with *every* compile of XFree86 you do. This is not only virtually impractical for distro vendors who have a lot of graphics cards to test with, but vastly more impractical for a Linux sys admin who needs to support the machines on his/her network.
Re: FreeBSD?
“Since the SciTech people are looking: Is there anyone looking into a FreeBSD port (or even taken an estimate of the effort)?”
Yes, we are planning a port to FreeBSD as soon as we get the Linux version completed and out the door.
I have a Radeon 9600, and while I can run XFree on it and get one display (sans 3-D, mind you), I can’t get both displays to run.
While I expect this to be corrected in future revisions, can I expect to run both displays if I opt for SciTechs drivers?
“Well what about an estimate of the effort to port the Linux driver part. From what I understand of the nucleus architecture there should only be a small part of SNAP that would need porting. Would it be possible for someone outside SciTech port (or wrap) the Linux driver to BSD?”
You are correct in that the port to FreeBSD only requires a small part of the SNAP architecture to be ported. That part is essentially the port of the PM (Portability Manager) library to FreeBSD, and large portions of the Linux version could probably be used to do the port.
As for if someone else can do this port, most definately. That is in fact one of the reasons why the SciTech SNAP Graphics SDK has been released under the LGPL license. All of the source code to the PM library is included in the SDK, so anyone wishing to look at porting the SDK to FreeBSD can do so easily. In fact you can port the entire SNAP architecture to any other Operating System as well if you are so inclined 😉
Dual Head support for the Radeon family is occurring as we speak. However, based on current QA schedules etc., support for dual head on the Radeons is unlikely to be available in the initial release. Sorry I don’t have better news for you on this front.
If you have not yet tried SciTech SNAP Graphics feel free to download the demo here:
http://www.scitechsoft.com/products/ent/enterprise_download/snap_li…
Apparently the drivers suppport multihead on the GF4 cards. Can’t find any documentation on actually configuring them though.
Oh, is more than one physical card supported as well? I’ve got a tripple head setup with a GF4 (twin head) and a GF2MX…
based on current QA schedules etc., support for dual head on the Radeons is unlikely to be available in the initial release
Hmm… Need any beta testers for Radeon dual displays? 8)=
The demo seems to work great in 2-D. Being able to use both heads would definately make it a “must have” for me!
Now that’s the kind of response we like to hear:) You can sign up for the product mailing list at the following URL and get notification upon the release of any betas…
http://list.scitechsoft.com/mailman/listinfo/announce.snap.linux
Feel free to send me your contact information and I will forward this on to our dev team – they are always eager to get out side feedback.
Ok guys, sorry for being honest. Here I go again,
a) Installed on both a Red Hat 8 and Enterprise Linux 2.9AS boxxxen && exec the install file && not worked =/
Simple!
Athlon K7 700 256 RAM Voodoo3 AGP 3000
I guess it has to do with the driver since the monitor setup tool worked flawlessly
Hope that helps
Thanx and excuses for being less informative
Risky77, can you try to see if there is a graphics.log file generated, and send this along with information about your hardware and machine configuration to our support staff? [email protected].
Thanks!
What the difference between the “demo” version and the one you purchase. SNAP Graphics seens to be a really great product but if i can’t be bundled with downloadable distributions, what the interest.
When will they make some drivers for windows?
“Demo” was bad wording, I think Andrew meant “trial version.” It works for 21 days if you don’t register.
Regarding Windows drivers – we’ve been there before. If you go to our web site, you will find SciTech Display Doctor for Windows in the “SciTech Classics” section.
Will there be any hardware manufacturers that will write there own drivers for the SNAP system?
This would be great because hardware companies that are hesitant to port drivers to other platforms, could just write the driver once, and let everyone use it (reguardless of the OS they choose). This way they would only have to maintain two sets of drivers (at least once 3d is supported in SNAP).
One question though. If hw manufacturers are able to write (and distribute) their own drivers would users still need to purchase SNAP from SciTech? Or would they just have to download the framework, and install the manufacturer driver for the SNAP framework?
I’m thinking that the product that must be licensed is the drivers themselves, not the framework. BTW, I think SciTech would still have a good product for IT companies, so I don’t think that would hurt your sales.
Am I babeling?
I should clarify that I meant by 2 drivers that they would have a windows driver and a SNAP driver. It would be ideal if manufacturers would develop drivers for each specific OS, but the reality is that they aren’t, and I think if they had the option to develop just one set of drivers for all the OSS OSs, they would be inclined to do so.
Currently, the 320/340M drivers are supported under the current Linux kernel as 2D only. Apparently, there was no AGP support for the IGP chipset and so for XFree 4.3 only 2D was made available.
There are now patches for various kernels and for XFree to add 3D support, although its still buggy. If you’re interested in playing with it, you can find more info at http://bugs.xfree86.org/show_bug.cgi?id=314
As for SciTech, I just don’t understand what they have to offer. I must not be the target demographic.
RC2 is now available, with support for 10 more chipsets (some 3DLabs, Trident, and S3 Virge chipsets).
Mmmm… Well I’ll wait for full ATI 3D, until I’m convinced. Neither Xfree of ATI are anywhere with 3D on radeon based cards. I guess someone needs to take the lead. I sure hope it’s these guys…
Q
I don’t think any hardware manufacturers would want to exclusively write a driver for Snap. Would you want to see after you open the box for your new video card: “Please go to http://www.scitech.com and enter your CC# to download drivers for this product?” If the hardware company pays for the license for end users, that’s just going to raise the price of the final product, when they could just as easily stick with their one driver solution for no additional cost (as long as Windows has a high majority of desktops anyway).
How is the PowerPC version coming along? 🙂
@ Tyr:
> I really don’t think paying for hardware support
> is the way forward. Companies should get off their
> a** and develop their own drivers for Linux.
What happened to the high-flying goals of breaking Microsoft monopoly and opening the way for a free-for-all operating system market? Wasn’t the all-powerful driver support for Windows recognized to be the #1 point of failure for any competitor?
Well, now that the GNU/Linux camp sees daylight, what are they doing? They kindly ask the hardware vendors not to support existing cross-platform driver architectures like SNAP and UDI. Instead, they want to replace the Microsoft monopoly with a Microsoft / GNU duopoly.
What’s up, are you afraid by the competition you might get, e.g. from AmigaOS, or some other competitior-in-the-making?
The hypocrisy of the GNU camp makes me sick. There are cross-platform driver concepts, which could open up the ballgame for all so people could chose the best OS instead of the best driver support, and they are actively opposed by the FSF and their evangelists.
Welcome in the circle of the powerful. You forgot your roots. Power corrupts.
Because one person gave their opinion? Are you so simple minded to think that one person speaks for the community? LOL
Well RC1 has now been eclipsed by RC2, as reported in an earlier post. Our Engineering and QA Teams continue to increase the number of supported chipsets as well as address feedback from users. Look for the official release in the very near future.
In addition to SciTech SNAP Graphics for Linux, OS/2, DOS and Qt/Embedded we also continue to improve the SciTech SNAP SDK, which provides developers with the ability to easily port the SciTech SNAP Graphics Shell driver for use on other OS’es. If you are interested in doing so I encourage you to take a look at the SDK documentation located on our website. http://www.scitechsoft.com
Cheers,
Andrew
When will they hae a DOS port for my a: drive?
I meant that in the case of Hardware manufacturers supporting SNAP, there would be no fees from anyone. As I see it, the framework is free, and if a Hardware Manufacturer developed and released their own drivers (as opposed to the ones that SciTech developes and sells) they would also be free.
In other words – no extra fees.
P.S. The SciTech guys would have to figure how that would enter into their licensing and sales formula. It would, if HW manufacturers jump on board, give the SNAP frameword greater market penetration I would imagine.
Look no further than IBM for an example of a vender utilizing SciTech SNAP to provide support for graphics HW to their customers. When IBM licensed a special version of SNAP for use on OS/2 systems they did so in a manner, which required no additional licensing, between IBM’s customers and SciTech.
The result, OS/2 users world-wide have great graphics device support.
“I meant that in the case of Hardware manufacturers supporting SNAP, there would be no fees from anyone. As I see it, the framework is free, and if a Hardware Manufacturer developed and released their own drivers (as opposed to the ones that SciTech developes and sells) they would also be free.”
The framework is available under a dual LGPL/proprietry license for the *SDK*, not the DDK. The DDK is not yet released, and when we do get around to releasing it (soon we hope!) it will be dual licensed under the GPL, not LGPL. Hence hardward vendors who wish to build SNAP drivers for commercial distribution (ie: non-GPL drivers) will have to purchase a commercial license to use our non-GPL DDK. If they wish to build GPL drivers and give out the source code, then they wouldn’t need to purchase a commercial license, but a lot of graphics vendors are not interested in having their IP be exposed to the public via GPL drivers.
I’d sure like to check this out when a FreeBSD version is available.
So in order for say nVidia to release a binary package for SNAP on X86 (in a manner that is as easy to download as windows drivers), they would have to purchase a DDK license?
Would they be interested in doing that? I guess it would make sense for them, if SNAP is available on enough platforms.
Also, what is the SDK? Is that for porting the framework to other OSs, but not the drivers?
Just to add on to what I’ve been saying, nVidia would be able to easily port their drivers to any platform that supports SNAP right?
It would be simply a matter of recompiling the driver, and writing a new install routine?
Thanks.
> Because one person gave their opinion?
No, because I am facing this attitude for years now everywhere I look. Check out http://www.gnu.org/philosophy/udi.html if you don’t believe me this is real.
Also, what is the SDK? Is that for porting the framework to other OSs, but not the drivers?
Good question. The SciTech SNAP SDK allows developers to port the SNAP Shell Driver to other OS’es as well as write applications which talk directly to SNAP Graphics. To better understand this concept you first need to understand how the SciTech SNAP architecture differs from a traditional device driver.
In a nutshell, a traditional device driver is written such that the OS and the HW specific code are really rolled up into a single driver – which by design only supports a single OS. This works great in a single OS world. However, in an environment where multiple and divergent OS’es exists this concept falls flat on its arse, as it is often too expensive/time consuming to support multiple OS’es in this fashion. The result poor vender support for alternate OS’es.
With SciTech SNAP we have separated out the two distinct components of a driver namely, the OS specific code (shell driver), and the HW specific code (device binary). What this means is that by simply porting the shell driver to your desired OS you gain access to all supported SNAP Graphics driver binaries. This is covered in more detail in the following white paper.
http://www.scitechsoft.com/pdf/SNAP%20White%20Paper.pdf
It would be simply a matter of recompiling the driver, and writing a new install routine?
Really just a matter of compiling a new shell driver for each OS in which NVIDIA for example desires to support. As mentioned earlier if the HW it self does not change then why should the HW specific code need to be changed to support a new OS;) – again check out the white paper (link in an above post) for more information.
Cool that clears it up very nicely, thanks.
So then, could nVidia, for example, release the compiled HW specific code (device binary), part of the driver, with a software interface and allow OSS developers to develop the OS specific code (shell driver) part of the driver?
Would this effectively hide the proprietary portions of the driver? If so, that would be a great way to make it easier for the OSS community to write their own drivers for their own platforms.
It could be the perfect marriage between proprietary code from hardware vendors and the OSS goals of the OSS community, if that were possible, and HW vendors would go for it.
If I am understanding you correctly then yes. A possible scenario might look like this.
NVIDIA contracts SciTech to write a SciTech SNAP driver binary for the nv-xyz chipset they could (depending on the license) freely distribute the binary driver to whom ever they wanted. (or they could license the SciTech SNAP DDK and write the driver themselves)
As for OS developers They can either license the commercial version of the SNAP SDK and develop a closed src shell driver for their particular OS or use the LGPL version and build an open src version of the shell driver. We have tried to make the process as flexible as possible for all involved. More info on our various licensing options are available on our website: http://www.scitechsoft.com
IF you have additional questions feel free to email me.
RC3 is now available, bringing the total number of supported chipsets to 150.
I am not an official Syllable developer, but is it possible today to build a shell driver and distribute the binary drivers in a package for Syllable without users being charged for the license?
“is it possible today to build a shell driver and distribute the binary drivers in a package for Syllable without users being charged for the license?”
Yes, this is possible, and we actually prefer to see it done this way – meaning the OS vendor taking the steps necessary to ensure that a wide range of HW is supported on behalf of their users. As for creating the SciTech SNAP shell driver, the tools are available on our website to do this in the form of the SciTech SNAP SDK
For your suggestion to occur the OS vendor simply needs to licenses the driver pack for inclusion in a given OS- as an example of this in action take a look at Rocklyte (www.rocklyte.com) , whom includes SciTech SNAP Graphics drivers with Athene.