The SGI AutoCAD Bonus Pack web page

Home of the software formerly known as the:

AutoCAD Bonus Pack

Including other interesting bits of IRIX software...

Be sure to check my Tip of the Day page...Image of Light Bulb

Frequently Asked Questions about SGI and AutoCAD:

* You'll need the Web Installation tools (tardist) to install this software.

GL Driver and Bonus Pack:

The optimized GL display driver for AutoCAD R13_c4 is included on Autodesk's AutoCAD R13 for Unix CD. There is a slight error in the AutoCAD Installation Performance Guide description of the driver installation process. The driver installation image is actually in the directory /opt/acad13/support/gldriver rather than /opt/acad13/drv/gldriver as described. The optimized GL display driver provides several advantages:

Included with the GL display driver are a number of other subsystems that serve to integrate AutoCAD into the Indigo Magic Desktop:

Download and install the latest version (3.44) of the GL Driver and Bonus Pack here. (1.4 Mb) *

* You'll need the Web Installation tools (tardist) to install this software.
[Top]

How was AutoCAD ported to the IRIX operating system?

This was a somewhat long story. Early on, in the IrisVision days (still Micro-Channel), my manager and I went up to visit Autodesk at their Sausalito, CA. campus. We ran various 3D GL demos on a PS/2 and talked about the specifications and performance. As the meeting was wrapping up, I ran a demo of a 2D CAD drawing that extruded into a 3D house (I think the demo was named house) and all of a sudden, a few of the Autodesk engineers from the "ports" group perked up. As we were packing up, one of them, Nathan, pulled me and my manager into his office and said look at this. He fired up AutoCAD on a Personal Iris workstation. It was running with the native X11 display driver, but it was mostly functional. At the time, the "ports" group was in charge of porting AutoCAD to other platforms besides MS-DOS, like Sun, HP and DEC.

At that time, I was working on a GL display driver for the IrisVision card on 32-bit MS-DOS, which we also showed them. They were rather ho-hum on that (after all, EVERY PC graphics card vendor had an ADI display driver back then), saying that we needed to get the PC-AT version out, which we were close to doing. In any event, we went home with a QIC-150 tape with a copy of the Irix AutoCAD application from Autodesk along with the Unix ADI-driver sample code. I was tasked with porting the 32-bit DOS Iris-GL display driver to Irix. That was very complicated, as under Unix, the display driver also has to handle all the window manager interactions (creation, expose, resize, icon-ify, etc.) as well as keyboard and mouse input. In the DOS world, that's all handled by the AutoCAD application itself. This was quite challenging as the GL driver had to be a mixed-model application. That means it used both IrisGL graphics functions for drawing to the graphics rendering window but it also had to handle the X11 window system calls for keyboard and mouse inputs, window resize and expose events along with Desktop Window Manager events like drag and drop, cut and paste, etc. I think Autodesk ended up releasing their R12 Irix port on the all-in-one Unix AutoCAD R12 CD and SGI made a Bonus Pack CD available for that release. In R12, AutoCAD only had 16-bit display list support, as I recall, meaning the ADI driver was somewhat limited in terms of what it could do. The biggest limitaion is that there isn't much panning/zooming in a 16 bit display list with a 1280x1024 screen, which is roughly 11-bits in size.

The hardest part was that, unlike on DOS, the Unix version of AutoCAD actually relied on the display driver to keep the application running. On DOS, AutoCAD basically has some sort of internal loop running that checks for user input, if none is present it'll run another chunk of it's internal processing code, then check for user input. On an X11 system, the only time an application gets notified of user input is when there's user input present. But if there's no user input, there's no event generated. So the display driver has to essentially stuff dummy user input into the event queue with a suitable timeout period so that it'll get periodic input. When one of these dummy input events comes in, the driver then passes that non-event back to the AutoCAD application, at which point it'll go on and do it's internal processing before returning to the display driver. The hard bit was tuning that dummy event process to make the application responsive without chewing up too much CPU time, especially on the lower end SGI systems.

