Hacker News Reader

Comment by jamesbowman | Hacker News Reader

Regardless of the Nyuzi's merits, that demo is unimpressive.

We (RenderMorphics and then Microsoft D3D) were happily spinning teapots on 50 MHz 486s, significantly faster than that.

View on HN

From a performance perspective, admittedly. The software 3D renderer it is running is not highly optimized. But it's probably not an apples-to-apples comparison, since this has programmable vertex/pixel shaders that uses floating point for parameter interpolation and color values. I assume 486 class 3D renderers were probably taking some shortcuts (no shaders, fixed point math, etc.)

What I think it does demonstrate is that the hardware design can run a non-trivial programs reliably on FPGA. Maybe that's not impressive either, but I thought it was kinda cool. :) While this doesn't mean anyone needs to go shorting NVidia stock, it does allow anyone who is interested in CPU/GPU architecture to experiment with and modify a full featured design (pipelined, vector floating point, L1 & L2 caches, hardware multithreading).

I analyzed the basic performance and scalability of the 3D renderer here:

http://latchup.blogspot.com/2015/02/improved-3d-engine-profi...

And dove a bit deeper into performance using a custom Quake level renderer:

http://latchup.blogspot.com/2015/06/not-so-fast.html

It may still not be an apples-to-apples comparison, but since it was running on the 486, it was by definition, doing programmable vertex transformation and shading.

> it was by definition, doing programmable vertex transformation and shading

Yes, all software renderers are—by definition—programmable, but those terms usually imply some kind of shading language like GLSL that is accepted at runtime, compiled and then executed by the graphics engine (hardware or software).

It seems unlikely that Mr. Teapot went through the effort to write his own JIT for a 486-class machine, but certainly it could be done…

What I meant was that the shader is a pluggable function in this implementation. If you wanted to change the shader function (say add texture or environment mapping) in this implementation, it would be a fairly minor code change that would have a relatively small incremental performance hit. If you wanted to do that for a highly optimized 90s era fixed pipeline software renderer, you'd most likely need to rewrite it from scratch, and certain operations wouldn't be feasible at all. So, this is paying a lot of the cost for flexibility up front.

Nice blog, it's a fascinating project to build something like this from the ground up.

(I actually have some phong-teapot-on-a-486 code, written when I was 16, which I keep meaning to dig up and post. It managed a few tens of thousands of triangles/sec.)

On it's own, that's not much information to make a useful comparison (in my opinion). There's a lot more to consider (power usage on an equivalent node, display resolution incl. bit-depth, # of tris, shading model, etc).

Thanks for the negative top comment, negative comment man. These kinda posts are really turning me off to hacker news. Yeah, you were awesome back in the day. Congrats.

That's probably a good thing. A small, private company can base their development off the existing design and deliver IP that's 95% as fast as the best in class for 30% of the cost. Nvidia/AMD/imagination disrupted.

Reply on news.ycombinator.com