Comment by baldfat | Hacker News Reader

Comment by baldfat | Hacker News Reader

Parent Full thread

I define myself as a former Amiga owner. That computer was so defining and the community so strong sad that Jack Tramiel went out to kill the Amiga with the Atari ST. These Andy Warhol pictures were a claim to fame for many Amiga owners and it was awesome to know that they were found right next to the bouncing red and white ball.

It must have taken around 6 or 7 years for the Macintosh and "IBM PC" computers to catch up. The graphic art capacity was head and shoulders about anything else outside of Silicone Graphics. Not to mention that VIM was developed on the Amiga.

I had a audio port so I could record through RCA cables and remix things. My church had the Video Toaster which was in use from 1987 to 2004. This actually led to me doing a lot of audio and video work that I still do today.

In the future I think the hardware architecture will resemble more of the Amiga as we hit the limits of computer chips. There will be more dedicated chips and cores for more specific things.

We've already seen the resurgence of heterogenous computing on the iPhone. The SoC inside offloads video and voice processing to dedicated ASICs. When you call these functions on the API, they run on the ASIC, not on the main CPU.

Video processing has been offloaded in PCs for a long time; the first "3D accelerators" were in the late 90s.

Perhaps I meant to say image processing. The ability to point the camera at something and make sense of the picture (FaceID, AR).

> the first "3D accelerators" were in the late 90s. You forgot about SGI and I'm sure a few others like Intergraph who were doing dedicated 3D video pipelines in hardware starting in the in the 80's.

Actually the Amiga had a GPU for 2D graphics. You need a Amiga desktop model and not a A500. The graphics shop down the road had a dozen Amigas with these cards for rendering and even ray tracing. They were pretty amazing. Even Disney used them for Beauty and the Beast and other animation at the time.

http://www.amigareport.com/ar216/p1-7.html

really? Pretty sure OCS was the same in all Amigas

Back in the 80s there was a co-processor known as 8087 and it was a different beast than 8086/8088.

I had a computer with two different CPUs 6502 and Z80 that could actually ran them in parallel.

There is nothing new about the ability to have some functionality offloaded to another processing unit regardless of the architecture.

The 8087 was the floating point co-processor or FPU for the 8086. It was not a separate CPU.

The blitter, raster, and audio coprocessors on the Amiga weren't Turing complete general purpose CPUs either.

The 8087 FPU was not offloading the CPU as the CPU was halted after the FPU caught a FP instruction and made a DMA call to the CPU and took control of the bus to access what memory it had to. They were a tag-team if you will; jumping in and out of the ring to deal with their respective instructions.

Halted? You had an option to WAIT for 8087 but you could 'cheat' and just run other instructions, manually calculating cycles.

Thus, a system with an 8087 was capable of true parallel processing, performing one operation in the integer ALU of the main CPU while at the same time performing a floating-point operation in the 8087 coprocessor. Since the 8086 or 8088 exclusively controlled the instruction flow and timing and had no direct access to the internal status of the 8087, and because the 8087 could execute only one instruction at a time, programs for the combined 8086/8087 or 8088/8087 system had to ensure that the 8087 had time to complete the last instruction issued to it before it was issued another one.

https://en.wikipedia.org/wiki/Intel_8087#Design_and_developm...

I believe Agnus(?) and the CPU had to wait on each other for the memory bus - as evidenced by the CPU getting slower when the screen resolution was increased, due to the greater amount of video memory being read per frame.

The first college I went to wouldn't let me in as a CompSci major because that program was full. But it had a TV station with an Amiga and Video Toaster that nobody knew how to use, so I was enrolled in the journalism school so I could run it for them.

I'm not sure. Heterogeneous architectures were a huge mess with the PS3, for a recent example, and abandoned in the subsequent PS4 for relatively standard x86 kit. Taking advantage of specialized hardware is not without its costs.

As someone who went through that era and worked on a cross-platform title.

The issue wasn't that the PS3 was heterogeneous, it was that the X360 came first so everyone wrote for a system that had relaxed memory constraints. When the PS3 came along all of a sudden things that weren't vectorized didn't run slow, they just flat out didn't run at all.

Fun fact, the few engines that were developed for the PS3 first and X360 second ran circles around everyone else because all the vectorization work for PS3 meant they fit in caches really nicely and had zero cache misses. Easily 2-4x faster than titles doing equivalent work.

It depends on the API implementation, really. The criticism back in the day was that Cell was difficult to program for. I would imagine this was because its functions were at a lower level, which buys you power at increased development cost. Think the difference between Vulkan and OpenGL. Sony didn't seem to value development value over capability, which led to the PS3 earning the reputation of being an underutilised console: https://www.cnet.com/news/sony-ps3-is-hard-to-develop-for-on...

Apple's heterogenous computing functions on iOS are higher-level and much easier to use. Instead of manually writing code to do FaceID on iOS, possibly involving graduate-degree levels of theory, you simply create a biometry type which abstracts much of the details, many of which developers aren't particularly interested in fine-tuning. This is how someone on a budget like Bank XYZ can use FaceID to unlock your bank app.

Another angle worth considering is the economics of porting titles. If you take full advantage of specialized hardware like the PS3 had, it could have a strong influence on the implementation of games- possibly even pushing down to choices in aesthetics and game mechanics. As a result it may be very difficult to get a comparable experience on another console.

If a game is designed and written to more-or-less cater to a common denominator it is more straightforward to later port the game to other consoles or PCs- including platforms that might not exist at the time the original game was created- and mop up sales from those other userbases.

I'm not sure I agree. It was much easier to develop your game around the PS3's heterogeneous architecture, then port it to a more conventional architecture like the Xbox 360 or PC and get good performance than doing it the other way around.

In very broad strokes, compared to the other consoles of its generation, the PS3 offered a large compute capacity via SPEs and was starved for RAM and memory bandwidth. I think you're conflating the technical impact of a heterogenous architecture with other differences in specs.

If you tailored a game to work within the memory footprint of a PS3 and did not take advantage of SPEs, a port is easy- you've aimed at a lowest common denominator. If you designed your game with the expectation that you'd have more RAM, you'll have to make some painful decisions to cut the game down to size. If you designed your game to actually take advantage of SPEs, there wouldn't necessarily be a comparable compute resource on the platform to which you would like to port.

Just a small nit that the PS3 and X360 had the same amount of RAM, it was just split on the PS3. X360 had a unified memory model which was a lot easier(PS3's is closer to a PC and X360 your mobile phone).

We still did clever things like putting music in GPU memory and then streaming it back to system memory since the bandwidth wasn't large and read patterns were very predictable.

Yup, and when you did that you got a huge perf-bump on non-PS3 platforms since you already had things built in a way that were memory-locality friendly.

Jay Miner - Creator of Amiga's API

http://www.geekometry.com/2015/01/gamechangers-jay-miner-and...

Amiga had the best API. Even as a kid I could understand what I was doing with it.

Well, not really: the PS4 still has a GPU, so it has two kinds of computing units where the PS3 had three. The SPUs existed mostly because the same number of full-blown cores would have been prohibitively expensive back then.

I specifically said it would look more like. Of course we have GPU and other chips but we are going to have much more than we have now to get an increase in computer power.

The BIG issue will be programming to utilize these architecture and we haven't really hit anything yet that we see a HUGE increase when we have multiple of cpu cores let alone other components. The big issue will be API.

Any modern PC is heterogeneous. Not just the GPU, but even full CPUs. Most harddrives have full CPUs driving the HD controller, for example (e.g. you'll find multicore ARM's on many of them).

Reply on news.ycombinator.com