I have been interested in learning OpenGL ever since I heard about it. I had to make the terrible choice last year of choosing whether to learn OpenGL or Core Audio because it would be complete idiocy to try to learn both at the same time. Since Chris Adamson didn’t write a book on OpenGL, I made the choice last year to learn Core Audio. It was the first programming book I read cover to cover and I got to spend a day with him in Boston at CocoaConf doing Core Audio. That was an amazing experience, but it’s time to move on to the next thing.
I started to learn OpenGL ES in earnest back in March. I had a few books and I have primarily been reading the same materials over and over again hoping that my brain translates them.One accepted way learn OpenGL ES is to work on the GPUImage framework. There is a great blog post about how to write a custom shader here.
I decided a good way to learn OpenGL ES was to do a talk on GPUImage. Many of the tutorials I have seen on the framework basically just tell you how to plug it into your project and use the built-in filters. I wanted to do a talk about how the framework actually works and how to write your own filters. The creator of the framework, Brad Larson, lives in town. He has been extraordinarily generous with his time and knowledge about OpenGL ES. I pitched this talk and got it accepted at two different conference: CocoaConf Columbus and 360|iDev in Denver. Both of these conferences are in August. I pitched these talks around May. I figured that would be a decent amount of time to figure all this stuff out.
Then, like everyone else, I got slammed by WWDC.
I know that I don’t have to talk about Metal. It’s only been publicly announced for a few months and it only works on a handful of devices. There was no reason I couldn’t just keep my original talk topic. No reason except I had some existential questions I wanted answered.
Every time I heard about GPUImage I heard it was faster than Core Image because it was programmed on the GPU. What does that mean? All of my research on OpenGL ES says to push as much work off the GPU as possible, but they never specify what work the GPU is doing. I read a whole book on OpenGL ES without having any real clue what work is being done on the GPU.
I really wanted to do a talk on how to optimize OpenGL ES. I also wanted to explore what exactly it was that Metal was doing that was so much better than OpenGL ES. I heard a lot of bemoaning about how slow and inefficient OpenGL ES was, but after talking to Brad about it for a little while, I wondered if the mob was wrong.
I am doing my first talk on Metal three weeks from today. I have exactly one slide from my talk done as of 1:00 this afternoon, but I am in the process of gathering the answers to my questions.
One resource I can’t recommend more highly is the video tutorial series done by Ray Wenderlich. I had a list of questions in my head that I now have answers to because of his series on OpenGL ES. I am a quarter of the way through it and subscribing to his video tutorials is the best money I have spent on tech resources this year. It is my hope that one day he will produce a 3D graphics programming, hopefully after I know it well enough to be able to contribute to it!
So, I am going to take some time, but not too much, cataloging my work on this talk. I also have a debugging talk to complete in three weeks along with some obligations for my unnamed project. I think this is doable if I don’t have a panic attack or get distracted by squirrels.I am planning to include links in my blog to any resource I have found to be particularly useful.
My goal before going to CocoaConf is to have a working Metal application with a few of the GPUImage filters translated from the OpenGL Shading Language to the Metal Shading Language. I would like to show the performance differences between GPUImage and Metal using the same project. I would also like to be able to intelligently explain GPU programming to people who are coming into this without knowing anything about OpenGL.
Three weeks. Two talks. Git ‘er done!