SciTech Software, Inc. today announced that it is has released SciTech SNAP Graphics for Linux 2.0 – The Simple Driver Solution. This release is based on SciTech’s SNAP (System Neutral Access Protocol) architecture and targets the Linux enterprise markets with a host of features designed to reduce the total cost of ownership associated with maintaining Linux on corporate enterprises. Read more for the rest of the press release.“This release of SciTech SNAP graphics for Linux feels like a home coming for me,” said Kendall Bennett, SciTech CEO and Founder. “As some may recall the original release of SciTech Nucleus technology, now known as SciTech SNAP was developed and released in 1998 to offer robust graphics support to early versions of Linux.”
SciTech SNAP Graphics for Linux 2.0 supports both X11, and Qt on virtually all graphics chipsets in one easy to deploy package. SciTech SNAP Graphics for Linux 2.0 delivers advanced 2D acceleration for business users, Plug-N-Play support, and supports all versions of from Xfree86 4.0.2 to 4.3.0 with consistent device support, making enterprise wide deployment and maintenance a real snap!
“Enterprise customers are the real winners here today, with the release of SciTech SNAP Graphics for Linux support costs associated with Linux deployments and maintenance can be dramatically reduced,” said Andrew Bloo, SciTech’s Director of Sales and Marketing. “For the first time enterprise customers looking to deploy a Linux solution can do so with out the worry of unsupported or odd case graphics hardware adding complexity to OS images being deployed across the enterprise.”
SciTech SNAP Graphics for Linux allows for a single device driver solution to be easily deployed across an entire enterprise. This single solution approach means that qualifying an image for deployment now takes less time, requires fewer steps and can be updated much faster. In addition to the many upfront advantages offered by SciTech SNAP Graphics for Linux, other long-term advantages can also be realized. Benefits such as; fully supported device drivers, tested and certified driver binaries, wide Linux distribution compatibility, and full access to qualified tech support if the situation ever arises. As new hardware is added and or updated SciTech SNAP Graphics automatically detects the change and updates the system to take advantage of the capabilities found in the new hardware. More importantly if a particular graphics card fails it can be easily replaced with another supported graphics card with out the need to reconfigure or update Xfree86.
The SciTech SNAP SDK is also available from the SciTech website under a dual-license structure (Proprietary and GPL). For more information on the SciTech SNAP SDK please see our website (www.scitechsoft.com) which contains the complete SDK source code and documentation.
Will there be a free non-sexy version to parallel the OS/2 scitech drivers? The OS/2 basic scitech drivers are free for Warp 4, but you must purchase the drivers with bells & whistles.
…for the DEC Alpha port.
As a clarification, the IBM edition is not actually free from SciTech – ($36.95 for the enterprise version). However, IBM has Licensed a special version of SciTech SNAP Graphics for OS/2 on behalf of its customers and as such may provide it tat what ever cost they deem appropriate.
SciTech SNAP Graphics for Linux in enterprise form is being offered at $19.95 currently.
Thanks;) we are currently working on alternate processor support (PPC, DEC Alpha,…) and hope to be in a position to support your needs in the future.
It may interest professionals, but for the dead-end user, it lacks two things : support for Xv and for GL extension (no 3D).
This is as important to me as IGP support, does anyone know when SNAP will support this extension? Also, does anyone know if the new X cursors in 4.3 are supported by snap? (I’ll guess that they are since it’s only a driver..)
The XCursors in XFree86 4.3 work fine with SNAP Graphics. There have also been positive reports about XRandR working (check out the LinuxFormat review).
Here is a link to a copy of the Linux Format review:
http://www.scitechsoft.com/pdf/linux_format_review.pdf
in its current form it is basically useless to me. If you guys come out with 3D support for it I would be willing to pay 3 times the amount you’re currently charging for it. Assuming the quality isnt worse than what the manufacturer provides (in my case nvidia). I’m thinking most people would be willing to pay you guys (SciTech) at least double of what you’re asking for 3D support.
First, congrats on the release.
Now that you’ve released the thing, you can start working on 3d support right?
Well if not, we can still discuss it ;-). So here is are some questions:
Also, in which part of the driver would OpenGL be implemented? Would the Hardware driver have some sort of standard 3D interface, that OS 3D graphics libraries (like OpenGL, D3D, glide, MGL, etc.) would use to implement those libraries? Or would these libraries be implemented in the Hardware part of the driver, with the OS part wrapping to that?
It seems like having some standard interface to the hardware driver would be less work for the Sci-tech team, at least per driver. And maybe to a Hardware manufacturer, who develops a driver using a licensed DDK (to keep their proprietary stuff secret). This way, the Open source community, or proprietary OS vendors, like Apple and Zeta, could write the OpenGL, D3D, etc parts of the driver, using the GPL or licensed versions of the SDK.
Also, would it be possible to add D3D to the drivers as well as OpenGL, in OSs other than windows?
There are currently wrappers that wrap D3D calls to OpenGL calls in non-Windows OSs, and I think that it would be possible to implement D3D drivers even in non-windows platforms. But what about licensing issues? Are there any licensing or technical reasons why it can’t be done (or even scope reasons)?
I’m just curious.
I am no expert in this field, but I thought I’d take a stab 🙂
If the Hardware part of the driver where to have some kind of API neutral interface, then I guess some kind of hardware neutral interface would need to be devised that would allow hardware calls to be exposed, without exposing any vendor specific secrets or tricks that they would not want to be public knowledge. Then the APIs, in the OS part of the driver (OpenGL, D3D, MGL, etc.) would be wrapped to that neutral hardware layer.
What do you think?
By the way, getting D3D into the drivers is more for future development and easy portability. I wouldn’t think it would be developed with binary compatability with current windows programs. Wine could certainly take advantage of it however.
Most of your ideas are correct, and in fact the current 3D interface API’s we have already developed in SNAP are based around the concept of a small, low level interface to the most common types of 3D hardware. For most hardware prior to DX8/9, this interface will be adequate, and includes functions to render triangles with vertices in a format useable by Mesa and another format useable by Direct3D drivers.
DX8/9 drivers however get complicated by the geometry pipelines, so the plan for this is to simply expose a mini OpenGL driver API from the hardware components.
Anyway it is very early days yet for the 3D support, but a lot of the design work has already been done, we just need to get the time to implement it 😉
I agree with cr@zy: as it stands this isn’t compelling enough for me to actually spend money, but I would happily pay twice as much (not three times like cr@zy suggests, I’m a cheapskate – but I’ll go as high as twice) for accelerated 3D support for new cards – ie, those that still don’t work with standard XFree.