Nice to see this here, thanks for sharing it cmsimike.
This was a labor of love/appreciation for me a couple of years ago over a Christmas break. I went through a retro gamedev period during that break, read a few books like Masters of Doom, and found myself trying to read through the various (relatively poor quality) electronic copies of the Black Book that were floating around. Yak shaving being what it is, I spent most of my Christmas break scraping and cleaning up a few different copies to put this together so I could (more comfortably) read it on my Kindle.
FWIW, these conversions were done with an eye for preserving an interesting piece of gaming/graphics programming history, and aren't really intended to be relevant today.
I also converted the Zen of Assembly Language also by Abrash[1], but it's considerably less relevant than the Black Book in general.
I wouldn't recommend it for most modern-day graphics practitioners. You're much better off reading Physically Based Rendering, and a Trip down the Graphics Pipeline (blog post series). After that, I would recommend reading and playing around with the UE4 source code (which is very approachable).
The "tricks" are nice but don't translate super well to how modern pipelines are usually architected.
Could you post a link, please? Searching for those terms leads to a '96 book and some different blog posts, but I am not sure if the ones you are referring to. Thanks!
It is an absolute beast of a book, and not for beginners. Nor is it written as such; After Ch. 1 the book acts less like a sequential book, and more like an extensive reference guide for anything you'd need to really understand what goes on in a Ray Tracer.
As for "A trip down the Graphics Pipeline", I found it fairly easily:
For a gentle intro to Ray tracing that is specifically geared for beginners, and lays a simple foundation for physically based rendering, I'll recommend Pete Shirley's mini-book Ray Tracing in One Weekend. http://in1weekend.blogspot.com/2016/01/ray-tracing-in-one-we...
Not to be pedantic but "ray tracer" evokes a concept that is a fair bit narrower than a "path tracer." The latter has concepts of sampling multiple directions and attempts to do things like conserve energy, respect the statistical properties of the surfaces it interacts with etc. A perfect ray tracer is easy to write but untenable for most real-world usage so PBRT is written more to the tune of all the various things you can do to improve performance without introducing statistical bias.
All that's "really" required is patience and some mathematical maturity. It is a complete book for the most part, but if you already are familiar with concepts like sampling theory, calculus, and concepts like convolutions and signal processing you'll be better off.
You shouldn't read this book to learn modern practices. You should read it to improve your way of thinking about problems. The book is timeless if you think about it this way.
Abrash had[0] a way of explaining things that just clicked with me. His Zen of code optimization book really taught me how to think about refining my code. And where to stop refining when enough was enough.
[0] I know he's still around. Just haven't read anything by him in forever it seems.
Its hugely dated, but I really treasured my copy (its still somewhere in the attic since I put the ebook on my iPad). From a 'how to program DOS graphics' it is nominally useless but as a holistic look at ways to get around problems that were designed in by engineers who didn't think about graphics performance it is still fun.
I'm still not impressed by hardware accelerated graphics for anything other than video games.
My celeron laptop with no GPU drivers (using the EFI frame buffer only) can decode full screen video in real time and run pretty much any graphical application I want (except Gnome3, but that runs poorly on my machines that have working GPUs too.)
Michael Abrash (author of the Black Book) is currently doing VR on GPUs. He's been talking recently about how the GPUs need at least 10x more power, so in some sense he's not impressed by hardware accelerated graphics either. But I'll bet a dollar right now that he won't settle for a Celeron. ;) It doesn't sound like you're doing much that's 3d or graphically demanding? Not surprising you don't need a GPU.
My laptop has a GPU, and also has separate dedicated video decode hardware, so doesn't need either GPU or CPU for most video -- far easier on the battery and doesn't hog the CPU.
Aside from games, you might be interested in a GPU for CNNs or mining virtual currencies. There's no question about the effectiveness over laptop CPUs.
Have you seen WebRender? It sports impressive performance, which does help on real-world applications/sites, especially on low-end HW. While its performance gains probably come from multiple sources, pushing work to GPU is afaik one of the main ones.
Also, I'm reminded of Anandtech review of the 1st-gen rMBP:
At 2880 x 1800 most interactions are smooth but things like zooming windows or scrolling on certain web pages is clearly sub-30fps. At the higher scaled resolutions, since the GPU has to render as much as 9.2MP, even UI performance can be sluggish [...] But there are other limitations: many elements of screen drawing are still done on the CPU, and as largely serial architectures their ability to scale performance with dramatically higher resolutions is limited.
Some elements of drawing in Safari for example aren’t handled by the GPU. Quickly scrolling up and down on the AnandTech home page will peg one of the four IVB cores in the rMBP at 100%
The GPU has an easy time with its part of the process but the CPU’s workload is borderline too much for a single core to handle. Throw a more complex website at it and things get bad quickly. Facebook combines a lot of compressed images with text - every single image is decompressed on the CPU before being handed off to the GPU. Combine that with other elements that are processed on the CPU and you get a recipe for choppy scrolling.
To quantify exactly what I was seeing I measured frame rate while scrolling as quickly as possible through my Facebook news feed in Safari on the rMBP as well as my 2011 15-inch High Res MacBook Pro. While last year’s MBP delivered anywhere from 46 - 60 fps during this test, the rMBP hovered around 20 fps (18 - 24 fps was the typical range).
The good news is Mountain Lion provides some relief. At WWDC Apple mentioned the next version of Safari is ridiculously fast, but it wasn’t specific about why. It turns out that Safari leverages Core Animation in Mountain Lion and more GPU accelerated as a result. Facebook is still a challenge because of the mixture of CPU decoded images and a standard web page, but the experience is a bit better. Repeating the same test as above I measured anywhere from 20 - 30 fps while scrolling through Facebook on ML’s Safari
I think that demonstrates clearly how GPUs are essential for todays rich UIs, especially when targeting higher resolutions. Yes, the examples here are for web, but I don't see any reason why the situation wouldn't be the same for any other stack.
This was a labor of love/appreciation for me a couple of years ago over a Christmas break. I went through a retro gamedev period during that break, read a few books like Masters of Doom, and found myself trying to read through the various (relatively poor quality) electronic copies of the Black Book that were floating around. Yak shaving being what it is, I spent most of my Christmas break scraping and cleaning up a few different copies to put this together so I could (more comfortably) read it on my Kindle.
FWIW, these conversions were done with an eye for preserving an interesting piece of gaming/graphics programming history, and aren't really intended to be relevant today.
I also converted the Zen of Assembly Language also by Abrash[1], but it's considerably less relevant than the Black Book in general.
[1] https://github.com/jagregory/abrash-zen-of-asm