Here’s a review of SciTech’s new SNAP Graphics 2.0 for GNU/Linux. It’s a hassle-free video driver program for X that gets excellent 2D performance. When SciTech implements hardware 3D rendering it’s going to revolutionize XFree86 Linux drivers. Read the review for the benchmarks and details.
SciTech SNAP Graphics: Commercial Drivers For XFree86
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
with proper drivers, we might actualy get something akin to an x-lib that will offload the graphics work to the GPU rather than rendering in the CPU….Linux does lag behind inthis aspect, and it will be hard to compete until we have proper drivers.
3D Support is what I’m waiting for, 2d is neat and all, but I do a lot of OpenGL tinkering, and as this article shows ATi’s 2d drivers are about as fast as SNAP (except for the copy image operation which is blazingly faster on SNAP).
I think it’s safe to assume that the vast majority of current Linux users aren’t very keen on paying for (admittedly nifty) unified drivers based on the limited success of commercial OSS. You’re certainly not going to win converts from the Windows world where drivers come with the OS or the device for free.
Both the major 3D players (Nvidia and ATI) have official drivers available for Linux and alot of the generic 2D display adapters are supported natively anyway.
I just don’t see this going anywhere significant, let alone revolutionizing Linux drivers.
“When SciTech implements hardware 3D rendering…”
The keyword here is When? Are we talking next week? Next year? Two years ago would have been nice to correspond to when Linux had attention from consumers. People heard the hype, tried Linux, then went away.
When are Linux companies going to begin taking video seriously? Here are some relevent quotes from the article:
“Before all of this, though, I had spent two days trying to get other drivers to work with my video cards so that I could run my performance tests on them”
“lockups in Unreal Tournament 2003”
“drivers from Gatos, which were a complete disaster.”
“unable to get the Nvidia drivers to work on my standardized test system despite spending an entire heartburn-filled day trying”
“the Nvidia drivers wouldn’t work with a stock Slackware 9.0 installation (and also Mandrake 9.1, 9.2 RC1, and Xandros 1.1)”
“…Debian flavors but they all either failed to detect or accept a driver for the onboard NIC (the EEPRO100 module doesn’t seem to load on some Debian distros) or crashed during installation (Knoppix, Morphix, Sid, Sarge, and Woody all failed on this hardware setup) probably due to the Nvidia video card. Gentoo breaks too easily…”
While I boot Linux as an alternate OS myself, I’m tired of the Windows-bashing and the crap about Linux replacing Windows for home users.
-Bob
I run both NetBSD and Slackware Linux. Recently I have registered SNAP for Linux for my Slackware installation for one of my machines. It works great and requires almost zero configuration. If SciTech releases a NetBSD version I am almost sure I would buy it.
It is especially useful in larger heterogenous networks with differen X versions and graphic adapters, because it can be configured automatically. It is also very useful if you only use 2D (like I do most of the time), but when it also supports 3D accelleration it can be a killer app (errr, I mean killer driver
.
It’s irrelevant to the slashbot, linux zealot kiddies whether linux has good video support or not. If linux was console-mode only they would go around saying guis are for wimps.
generalisations are a great thing aren’t they, just cause there’s a vocal bunch of gobshites out there who brag about their dislike of windows and use Linux instead, doesn’t mean that all Linux users are like that. I’ve no problem using W2k, heck i use it everyday at work, along with Tru64 and Redhat 9, however at home my main OS is linux, if i wanted to i could put FreeBSD on, but having used Linux now for nearly 5years i’m fairly comfortable with it.
regarding graphics while lurking on the Xouvert mailing list today i came across a link to a “Y windowing system” that some college fella did up for a final year project, the project reports makes for fairly interesting reading. Here’s a link
http://www.doc.ic.ac.uk/~mbt99/Y/
the report link:
http://www.doc.ic.ac.uk/~mbt99/Y/report/MarkThomas.pdf
but that doesn’t stop me from having something pretty to look at.
I have to agree with robelanator. I’ve been hearing about this for awhile.. the one time I felt compelled to try it it didn’t support my video “card”… which is actually onboard i825 if I remember correctly. It sorta pissed me off because in X it falls under the i810 driver, and from what I know such onboard chipsets for handling video are quite common in cheap PCs and laptops — so I would have assumed they had support for it.
When it didn’t have support it gave me a very obscure error message on installing which really didn’t mention anything about my card not being supported… so I felt as if I was doing something wrong. All in all, I had a horrible experience with Snap graphics.
I’ve never had speed issues with X’s i810 driver, and while numbers may prove different, the user experience is tip top. On my other system I have a GeForce2 MX… so NVidia’s drivers are all I feel I need for that. And despite what one person noted in the review, NVidia’s drivers work perfectly fine installing/compiling on a default Slack 9 install, as that’s what the system is.
I guess I’m just not seeing anything too revolutionary about a commercial solution to an open source problem.
The issue with the i810/i815 driver is that in order to get this to work, we need support for some things that are not available via the Linux kernel. Under OS/2 and other OS’es we support this hardware, but that is because it is real easy to install a kernel device driver that implements the pieces we need.
Suffice to say we are working on a solution, but this solution *will* require a SNAP specific kernel module to be installed (as will 3D for that matter ;-). The catch of course is that with Linux the kernel doesn’t like it when you install a kernel module that was not compiled for that *EXACT* version of the kernel. To do that, you need the kernel source code that corresponds to the kernel install in the machine, which 9 times out of 10 is not installed on the machine! So our original plan of simply recompiling the kenerl module on the end user box is not suitable (DRI tries to do this and fails for the same reason on many boxes).
We will probably end up at least just releasing the GPL source code for the kernel module for those intrepid souls who are willing to compile it against their kernel source code, however that is not a clean plug and play solution. We are working on a solution to allow a pre-built kernel module to be installed, but it will take some time to get this solution implemented.
Hmm, I checked out the product supported chip list page and noted that the i810 (nor the i825, though not sure that chip exists) is not listed as supported – I suggest if you are interested in trying SciTech SNAP that you first read the supported HW list which is quite extensive…
http://www.scitechsoft.com/chiplist/snap_linux_chiplist.html
It seems some SciTech people are reading OSAlert, so I will take the opportunity to ask what I always wanted to ask
. I heard some rumours SciTech is working on FreeBSD support. Is there any chance that you will also release a NetBSD version?
If not, I hope porting the “shell code” isn’t too difficult, I am not good at C
every now and again it would help if I looked up to see what I typed
The SNAP drivers seem to pale in comparison to the NVIDIA drivers. Heck, even the VESA drivers give it a run in places! Just saying something is fast doesn’t make it so!
On to the benchmarks!
Note: My machine is slower than the article’s in every respect!
2.0 GHz P4. vs 2.53 GHz P4
640MB DDR2100 memory. vs 512MB DDR2100
GeForce4Go 440 vs GeForce4 Ti 4200
Note that graphics card: The GF4 Ti is based on the GeForce4 architecture, so it has some improvements in the memory controller that the GeForce4Go (which is based on the GeForce2 architecture) does not. Also, the 4Go has 6.4 GB/sec of memory bandwidth, and the Ti 4200 has 8.0 GB/sec.
My results are listed first, then the results from the article:
500×500 stiple rect: 2570/s — 941/s
500×500 tiled rect: 1920/s — 1770/s
500×500 tiled rect (2): 2200 — 1780/s
500 pixel line segment: 200,000/s — 31,700/s
500 pixel rect outline: 75,300/s — 34,300/s
500 pixel circle: 17,100/s — 9370/s
500 pixel filled ellipse: 9120/s — 6680/s
300 pixel stiple trap: 3040/s — 1040/s
9×15 character: 6.94 Million/s — 1.32 Million/s
k14, k24 character: 2.03 Million/s — 0.45 Milllion/s
RGB character: 0.44 Million/s — 0.20 Million/s
500 pixel scroll: 1970/s — 2000/s
500 pixel copy (WinWin): 1940/s — 1870/s
500 pixel copy (PixWin): 2270/s — 1860/s
500 pixel copy (1-bit plane): 3830/s — 1470/s
PutImage XY: 71/s — 50/s
GetImage XY: 0.2/s — 0.2/s
Wins just a single benchmark, with a tiny margin, and loses on most by a factor of 2. I’ll post benchmarks with the XF86 nv and the SciTech on my machine when I get around to it.
good to see a solid review of substance – i even ran some of the x11perf tests myself. very surprised to see that the SNAP drivers give better results that the ATI/Nvidia drivers. that is odd.
should be surprised though – my nvidia driver freezes my machine on occasion.
i also notice that the SNAP don’t support the ATI IGP 9000 chipset – wish i had not bought a laptop with those cursed chips in now.
i would pay for a solid X driver, especially for 3D, and especialy for bog-standard chipsets on laptops.
In the spirit of “Free Software” (I don’t mean price) I would rather use drivers released under the GPL. It looks like the SNAP drivers have to be purchased, can not be redistributed and probably are not open source. I’m aware they have an SDK that might be under the GPL, but that doesn’t help.
Besides, I’m more than pleased with the performance of my current XFree86 drivers. I have no intention of buying proprietary ones.
lol… the author of that article seemed oddly obsessed with his viewable image being centered…..
correct me if i’m wrong, but i was under the impression that the average display saves its Geometry settings on a per resolution/frequency-combo basis. (For example, 1024×768@75hz and 1024×768@85hz are two distinctly different profiles saved on the monitor). As long as your display drivers are tuned to the particular combination (profile)…if it worked before, it should work again w/o adjustment.
I’ve never had a problem with the stock x-drivers throwing my screen off-center, unless it was set to some obscure res./freq. setting.
And as for the nvidia driver compilation problems… I’m nowhere close to being a linux expert, and I’ve never had the problems described in the article. I’ve successfully compiled and installed Nvidia drivers on RH 8-9, Gentoo, FreeBSD, and Debian without so much as one hiccup… The only slight issue I had was with SuSE (minor confusion about that fake/non-3D “nvidia” driver), and I was able to get that to work after only a few minutes.
*shrug* …i guess we all experience different issues with these distros… but some of the comments the author makes just seem illinformed and slanted—(i.e. “gentoo breaks too easily” and “takes far too long to install.”)… and why was RedHat (a very complete & widespread distro) barred from consideration? It comes with just about everything (kernel sources, dev-libraries, etc.) you would need to complete these benchmarks…
Don’t get me wrong, I’m all for the expansion in graphics support for free Unices…. but this review’s reliability and validity should be questioned.
“i also notice that the SNAP don’t support the ATI IGP 9000 chipset”
We are talking to ATI about adding support for the IGP family of chipsets. ATI like Intel and some others are very good about providing us (SciTech) with HW and specs, and have been doing so in relation to desktop units for a long time. The embedded and mobile space is typically slightly more difficult due to the nature of the HW (more expensive/lower quantity…) but rest assured support is coming:)
Well, that was a short experiment. Apparently, the SciTech drivers don’t have the PCIID’s of my card, even though it is functionally identical to the GeForce4MX 440, which they *do* support. My experiments with the XFree86 ‘nv’ drivers were interesting.
Apparently, they don’t bother accelerating non-core operations like lines, trapazoids, etc. However, for stuff like blitting images, they’re comparable to the SciTech and NVIDIA drivers. For example, the copypixwin500 operation gets you 1870 operations/sec, which is not that far away from the NVIDIA result of 2270/sec. This makes a good deal of sense, since, in this age of anti-aliased everything, the traditional line/trapazoid/etc operations make little sense, because nobody wants to see jaggy primitives. Most apps these days really depend on the blitter more than anything else.
Interestingly, neither the ‘nv’ nor the SciTech drivers accelerate RENDER, while the NVIDIA drivers do. This makes a huge difference in performance, because without RENDER acceleration, all AA text has to be blended in software. In terms of UI feel, this negates any improvements there may be in other operations.
I’ve used SciTech on OS/2 and it is good to see their Linux products getting a little attention. I don’t need 3D and make up my mind based on what my eyes see, not on which driver gets the most points in a test. So, I’ll give a go at the evaluation version. If it delivers a better display with my Matrox G550, I’ll buy it.
“Apparently, the SciTech drivers don’t have the PCIID’s of my card, even though it is functionally identical to the GeForce4MX 440, which they *do* support.”
What card are you using? To be clear we list cards (by PCI device ID) as certified only after they have passed an extensive battery of tests – both qualitative and quantitative. To do this we require the card be physically plugged into our test harness where the specifics of the card are captured and then flagged as certified or failed upon completion of our QA tests. So while “functionally” your card may act similar to a card we list as certified it was deemed unique enough by the HW vender to warrant a unique device ID and their fore must be tested and certified as a discrete chipset.
Its a GeForce4Go 440.
What’s the point of comparing nvidia drivers with SNAP, since nvidia doesn’t release the documentation for their cards I think it’s obvious that no one is going to make faster drivers than nvidia themselves.
I’m a linux newbie asking this simple question:
Why would I buy SNAP drivers for my GeForce4 MX 440 card when nvidia drivers install very easily (did it on mandrake, redhat and gentoo), are free and outperform SNAP drivers?
And oh, I run gentoo, and have yet to see it break. I seriously question the authority of the author to perform this review.
Your card is a laptop chipset, which we do not support. A point that must be made is that the NVIDIA support we do have is very sub-standard compared to the rest of our drivers, so comparing the NVIDIA binary drivers against SNAP is not a fair comparison. The reason for this is that NVIDIA does not release any specs (nor provide us with any hardware either; we buy it all ourselves!!) and hence the support we do have is cobbled together from the information we can gather from the XFree86 ‘nv’ driver source code. Essentially there are a number of critical limitations in our NVIDIA support that we cannot rectify as we do not have access to the necessary information:
1. Laptop support
2. Proper flat panel support
3. TV support
4. Hardware RENDER support
5. Full 2D hardware acceleration
6. 3D support (of course
There are a lot of things in the SNAP device driver architecture that we cannot acclerate on NVIDIA hardware due to lack of information. We get by OK on the stuff we can do, but a lot is missing.
Another thing is that this is the first generation of our XFree86 shell driver module, and as such it is not as highly optimised as we would like. We have already documented a number of areas where we can get major improvements, and our developers are already in the process of implementing a lot of that code. No guarantees on when it will be out, but we are expecting a decent performance improvement across the board (ie: for all chipsets) in the next major release.
“It seems some SciTech people are reading OSAlert, so I will take the opportunity to ask what I always wanted to ask
. I heard some rumours SciTech is working on FreeBSD support. Is there any chance that you will also release a NetBSD version?”
We are working on a FreeBSD version (as well as PowerPC versions), but not NetBSD. However FreeBSD and NetBSD are very similar, so once the FreeBSD version is done I expect a NetBSD version would not be too difficult to complete. Porting the shell driver code is really not that difficult.
I run a dual head configuration using two different video cards with Xinerama. I noticed that both of the cards I’m using is on your supported hardware list (Permedia 2, Mach64 CT… yeah, I’m poor). I was just wondering if the SNAP drivers will function properly under that environment with all the same benefits I would expect to get if I were using only one of the cards (e.g. both cards being accelerated at the same time).
If so, I’ll be more than happy to purchase SNAP, oh and if you need anyone to beta test something like the above…
even though I might go back to the ATI binary for 3D. I like to support small companies whenever I can, like buying Slackware 9.1 rather then waiting for the ISO.
I was just having a look at XIG Summit products and it seems to me that it would be alot better value for money to get the Desktop version of Summit for $39 and you get 3D and 2D acceleration.
Oh, btw, they’re available for Solaris meaning that once Madhatter comes to Solaris x86, simply buy a summit driver and you will see better performance and hardware support.
This set of performance results focuses on the numbers produced by the tool ‘x11perf’. Sadly, this tool is not useful for benchmarking X11 for real use. x11 perf focuses on the set of traditional X11 primitives that very old applications use, and does very little to address how modern X11 applictaions and toolkits use the protocol.
A more useful set of tests would have focused on common GTK and Qt widget operations, scrolling, text production, antialiasing, and so on. This isn’t an easy thing to scrape together for a quick review, I admit, but it’s quite easy to do a bit of searching X developer mailing lists to discover that x11perf is outdated.
Doing a GTK or Qt test would be testing the toolkit, not the driver. x11perf is largely useless for testing overall X11 performance (because pretty much the only thing modern apps use is the blitter routines, maybe some line drawing and area fills). However, we’re testing drivers here, and x11perf maps pretty closely to what the drivers are required to do, and as such is a good benchmark to use in this case.
While I dont think I would ever purchase a close-source driver for X, I’ll still wish you good luck. =)
It’s just a shame that Nvidia are unwilling to share the specs of their cards, as both closed-source and open-source projects could profit from access to those.
True. Just look at Creative. They claimed that if they made their SoundBlaster driver opensourced their whole world would come to a crashing end. Here we are, many years later and now all and sundry can use SoundBlaster products no matter what the operating system is and Creative is still in business.
We at SciTech Agree that open source development can be both good for the community as well as for business. Which is why we support so many open projects our selves including: Open Watcom, SciTechMGL, wxUniversal, wxMGL, and the SciTech SNAP SDK project – cheers