We made use of these periodic time slices to perform processing inside the ADI driver. For example, we had a display list cleaning function that would go through and remove deleted entities from the display list. The way AutoCAD deletes a line segment, for example, is to draw one in the background color. Essentially this is just like one would do with white-out on a typewriter. The problem is that if a user deletes a large chuck of a drawing, the size of the display list can double, as there's one copy of every line segment in the original color and then another copy in the background color. One of the popular AutoCAD benchmarks, at the time, had a test loop that made ever increasing array copies of a rather large drawing (aksland.dwg) and then, among other actions, it would delete all these copies. Without display list cleaning, that could bring a small memory system to it's knees as it would have to start swapping to disc due to the huge memory allocations. With cleaning running in the background, as each page of display list memory was marked as all erased, it would be freed and returned to the O/S. I recall running a 16MB 486/33 PC next to a 16MB Indy R4000/33 and the Indy finished that benchmark in a few hours and on the PC, I finally had to stop the test after many days of running around the clock as I needed to use it for something else.

Later on, Autodesk released R13 on DOS and that included full 32-bit display list capability for the ADI display driver. This allowed the ADI driver to do panning and zooming using it's internal display list without having the AutoCAD application re-convert it's floating point display list to screen coordinates (REGEN). They also added the ability to embed special driver commands along with the AutoCAD commands to let the driver do things like a birdseye view and real-time panning and zooming.

There was also some discussion of having SGI (i.e. me) handle the port of AutoCAD R13-C3 to Irix. Anyway, I ended up having a temporary office in the Autodesk Sausalito building where I wrapped up the C3 port to Irix. Later, when AutoCAD R13-C4 was under development at Autodesk, I again was called in to do that port. I now had an office at the Autodesk campus, in San Rafael, CA, that I would drive to 4-5 days per week. We had a few Indigo or Indy workstations as well as a Challenge L in the lab. That Challenge L had 4 - R4400-200MHz CPUs with 2GB of RAM and a handful of 4GB SCSI drives. Using the IRIX parallel make (pmake) utility, I could rebuild the entire AutoCAD source in maybe 20 minutes. Also, with the, at the time, huge memory, I could also run a full -DEBUG build of AutoCAD in the IRIX debugger. This was something that the Autodesk ports engineers said was impossible! I made use of this feature to debug and fix some long standing bugs inside AutoCAD that the Autodesk guys said they knew about but could never debug and fix.

Later, we had a couple of contractors helping with porting project, one who handled running my builds against the extensive AutoCAD internal test suites. This is where we found and fixed many internal AutoCAD bugs, only later to be told that Autodesk didn't bother running those test cases as they always failed!. Another contractor, Bill, who was a database expert, handled all the database integration (ASE) testing with AutoCAD. That involved setting up three different database servers, getting those connected to AutoCAD and then running all those tests. Those two guys were very helpful in testing all those areas, allowing me to focus on finding and fixing the bugs they uncovered.

In the end, I was able to greatly speed up the performance of AutoCAD. One massive speedup was with the Autodesk Modelling Extension (AME) startup. The way that this extension was originally added into AutoCAD, they simply linked in the entire AME library into AutoCAD. That is a huge library and since it was statically linked, all that code had to be read in off the disk, loaded into memory and then all the initialization calls had to be run, whether the user needed AME or not. I ran into some issues with that related to the sheer number of object (.o) files that needed to be linked. For some reason, the IRIX linker had a smaller limit on the number of .o files in a .a (library) file than Solaris had. As such, I needed to find a way to reduce the number of .o files linked in at one time. Digging into the AME source tree, I saw that the code was structured such that there was the top layer code, then an intermediate layer that had the main entry points to the various sections of the AME library and finally the bottom layer of code where all the 3D modelling stuff happened. A simple fix was to split those intermediate layers off into separate libraries and then link those separate libraries into the code. That way, the application could take advantage of the new IRIX dynamic shared objects (.so files, similar to .dll in Windows). With dso's, a place holder for the code is created, but unless something in that shared object library is called, none of the code there is loaded off of the hard drive, executed or even occupies memory. That one fix, cut the startup time in half!

