3 ms·

Regardless of the Nyuzi's merits, that demo is unimpressive. We (RenderMorphics and then Microsoft D3D) were happily spinning teapots on 50 MHz 486s, significa

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.

wallacoloo 11y ago
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).
jeffbush 11y ago
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-profile.html 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 http://latchup.blogspot.com/2015/06/not-so-fast.html
- Arelius 11y ago
  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.
  - erichocean 11y ago
    > 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…
  - jeffbush 11y ago
    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.
- pjc50 11y ago
  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.)
mankash666 11y ago
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.
sitkack 11y ago
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.

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.

wallacoloo 11y ago

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

jeffbush 11y ago

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-profile.html 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 http://latchup.blogspot.com/2015/06/not-so-fast.html

Arelius 11y ago
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.
- erichocean 11y ago
  > 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…
- jeffbush 11y ago
  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.
pjc50 11y ago
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.)

mankash666 11y ago

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.

sitkack 11y ago

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.