Sunday, August 10, 2014

What to do when your company runs out of money


With the recent Crytek news, and many, many similar stories out of the tech and games industries in the past I was urged by some folks to give my counter example of how to plan for the worst...

I started my career over 10 years ago at Ageia Technologies, a crazy little start up with a crazy little idea of building a chip designed to accelerate physics for video games (and a few other industries as well). The idea never caught on very widely, and the advent of GPGPU would have been the final nail in our coffin if it wasn't for NVIDIA acquiring us in early 2008.

At some point we started to all get concerned about running out of money, and while my details might be a bit fuzzy I want to say about 9 months before acquisition our management held a company meeting where they laid out the situation to us and presented their plan for keeping us from all jumping ship immediately. They set aside like 3 months of salary for every employee and drew a line in the sand. If we didn't get acquired or somehow start turning a profit by a specific date everyone would be laid off and we would get the 3 months severance. If we did pull through one way or another, that 3 months of cash would be given to us in the form of a bonus, which is ultimately what happened.

We still did have a round of layoffs, and some of those folks actually ended up at NVIDIA before acquisition, but what this plan really did is it took the risk out of being loyal to the company. We knew we would keep getting pay checks all the way up to the last day, and if we got laid off we would get quite a nice severance package that would carry us to our next gig.

So I don't want to talk specifically about Crytek and what is going on there, I don't really know their situation, but I know Ageia was really caught off guard by Havok FX and later Cuda hitting the scene on top of it generally being a tough sell getting people to buy yet another board for their computer, but our management cared enough for the people, and understood their value to come up with a plan to protect the people that built the company.

Saturday, June 28, 2014

OpenGL 4.4 and beyond on Android

Things are changing so rapidly in mobile hardware that we are starting to enter an era where no longer will there a difference in feature sets or capabilities between what your phone can do, and what a high end PC can do. The difference will simply be how much power the chips are allowed to consume.

Now, I don't want to sound like I am just blindly pushing our own chips here, but I believe Tegra K1 is an early glimpse of things to come, and probably not just from us, I expect the rest of the industry to follow eventually until developers can safely assume a relatively consistent feature set from PC down to mobile. K1 is just the first example, because the GPU core in it is Kepler. And that is not just some marketing trickery, its actually same microarchitecture that powers crazy things like the GTX780. Over the last few years a lot of blood, sweat and tears went into making this possible. And while due to size, power and thermal constraints it only has 192 "cores" instead of 2304, it still smokes the competition perf wise, but more importantly its just in a completely different league when it comes to features as it is capable of full desktop class OpenGL 4.4, including geometry shaders, tessellation, compute, etc, plus extensions enabling things like bindless!

Friday, June 27, 2014

Tegra Glass Fracture Demo

At GTC a few years back I was tasked with taking a really cool GPU rigid-body + fracturing demo and making it look pretty for the keynote (something I always seem to get suckered into every year). I decided to trick it out with some fancy glass rendering, caustics, etc. Some of the techniques were invented just for the demo (how I came up with a way of using a geometry shader to do caustics probably involves a severe blow to the head I imagine). This demo ran on a high end PC with a GTX 690 in it.

After that demo I started fiddling around with the idea of bringing it to Tegra. I actually rewrote everything with a keen eye on performance. Starting with Tegra 3 I was able to get the refraction/reflection actually working at around 30fps. Tegra 4 allowed me to hit 60fps and turn the shadows on (using a little mip-chain hack to achieve the penumbra). K1 though allows me to blow all that out of the water and bring the full experience of the PC version to mobile using desktop class OpenGL 4.4 feature set. And Nathan Reed took my crazy geometry shader for doing the caustics and added the even crazier use of the tessellator to make the caustics truly mind blowing and better than the original PC version.

Anyways, the Tegra version of this demo didn't get a lot of attention, but we have shown it at our booth at a few trade shows, so figured it was time for the interwebs to get a taste.

Continue reading for high resolution screenshots...

Friday, June 20, 2014

Screen Space Surface Generation circa 2005

Early in 2005 at Ageia we were doing a lot of research into fluid dynamics using smoothed particle hydrodynamics. Because at the time we had not yet gotten chips back from the fab all of our test cases would be run in SW and then run marching cubes over them to generate a surface. We would then cache the output of marching cubes to disk and then stream it back later in real-time to give people an idea of what we thought we could do. The assumption was at the time that our hardware could generate these 3rd surfaces in real-time for tens of thousands of particles. Turns out, we could do SPH rather well, but marching cubes, not so much.

When working on a cheesy little demo with John Ratcliff called "ageia carwash" I decided to try an idea that was bouncing around my head which was to render the particles as sprite that looked like the normals of a sphere, blur it a bit, then discard the post-blurred alpha below a particular threshold, apply some lighting and fake refraction in an attempt to create a GPU friendly real-time liquid surface. Personally I thought this first attempt was pretty good, but I couldn't convince everyone higher up the food chain that it was a reasonable compromise, but I was just a kid bad then and didn't push for the idea hard enough I guess :/

Luckily Simon Green independently had the same idea at NVIDIA and has over time turned it into the goto method for rendering particle based liquids in real-time.

Also around this time Matthias Müller, Simon Schirm and Stephan Duthaler had another novel technique called Screen Space Meshes (published in 2007, but I think they had this working much earlier than that), which did marching squares in 2D and then projected that back out into 3D. It was fast enough for real-time and could be run efficiently on our own hardware so thats the direction we went for a while, even ended up in a few games I think. But of course, eventually we ended up back at Simon's solution by the time acquisition came around.

Anyways, this video was captured early in 2005 before we even added lighting in the demo and even featured our old logo.

Enabling color output with ccache+clang

Quick tip here...

Typically when you compile with clang you get some pretty sexy color coded error messages (as seen above). This is great and all, but if you are running through ccache (which is awesome btw), then you will notice that you lose the hot color coding, which will probably make you sad. The problem isn't ccache stripping out the color coding exactly, its that clang is detecting that its not printing to a terminal that supports color (because its going through the ccache process which knows nothing about color).

The fix is quite easy though, just pass "-fcolor-diagnostics" on the command-line to clang like so...
$(CCACHE) $(CLANG) -fcolor-diagnostics
...but what if you want to run your build through some sort of automated build system that then forwards the log to people via email or pipe it through some other system that doesn't understand color? Well I got a solution for that as well, just have your makefile check for color!
COLOR_DIAGNOSTICS = $(shell if [ `tput colors` -ge 8 ]; then echo -fcolor-diagnostics; fi)
$(CCACHE) $(CLANG) $(COLOR_DIAGNOSTICS)
In this case I check for a terminal that supports at least 8 colors.