Another improvement I made was in the licensing. As coded by Autodesk, they had ticked on every possible option in the Elan License Manager code (elmd). I think they had host name, IP address and sysid (MAC address) selected. I changed the IRIX version to only work off of sysid, which is unique to each system. The problem with adding the first two is for systems on DHCP networks, they may get a new IP and/or host name each time they boot up. That would then cause the license manager (elmd) to fail to authenticate the previously issued license ever time the DHCP server handed out a new IP adress!

I also included full desktop support for AutoCAD. This included desktop File Type Rules to support drag and drop interactions. Likewise, there was full cut and paste support. The application could easily be run over the network, I routinely ran demos in the main SGI Demo Center while logged into my workstation at the other end of the Shoreline campus. That saved a lot of time as I didn't have to install any software or have any system access to the demo machines. All I had to do was open a console window, then rlogin to my workstation and AutoCAD popped up on the demo system with the X11 and IrisGL commands coming over the network. It was fun demoing the GL display driver and AutoCAD on a Reality Engine!

What's involved in porting and application, like AutoCAD, to Irix? That's a complicated process to say the least. Yes, AutoCAD was actually designed to be portable to different platforms from the get go. However, the devil is in the details, as they say. Porting an application involves re-compiling it on the target platform. There are compiler and linker differences as well as differences in Unix system calls that vary between Unix implementations such as Solaris and Irix. One of the biggest issues was that the SGI C-compiler was very strict in adhering to the ANSI-C specification. The AutoCAD code base, being from the early '80s, was written in varying flavors of the C (and later C++) language over the years. So I had to fix many C-language related issues in the code, that really had nothing to do with Irix or the Mips CPU architecture. But Autodesk would always see those fixes as SGI issues. Another issue had to do with memory segmentation violations (Segv - core dumps) which came from some of the old AutoCAD code that did somewhat naughty things. One example was some String library code that was used in dialog boxes to limit string lengths for button labels. That code could copy, for example, 5 bytes (ASCII characters) into a 4 byte array. Somehow on DOS, that was OK but I don't care what platform you are on, that's wrong. But again, this was an SGI problem. This is just a few of the issues that were encountered, but all these fixes had to be enclosed in #ifdef SGI ... #endif because I could never win any arguments that the original code was bad. I later found out that much of this code had been written by one of the founders of Autodesk and he was still around and involved in day to day operations. Nobody wanted to stand up to him to critique his code!

In the end, I think there were two major things that doomed AutoCAD on IRIX. The biggest one was that it was included on the Unix CD, along with Sun, HP, and DEC. However, when Autodesk sold a Unix copy, the salesman would usually mark that down as the Sun/Solaris version, unless it was specifically purchased for SGI/Irix. Related to that was the trade-in program Autodesk ran. Anyone could trade in any old copy of AutoCAD on the latest version for something like $485. We knew of many instances of dusty old DOS copies being traded in to get the Unix version to run on the SGI workstations and servers at customer sites. Those upgrade sales were not tracked as far as what platform they were for. As such, Autodesk would look and see that the SGI version wasn't very popular per their records, yet we knew it was being used quite extensively. But the bigger picture was that Autodesk decided to go 100% with Windows and drop all the other platforms. In their early days, their big claim to fame was AutoCAD could be run on almost anything. We did work with them on the Inventor application, but then when Microsoft picked up the OpenGL and Inventor components, I think that fell by the wayside as well.

In all, I logged over 30,000 miles of driving to/from Marin county over a few years. It was a 65 mile trip each way.

AutoCAD on XFS File Systems:

While AutoCAD itself runs very well on the new XFS file system, you may run into some difficulty when trying to install AutoCAD on large file systems, especially ones over 2 GB in size. Since the installation program is a 32-bit executable, it sees numbers over 2 GB (2^31) as negative, and thus improperly determines that there is insufficient disk space to complete the installation. There is an easy work-around for this problem in the 'ainstall' program:

