[nickpsecurity]

I guarantee it would smoke it by similarly ridiculous numbers. Assembler will inherently be doing ops sequentially while also waiting on memory accesses in between them where not cached. An expected speed up might factor in the clock difference between it and yours plus number of cores. Yet, you're not going to get the kind of parallelism and simple operation you have with custom HW. It's the lasting drawback of general-purpose CPU's.

And why Intel is buying Altera. Stuff like this article will get easier and with even bigger speedups in the near future. Just wait. :)

[p1esk]

It's more interesting to see what could be done with a GPU.

Also, I wonder if we could bypass the shared main memory, and to turn the pixels on and off directly (by hacking the display driver or whatever).

[nomel]

> Also, I wonder if we could bypass the shared main memory, and to turn the pixels on and off directly

The pixels exist in a shared memory, do they not?

[gluggymug]

That's the problem I think. He's changed from a shared pixel memory in the reference design to a non shared one in his HW accelerated design. That's the impression I get from the diagrams.

It's somewhat moving the goal posts IMO. Guess it's ok since it's a student project.

[p1esk]

Pixels are mapped to memory locations, but they don't have to be, if you can access the map directly. I don't exactly know what I'm talking about here, just a thought.

[conorpp]

What would be the difference between writing to shared hardware pixels over a shared memory performance wise?

I mean, pixels are just like a memory except that they glow. They hold their value and can be writen a new value in sync with a clock (which is normally 60 Hz for most monitors which is MUCH slower then on chip memory). There could be no performance benefit.