
Proposal For An Interactive Introduction to Graphics Programming - jeffreyrogers
http://pixelshaders.com/proposal/
======
sparkie
> _New ways of programming_

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](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.

~~~
tizzdogg
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.

------
SomeoneWeird
You should look at [https://github.com/stackgl/shader-
school](https://github.com/stackgl/shader-school) \- it is very similar.

~~~
jeffreyrogers
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.

------
robobenjie
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.

~~~
joshdance
Always be giving CTA

------
chubot
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.

~~~
sparkie
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](http://graphics.stanford.edu/projects/brookgpu/lang.html)),
and Harlan ([https://github.com/eholk/harlan/wiki/Language-
Overview](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.

~~~
pjmlp
No, the primary target is PTX in CUDA devices.

This is one of the reasons OpenCL is still playing catchup with CUDA.

Thanks to PTX, you can target CUDA directly with C++ and Fortran, besides a
few other languages.

OpenCL only this year got SPIR.

~~~
wtallis
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.

~~~
pjmlp
Funny I had the impression CUDA is winning hands down on HPC.

~~~
wtallis
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.

~~~
p0nce
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.

------
arsey
Shaders have always seemed like some kind of dark magic to me. Would love to
see this book happen.

------
moron4hire
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.

So this sounds freaking amazing. Sign me up.

------
dsugarman
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

~~~
chrisbennet
Shaders != CUDA

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.

------
acbart
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](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!

------
thegeomaster
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.

[1]: [http://gamedevelopment.tutsplus.com/articles/the-end-of-
fixe...](http://gamedevelopment.tutsplus.com/articles/the-end-of-fixed-
function-rendering-pipelines-and-how-to-move-on--cms-21469)

~~~
Fando
Wow great article. I learned about the difference between Ambient Occlusion
rendering techniques: Screen Space Ambien Occlusion (SSAO) and Horizon-Based
Ambient Occlusion (HBAO).

------
bstrom
I'm in. I'd love to chip in some $$$ to support it, as well.

------
berzzz
Love this idea!

I think you should add an intro to procedural graphics chapter that goes over
raymarching and other algorithms used to create meshes procedurally.

------
ogennadi
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](http://vimeo.com/36579366)). I think that that
change would really aid in "feeling" the behavior of the algorithms.

~~~
Fando
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/](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](http://worrydream.com/#!/Showreel2012)

------
landongn
I would absolutely love a resource like this.

------
hxrts
Toby's a brilliant guy. Check out some of this other work here, some of which
has been seen previously on HN.
[http://tobyschachman.com/](http://tobyschachman.com/)

~~~
Fando
Indeed! Very cool. I really enjoyed the Time Traveler art installation and
recursive drawing.

------
smrtinsert
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.

------
monokrome
This is cool.

Seeing the examples rendered is nice, but changing the code doesn't work in
Firefox. Seems like that might confuse a lot of people.

------
coderzach
This is great, but there's no where for me to put an email or something to
stay in the loop :-(

------
Gusfoo_2
That really impressed me.

------
vajrabum
FYI, the web site doesn't seem to work in Safari.

~~~
amf314
Or Chrome (at least the interactive example did not).

~~~
Narishma
Worked fine for me on Chrome.

------
daviis01
Reminds me of interactivepython.org