ainstall work-around:

Instead of using the selection:

use the selection:

and then de-select one option in the Custom Install dialog box. For example, if you don't require the External Database Access (ASE) feature, click on the option button to its left to remove it from the installation list and select OK.

[Top]

AutoCAD License Server:

Autodesk uses the Elan License Manager (ELM) for all Unix platforms. ELM is a network licensing system that provides floating AutoCAD licenses. It is based on a client-server architecture, in which one (or more) license servers (running the ELM license daemon; ad_elmd) respond to license requests from one (or more) clients via a list specified by the ACADSERVER environment variable. Even in the trivial case of a single workstation, a license server and client process (AutoCAD in this case) are needed. Also, you should note that the ELM licenses work transparently across all the supported Unix platforms.

Here is an installable package to simplify the process of installing and configuring the R13 license server*. With the click of the mouse button, you'll install the license daemon, create all needed directories, network startup scripts, and even run the license administration program to generate your server ID to send you your dealer. It even creates a chkconfig flag for ad_elmd to allow you to easily turn the license daemon on and off easily.

Did you know that the R13 license server can be used with AutoCAD R12? You'll need to do two things to get this to work.

* You'll need the Web Installation tools (tardist) to install this software.

[Top]

Collaborative Engineering:

One of the primary benefits of AutoCAD on SGI is the ability to integrate the efforts of multiple people on a project with a variety of collaborative tools. This collaboration is available in many forms and you may find you'll need more than one technique depending on your situation at hand. These collaboration techniques range from live multi-user shared application sessions (X/TeleScreen) to live audio/video teleconferencing (InPerson) to store-and-forward drawing markup (Annotator) to the latest Web-based paradigm (OutBox and VRML) and that old standby; facsimile.

Below I'll relate my experiences with each of these technologies:

National Information Systems has a product called X/TeleScreen that allows you to share any X Window application, including AutoCAD. This allows you to have a true multi-user shared AutoCAD session.

Here's how I set up xtls to work with AutoCAD:

Set up the XTLSDIR environment variable and run the xtls program;

Due to it lower bandwidth requirements I recommend that you use the X/Motif display driver with XTLS. The GL driver will work between two (or more) SGI workstations, but unless you have a good network connection, you may find it to be slower in interactive operations, such as dragging, etc. I would recommend at least a single B-channel ISDN network connection for XTLS.

I have even tried a shared session to a PC running Windows and the Hummingbird eXceed/W X Window server.

Be sure to set up the eXceed server to provide backing store when requested.

If you are working with 3D AutoCAD models, you may also want to look into SGI's Annotator and InPerson products. Both are available from the SGI_TOOLS menu in AutoCAD under the Collaboration sub-menu.

Finally, you could also look into using the Mind Share OutBox web server that comes on all SGI systems. By exporting a VRML model from AutoCAD and placing it in your ~/public_html directory, your model is available for review over the Web.

[Top]

Print To Fax:

The SGI Tools menu includes a FAX item under the Collaboration section. This feature requires a few separate software packages. First, you'll nee the PostScript Utilities and the HylaFAX telecommunications software (below). In addition, you'll need to have the Practical Extraction and Report Language (PERL) installed. On IRIX 5.x, this is an optional package that should be included on your IRIX execution CD. In IRIX 6.x, PERL is installed by default.

Here's a screen shot of the Print-to-FAX feature in operation.

* You'll need the Web Installation tools (tardist) to install this software.
[Top]

Third Party Solutions:

A number of interesting third-party applications exist for AutoCAD on SGI. Here's some that I know about:

If you run across any other interesting apps, please let me know via e-mail.
[Top]

CAD Resources:

If you run across any other interesting resources, please let me know via e-mail.
[Top]

Send email to me. ===>> picture of the Author

[Last updated: 25.September.2026 ]

Visitor # since 14.SEP.2003