In this case, every computer today follows the Amiga way: graphics and sound are offloaded to dedicated chips, usually using a DMA bus no less, and they have their own memory as well.
Yeah, I think that's right. The Amiga failed in the marketplace, but a lot of its better ideas were picked up and used in other systems.
The Atari also had custom chips if memory serves, which is why its music was better (or so I hear).
It depends on the model of course, but the original ST used an off-the-self sound chip, so the sound was worse than the Amiga, which was apparent in games. It did have MIDI ports, and was thus fairly popular for music production. The graphics were better than the PC (analog, with a 512-color palette), but again, worse than the Amiga.
I only knew one guy with an ST, so my knowledge is limited. If the Amiga had never existed, the ST would have probably been the one to get.
Skipp, which is a beta tester, has finally gotten his hands on a V4, and have run thru a few demos.
Ghostown & Loonies "Human Traffic" Amiga AGA Demo (Vampire V4)
First ever capture from my shiny new Vampire V4 :) "Human Traffic" AGA/FPU demo by GTN&LNS (2011). Running on alpha AGA+FPU core revision 5484 (~92MHz, not 78MHz despite what "WhichAmiga" thinks). Recorded in realtime 720x576 50fps with StarTech PEXHDCAP.
Lou wrote: I wasn't suggesting to use GDDR5. I used GDDR5 to show such speeds exist in the real world and are not "fictional".
Also, if you've been following along, the Gamecube's memory, circa 2001 was doing 2.6GB/s to 18GB/s depending on where in the system you look... and could still push 20M-90M polygons per second. This is 2018. So even his fictional 50GB/s number was a gross overestimation of what is required to render acceptable 3D. Mind you, I was only looking for the 100k to 200k number to beat or match systems available in the mid to late 1990s that had FAR WEAKER cpus...
I repeat - his hubris is thinking the cpu can do it all.
A CPU can do most of the work of a GPU. The Commodore Hombre chipset was using a single core superscalar PA-RISC CPU with primitive SIMD unit (PA-RISC SIMD unit part of integer unit like the Apollo Core).
Then there was the Larrabee GPGPU which used multi-core in-order superscalar Pentium/Atom like CPUs with 512 bit wide SIMD units. The result was a very flexible and easy to program GPU with cores which could also be used for CPU SMP work. Surely a 16 core setup like this could handle 3D gfx of old consoles even though 48 cores was not competitive with more specialized GPUs of the day resulting in Larrabee being cancelled. Perhaps this concept could work with more efficient and smaller cores (so they could have more in the same space), more specialized GPU hardware and/or not seeking to be competitive with state of the art GPUs.
Then there was the Knights Landing Xeon Phi x86_64 which resembled Larrabee but was now called a CPU instead of a GPGPU. However, it was sometimes faster to render with the SIMD units that go through a slow bus to a GPU.
The concept is really cool but keeping the logic close enough, cache coherency issues, stream processing requirements and a good MMU design probably make such a setup tricky. Intel thought they could make an x86_64 based GPGPU work with Larrabee and it wasn't efficient enough.
The Apollo core is restricted by the small resources of affordable FPGAs. It's not difficult to add multiple cores or a wider SIMD unit (speaking of hardware limitations not Gunnar's ISA limitations). It makes little sense to move dedicated functionality to other chips. As I've said before, it is better to move everything closer into one SoC, perhaps with a separate FPGA for versatility.
Lou wrote: I don't know, but generally speaking, unless it's an embedded device, you ship a PC board with sockets, not soldered memory...
So the Raspberry Pi is an embedded device? Maybe you are right. Affordable computers seem to find embedded uses. It certainly is a better embedded device than any NG Amiga.
You missed where I linked the successor to the Super Nintendo's FX chip -> the ARC Processor, that uses a risc cpu along with many "stream processors" in parallel to allow a 100Mhz to 200Mhz cpu to do modern 3D and MP4 decoding...
...and yes, a RPi3+ is considered an embedded device to me. It's not expandable and is used to control machinery such as printers, etc... embedded PPC devices have been running cars and printers for years, for instance...
Re: News about Vampire and Apollo Posted on 30-Sep-2018 6:27:52
Yes it is relevant if: 1. you want to have a system with 68k compatibility. 2. you need to access the same system structures from 68k and PPC.
Maybe you can run the 68k software in a UAE like sandbox, but there it could not access system structures like if it was done in AOS4 or MOS.
But if you don't care about 68k emulation or if you think an UAE is enough, you can switch to other CPUs and even to other OSes.
That's what I did for my personal needs.
Anyway, sometimes it's very difficult to understand what other people wants. For me it's not a matter of "I want a big endian system to run 68K applications", but... "I want to run 68K applications".
You talked about OS4 and MOS, which provide a better integration of 68K applications, for sure. However I don't know if you want to use 68K applications only on OS4/MOS, or in general you want to executed them in your favorite system.
My favorite system is Windows, for example, and currently I can run them only through WinUAE. It means that I'm limited and forced by a sandbox approach which requires to reproduce an entire Amiga machine. So, 68K applications aren't well integrated on Windows.
However this might change if a "68K virtualizer" is realized which allows to run those applications as regular Windows ones. The integration will be limited, of course (not comparable to what OS4 and MOS offer) but can be good enough.
Re: News about Vampire and Apollo Posted on 30-Sep-2018 8:59:00
PPC can not be replaced because there is not faster cpus than work in 32 bit big endian mode. PPC Amigas feel like better Amigas than these made by Commodore beacuse they are many times faster than 68k Amigas and provide seamless integration with old 68k Amiga software. Comparison to pc with Windows is dumb, Windows do not provide integration with old 68k Amiga software.
Re: News about Vampire and Apollo Posted on 2-Oct-2018 9:04:38
But this is not possible, the compiler does know it can use lhbrx or lwbrx, or whatever.
So instead, I might do some inline PowerPC assembler to do something to optimize for x86 little ended memory structures.
This where get stupid, having to write none generic assembler that don't work on x86 to read x86 memory. do you see the stupidity of that?
Similar calling x86 instruction big endian mode to emulate different powerpc instruction, it so silly, and often ends up as some bloated C code.
I think If was possible to use intBe32 in C code, I think most developer be using it, Le format is not readable, "LE" only become popular because it was used on most common CPU's, as result of Microsoft Windows/Office addition in the market. The open PC clone market. What horrible legacy to drag on into the future.
cdimauro wrote: Just some notes here, since I was primarily working on Xeon Phi products when I was at Intel.
Larrabee failed because GPUs were (and still are, albeit something is changing) too much optimized for raster graphic, so the latter allowed to better use the silicon for this specific task. First Larrabee versions (never released) had not fixed-functions at all, so the x64 cores had to do all the work, which brought to very worse performances; this forced Intel to add some fixed-functions units (texturing) to improve the situation. However it wasn't enough to compete with GPUs. The paradox is that hardware-based raytracing GPUs were just presented by nVidia, and this means that NOW a Larrabee design could have been much higher chances to compete...
The Amiga has an association with ray tracing as the Amiga was better equipped to render static ray traced images back when it was introduced. When I was part of the Apollo team back in 2013, one of the potential investors I was talking to was all about ray tracing (Monte Carlo bi-directional path & wave tracer). He was wanting FPGA accelerated ray tracing as a GPU before it became popular again. It certainly is possible to do real time ray tracing at lower resolutions than rasterization. Eventually, highly specialized hardware will likely take over for ray tracing like rasterization but the algorithms are being improved so it could be useful to use more flexible hardware like many core GPGPU/CPUs and/or FPGAs. While an SIMD unit can likely handle most of the vector computations, it looks to me like the algorithms can use many branches for trees (shorter integer pipelines and/or better branch prediction helpful) and quasi-random numbers (less discrepancy than psuedo-random numbers) which perhaps could use acceleration. Does this agree with your understanding of ray tracing workloads and did I miss some requirements to make it fast?
Larrabee and the first Xeon Phi products weren't called CPUs because they were just coprocessors (they lacked some instructions. So, they weren't fully x64-compatible) and sold only as PCI-Express cards.
Starting from Knights Landing they are called CPUs, because they have a full x64 ISA. They were still sold as PCI-Express cards, but also as standalone processors (which offered much better performances too, since Knights Landing processors hadn't to go through the the very slow PCI-Express to share memory: NUMA works much better).
A CPU integrated ray tracing GPU could probably offset some of the additional cost of ray tracing. The Amiga used to have integrated graphics which has a performance advantage with Moore's law expiring but now PCIe seems to be the NG "Amiga way". I love the scale-ability of a highly parallel multi-core GPGPU/CPU which can use cores for both the CPU and GPU. I believe it would be easier to program and optimize than highly specialized hardware (Hans was complaining about the unfriendliness of modern rasterizing GPUs). I believe the 68k could be a more efficient mid performance base CPU than a Pentium/Atom like x86/x86_64. The 68k ISA is not as fat, instructions don't need to be broken down as far, decoding is less expensive (percentage of a mid performance core was as high as 30-40% for x86 according to you) and may require fewer pipeline stages for better branch performance, has significantly better code density which may allow to half the L1 ICache, etc., which is all a per core savings in transistors and energy use which adds up. Too bad the "Amiga way" does not include hardware any more. Software only is the route to being assimilated.
Re: News about Vampire and Apollo Posted on 2-Oct-2018 23:59:45
Not really that impressive. Q2 software rendering looks about the same performance as on my 68060@75MHz. I believe NovaCoder compiled for the 68060 and my assembler optimizations were the best for the 68060 but should be good on the Apollo core. It would look much better if you ran 512x384x16 instead of 320x240x8. Granted, I can only push that with Warp3D acceleration and Cowcat's old version wasn't as smooth as NovaCoder's version in any resolution (Cowcat's Q1 was silky smooth at 512x384x16 but it has more of Frank Wille and my assembler optimizations). You would be better off AMMX optimizing and showing off Doom since AMMX lacks floating point support needed for Quake 1 and 2. The fully pipelined OoO FPU doesn't seem to be blowing away the partially pipelined in-order 68060 FPU. Maybe I was right in arguing that the fully pipelined Pentium FPU didn't have much advantage over the 68060 in mixed integer/fp code. I still expected the faster memory and larger DCache of the Apollo core to give it an advantage with fp code but maybe those wide shifts for normalization are slowing it down.
Last edited by matthey on 03-Oct-2018 at 12:00 AM.
Re: News about Vampire and Apollo Posted on 3-Oct-2018 6:30:09
When I was part of the Apollo team back in 2013, one of the potential investors I was talking to was all about ray tracing (Monte Carlo bi-directional path & wave tracer). He was wanting FPGA accelerated ray tracing as a GPU before it became popular again.
Would have been a promising idea back in 2013, but that ship has since sailed. NVIDIA now have GPUs with hardware accelerated ray tracing ( https://developer.nvidia.com/rtx/raytracing ), and this will soon be cross-platform (once the Vulkan support for ray tracing is brought in). It's a shame, as FPGAs would've been well suited for the task, but they aren't likely to be able to compete now that modern GPUs are offering hardware-accelerated ray tracing.
If you'd like to see a demo of NVIDIA's RTX (Ray Tracing Extensions) in action, check out this video: