If you wanna be sincere about this, I think you should have a section dedicated to Gezira, and not only the more traditional imperative styles of graphics programming. The style of GUI that came out of PARC is no longer "modern", and has problems with modern development styles (e.g, single-threaded global event loops makes writing concurrent programs difficult).
If you're not familiar with it, Gezira is a full vector graphics API, including compositing, written in less than a thousand lines of Nile - a small flow-based programming language. It does its magic by treating quadratic bezier curves as the main primitive, where the author has developed an algorithm to calculate the pixel coverage of a given bezier, with anti-aliasing.. Because most operations can be treated independently, it lends itself nicely to concurrency - each operation in a data flow can run independently, and many operations can be parallelised if given sufficient inputs.
Gezira/Nile was created by Dan Amelang while working for VPRI (the research institute headed by Alan Kay). A demo of it in action can be seen here: (http://tinlizzie.org/~bert/Gezira.ogv), where it's worth noting that the entire Editor UI in this example (after first 5 seconds), including font rendering, is written with Gezira itself.
How is Gezira relevant to the topic of this book? The title says the book is about "graphics programming", but from the description it seems clear that it is primarily about GPU programming, and pixel shaders in particular.
I'm not familiar with Gezira, but from what little info I could find it seems to compile to C code and runs entirely on the CPU. They say an OpenCL backend is planned for the future but not there yet. I agree it might be a good environment to learn about graphics concepts in general, but it wouldnt really teach anything about the details of GPU programming.
Wow, that looks really interesting. I've only taken a brief look, but I'll be sure to take a more in depth look at it this afternoon/evening when I get a chance.
I've been very surprised and pleased by the accessibility of graphics programming and the helpfulness of a lot of the communities built around it. It's been a lot of fun to learn and play around with. (Plus I get to use C and C++, which the masochist in me really enjoys for some perverse reason).
Edit: I actually couldn't help myself and ended up taking a look anyways. That project is incredible at least from the small amount I've seen so far. I don't think it's an exaggeration to say the project you linked to is the coolest web-app I've seen.
Add a call to action. I got to the bottom and was like "Where do I put my email?" I want to read this, but I worry I will forget about by the time it is done.
Possibly naive question: will there ever be a C for GPUs? That is, a minimal, portable "assembly language"? Or will there continue to be heterogeneity?
I think that's what OpenCL and such are trying to be, but I know it is nascent and has competitors. I don't know enough about the hardware to tell if languages will eventually consolidated like C (with basically all higher level languages built on top of C), or if there is some fundamental heterogeneity or evolutionary divergence that means there can't be one language.
There's been a number of attempts to create hardware agonostic languages for GPGPU programming - examples are Brook (http://graphics.stanford.edu/projects/brookgpu/lang.html), and Harlan (https://github.com/eholk/harlan/wiki/Language-Overview), although there are many others. None seem to take off, as with most languages - and OpenCL seems like it's here to stay (perhaps because it requires little new learning on the part of C programmers, as it is just C with a few restrictions and a few additions). I think OpenCL will be the "assembly" of GPUs for a long time to come, and will generally be the primary target of higher level languages aiming to make use of the GPU.
PTX is certainly more suitable as an intermediate representation than OpenCL's dialect of C, but PTX obviously doesn't and never will fulfill the requirements of being the low-level portable target for high-level languages.
NVidia's early-mover advantage is significant, but software tied to only their hardware will never be able to achieve the kind of status that the netlib stuff has. The only question is whether the gold-standard numerical libraries a decade from now will have multiple backends, or a single non-CUDA backend.
I never said they weren't. But they can't expect to automatically continue with that success while staying as closed and proprietary as CUDA has been so far. Their hardware is not drastically better than that of their competitors, and they are subject to serious competition (unlike Intel with their CPUs). OpenCL is here to stay with a market far broader than just AMD GPUs, so it's pretty much inevitable that it will take over as the dominant standard unless it's developed as badly as OpenGL was in the early 2000s. If Microsoft ever ships a CPU-backed OpenCL runtime as part of Windows, it'll be all over for CUDA.
The NVIDIA hardware is not necessarily better, but the toolchain is unmatched. Race checker, memory checker, top-notch debugger and profiler, visual disassembly graph, makes it a very smooth experience.
AMD can only compete through HSA and non-standard OpenCL extensions, and only companies whose hardware originates from AMD GPUs are in HSA.
OpenCL suffers from being fragmented and with very fuzzy mapping to real hardware. Even OpenGL compute shaders looks more interesting to me with their vast texture format access, and the fact that OpenCL multiple queues don't deliver in practice.
There is both SPIR and HSAIL in competition with PTX, NVIDIA can rejoice.
I had concentrated on graphics when I studied computer science in college. That was 10 years ago and shaders weren't in common usage. To this day, I can still derive a rotation matrix from basic principles.
Yet learning GLSL has been surprisingly difficult. Either the resources available are the Khronos Group's shitty documentation, or tutorials of a different yet equal shittiness that go no further than spinning cubes.
I am a little confused, it seems like you are proposing an interactive CUDA guide, but there is no mention of CUDA at all. Having spent a lot of time in graphics, I feel like better test environments for GPU programming will go a long way towards higher market adoption, it's a nightmare debugging sometimes
Shaders have there own stripped down C language to run on parts of the graphics pipeline as apposed to CUDA which is a much richer framework with a lot more control (and knowledge) of the GPU it's running on.
CUDA is an NVidia only GPU framework.
Shaders are used in conjunction with graphics frameworks like OpenGL, DirectX(?) and WebGL.
The interactive nature is great. Normally shaders are a just a big string or file that gets submitted to the graphics card driver to get compiled and run on the GPU.
I posted this, but I didn't create it. I came across it while learning OpenGL and thought it was an interesting way to learn more about how pixel (fragment) shaders worked.
That said, I definitely agree that an interactive CUDA guide would be useful! And although my experience with graphics programming is limited to the past few weeks I've certainly experienced some of what you mentioned with regards to debugging. One of the most frustrating things starting out with OpenGL was how forgetting a specific function call would cause nothing to render at all with no hint as to what was going wrong.
If you're looking for a platform, I STRONGLY encourage you to look at either OpenDSA or Runestone, two open source interactive textbook platforms. I've been hacking on the latter this summer, porting it over to Runestone for a course I'm teaching (on Computational Thinking) (https://github.com/RealTimeWeb/runestone-flask is my public facing copy to give you an idea, but it's not a full copy of my port).
I'm very familiar with the development teams for both these platforms, and they're both very friendly and desirous of collaborations!
Great idea! AFAIK, the only "serious" literature we have on the subject is the GPU Gems series, although it's pretty outdated now and I suspect a lot of other great resources have emerged since my time.
I'll take this opportunity for a shameless plug of one of my articles [1] with some musings that may be relevant and/or interesting to read and know.
Wow great article. I learned about the difference between Ambient Occlusion rendering techniques: Screen Space Ambien Occlusion (SSAO) and Horizon-Based Ambient Occlusion (HBAO).
This is very cool and I hope to see it when it's complete.
BTW, have you thought of making the values in the code samples scrubbable? (e.g. at 4:20 in this Bret Victor video http://vimeo.com/36579366). I think that that change would really aid in "feeling" the behavior of the algorithms.
Great idea for a book. I am all for interactive education. Well done. Also, what a brilliant video. A new way to interface with code and imagine algorithms, animations and data. All to be used for education! My favorite part of the video was at 30min, where Bret demos how to interactively make animations. Reading the comments on the video led me to purchasing Braid http://braid-game.com/, a game that was mentioned. HA.
EDIT: Exploring your link, I discovered Bret Victor. Anyone looking for some inspiration look at his show reel. http://worrydream.com/#!/Showreel2012
This has been out there for a while iirc. I hope something comes of it. Even the potential chapter list is great though for those of us struggling to learn pixel shaders well.
If you wanna be sincere about this, I think you should have a section dedicated to Gezira, and not only the more traditional imperative styles of graphics programming. The style of GUI that came out of PARC is no longer "modern", and has problems with modern development styles (e.g, single-threaded global event loops makes writing concurrent programs difficult).
If you're not familiar with it, Gezira is a full vector graphics API, including compositing, written in less than a thousand lines of Nile - a small flow-based programming language. It does its magic by treating quadratic bezier curves as the main primitive, where the author has developed an algorithm to calculate the pixel coverage of a given bezier, with anti-aliasing.. Because most operations can be treated independently, it lends itself nicely to concurrency - each operation in a data flow can run independently, and many operations can be parallelised if given sufficient inputs.
Gezira/Nile was created by Dan Amelang while working for VPRI (the research institute headed by Alan Kay). A demo of it in action can be seen here: (http://tinlizzie.org/~bert/Gezira.ogv), where it's worth noting that the entire Editor UI in this example (after first 5 seconds), including font rendering, is written with Gezira itself.