Built to solve complex simultaneous uses of CPU and GPU for animation, Fabric Engine has the potential to solve knotty issues in a wide variety of disciplines.
By Kathleen Maher
It’s not much of a secret that while processors, CPUs and GPUs alike have undergone tremendous architectural changes over the past 10 years, software has a ways to go before it really takes advantage of the hardware. The basic problem is writing software that knows when to call on the GPU’s processors and when to call on the CPU’s processors and how to get the most out of all the resources. The APIs to reach the processors have been a long time evolving. Tools such as the open source API OpenCL gives developers a way to access the processors across CPUs and GPUs, but it’s not easy for developers to use. The challenges facing developers has only multiplied as applications are being developed to take advantage of the enormous potential resources available through the cloud.
A start up in Montreal might just very well have the answer to a problem that’s been plaguing developers ever since processors ran afoul of the laws of physics and had to start multiplying to get the job done. Fabric Engine was started 18 months ago by a small team of people from Softimage including Philip Taylor, VP of Engineering Peter Zion, R&D Engineer Helge Mathee, and Core Engineer Jerome Couture-Gagnon. Paul Doyle, also from Softimage and Autodesk is the CEO. Fabric’s engineers are the people who developed the ICE (Interactive Creative Environment) engine for Softimage XSI. Softimage used ICE as an internal development tool and also offered it to third party developers to create powerful custom tools for Softimage. Softimage’s ICE was used to create real time preview in Softimage and it was an incentive for Autodesk to buy the company. In a phone interview, Doyle says the engineers working on ICE always knew they had something really great, but the code they developed was ultimately limited because it had to be “shoehorned into a legacy, single-threaded software architecture.”
The ICE engine was a Ferrari engine rarin’ to go, but it was stuck in an older car that had been to the repair shop a few too many times. Still it did wonders for Softimage.
When the former Softimage engineers left Autodesk they planned to build 3D content creation tools and along the way, they built their own development environment, which has become Fabric Engine. “We set out to build a 3D application platform that would massively outperform the incumbents,” says Doyle. What they actually wound up doing goes beyond that early mission statement. “We’ve abstracted beyond that,” says Doyle, who says the team came to believe the market really doesn’t want another monolithic 3D tool. The company says that in addition to speeding up 3D graphics and animation, the technology also accelerates video processing, simulation, web analytics, complex rendering, and loading large binary files. As they began working the Fabric team realized they could create something universal that enables advanced applications to run in browsers by taking advantage of multiple processors, be they GPU or CPU, to speed-up performance.
The Fabric Engine team has abstracted all the hard parts of developing for modern processors including explicit management of threads and memory. Application development can be performed using standard web development tools and the resulting applications run anywhere, including on the browser. They are taking advantage of standard web technologies including HTML5, JavaScript, and CSS. But they’ve also designed Fabric to be extensible so that it can support custom libraries and file types. The high performance parts of the application are written using a performance-specific extension to JavaScript, called KL (Kernel Language). “This extension system means that we don’t require developers to reinvent the wheel, and it turns the browser into a powerful application platform,” says Doyle.
Fabric uses the LLVM compiler, which allows for dynamic compilation of applications and can massively improve iteration times for developers. There are two approaches to concurrency: the dependency graph and a MapReduce implementation. The Extension platform already supports a variety of formats and custom libraries, including support for OpenGL and OpenCL.
When they first got started the team went after the kinds of projects they were already familiar with: 3D modeling and animation. They were helping their customers build solutions for specific problems. Fabric Engine lets people build their own applications across all fields of visual computing. To prove that point, they have built a number of demo tools that handle some of the main challenges they see within content creation pipelines. For example, they have built a browser-based crowd simulation tool that can run with much more complex characters and much faster than the tools currently in use by the studios. In another instance, says Doyle, they’ve built a character animation tool. He mentions that one studio they’re working with had been struggling with a highly complex character and they could only run animations at 2 or 3 frames per second. Fabric Engine has written a tool enabling the same character to run at 20 fps so that an animator can really see what the character is doing. “The best thing by far is to give them the performance they’re after,” says Doyle of his customers at the studios. “With Fabric we’re building in weeks what used to take months to build.” This is because Fabric Engine has an embedded compiler, there’s no compile wait time. “Our iteration time is really really fast,” says Doyle. He says coders can write it, see it run, then write some more like, well… a web developer using JavaScript.
Fabric Engine has adopted the LLVM compiler developed at the University of Illinois for multi-processor architectures. Key to Fabric Engine’s ability to take advantage of multiple processors is the dependency graph, which organizes the execution of work. Each node represents work to be done. Dependencies determine the execution order and parallel sections of the graph are executed simultaneously. When taking advantage of the CPU, the process can be nearly automatic. Taking advantage of GPU acceleration requires more intervention work defining dependencies, a requirement that GPU developers are very familiar with. “The dependency graph is awesome for 3D,” says Doyle. Fabric Engine does a lot of the abstraction, but on the GPU side, you have to understand what the GPU is doing,” he says.
The wider world
Even though 3D remains one of the showcase challenges for parallel processing, the Fabric Engine team sees broad applicability. In fact, Doyle worries that people won’t understand how useful the Fabric Engine architecture can be for a broad range of jobs including data mining, image/video editing, etc. It can be used to create an application that tackles any kind of problem that lends itself to parallel computing.
“One of the first things we did is to build a very rich extension architecture,” he says. To demonstrate, they have built an extension for the Bullet Physics engine that enables it to run in a browser. They built a tool for the Alembic exchange framework that enables different groups to collaborate on data. Doyle notes that the phone started ringing when they unveiled the Alembic tool because content creators were excited by the idea of sharing content in a browser and working on it interactively from different machines.
Point clouds are a problem that lends itself to Fabric’s approach and to prove the point, Fabric developed an extension built to support a Lidar library allowing people to work with huge point clouds interactively within a browser. They’ve also built a demo that shows how Fabric Engine can be used to visualize medical data, using a custom volumetric renderer. The team is busily working on creating more demos to inspire the development community. All of the demo work that Fabric releases is open source, so developers are free to take that code and use it themselves. For an example of the kinds of programs Fabric Engine can develop, see the company’s demo site http://demos.fabric-engine.com/. For video examples, check out http://vimeo.com/groups/fabric/videos.
The proposition
As a determinedly community-focused company, Fabric is giving away their development tools and Fabric Engine is free when running in the browser. However, if you want to start working with your application on servers, Fabric Engine will charge money on the basis of the resources you require—much like the Amazon model. Doyle sees applications such as Fluid Dynamics calculations, FEA analysis, rendering, and so on, as problems that are well suited for the cloud.
It’s a modern approach to software, believes Doyle, who admits that he and his team had to get used to the idea themselves. First of all there’s the free part that is available on the client “As a sales person, it just killed me to give the product away for free. But when there’s a cost of adoption, there’s a lot of additional friction,” he says. Then, when you start talking about Fabric Engine running in a browser, says Doyle, “it brings up certain preconceptions that people have about browser based technology. But as we started working we realized that the browser is not the barrier we thought it was.” Doyle talks about early customers who are taking advantage of the browser in collaborative environments. For instance, he says, a director might want to look at a character and see how it is coming along. Maybe he will want to interact with that character but he is not going to want to open it in Maya. But, using the same sort of applications Fabric is working on with the studios, “you could send a director a URL and he could go to that URL and see the character and interact with it.”
“Our goal isn’t to replace Maya. Monolithic applications are the way the market started, now it’s more a matter of niche applications,” says Doyle. There won’t be new Fabric data formats, he says. Rather, it’s critical that Fabric can play nicely with existing data types and avoid introducing more complexity to pipelines. In fact, that’s where their Alembic extension is coming in handy. “The animation review tool that we built shows how powerful Alembic can be, especially when everyone is working from a single data source.”
Developing tools for multi-processors is an arms race. OpenCL provides the raw materials and now developers are figuring how to build on it to enable better application development. Because Fabric is looking at professional grade applications for their technology, they’re using the full OpenGL 4.0 API rather than using WebGL. Doyle says that WebGL is great for browsers, but it’s a subset of the complete OpenGL API and he says their clients often need some of the capabilities that have not been included in the early iterations of WebGL. Fabric is designed to allow developers to take advantage of CPUs and GPUs and scale. That’s been the real prize in this race.
What do we think?
It all comes down to apps, doesn’t it? The inflection point of today is the challenge of point products that are very very good at one thing compared to big complicated products that can do a whole lot of things. Ironically, most people working in big horizontal products, such as Maya, AutoCAD, Photoshop, etc. are using a subset of the tools’ capabilities. It’s the 20/80 rule in action: 80% of the customers use 20% of the product… just not the same 20%. Apps appeal to people who need to accomplish a task, not learn a program. Fabric Engine connects the performance of compiled applications to the ease of using dynamic languages to develop those applications, so people can start handling a greater number of complex tasks faster. Add the cloud and you add collaboration, sharing, networking, and the ability to speed work with infinite processing.
Fabric has cracked open an opportunity for developers but Doyle is right to worry about getting the message out to new customers. He has to preach the Fabric Engine gospel to a world that’s buffeted by security fears and performance doubts and he has to reach new customers in their bunkers: researchers at universities, financial wonks in New York redoubts, hospitals, CAD developers in large enterprises, all of whom have different ideas about how their jobs should be done. Now the hard part starts.
