@matthey

Quote:

Could Hombre have saved C= from bankruptcy? Probably not as it was not far enough along in development. It was probably on par with the PS1 but wasn't finished so maybe would have had to compete with the PS2. Would C= have been pursuing the PA-RISC if they know now what the 68k could do as presented here? If they were smart, they would have been looking to license or buy the rights to the 68060 from Motorola (should have been cheap as it was undervalued and discarded for PPC) and perhaps add their own SIMD as it would have saved them the development effort of porting the AmigaOS to PA-RISC and they could have done it as a much prioritized effort to make a single chip Amiga (68k+custom chips) SoC. Then again, knowing C=, they would have probably tried to create a 68030 based SoC instead of 68060 based one as they lacked a tech savvy vision with good leadership.

C= management killed their MOS (CSG)'s CISC 65xx CPU R&D and you think CSG has engineering resources to evolved CISC-RISC hybrid 68060 with 2.1 million transistors in a timely manner?

C='s management culture issues have existed since the 1970s when C= runs down MOS R&D competitiveness.

Commodore is NOT 1990s AMD. AMD has an in-house designed 29K RISC CPU which served as the RISC core for K5's X86 CISC-RISC hybrid design. X86 CISC is acting like instruction compression for 29K based RISC core on K5.

K5-90 reached 90 Mhz in March 1996 with 0.35 micro-meter process node.
K5-100 reached 100 Mhz in October 1996 with 0.35 micro-meter process node.
K5-166 reached 133 Mhz in January 1997 with 0.35 micro-meter process node.
K5 has 4.3 million transistors, about double 68060's 2.1 million transistors count.

1995's 29050 model was the first superscalar version which can retire up to four instructions per cycle and also including a greatly improved floating-point unit (FPU). 80-megaflop peak floating-point execution at 40 MHz.

29050 reached 100 Mhz in 1994. 29050 doesn't have L1/L2 cache, but it has 192 general-purpose registers. 29050 closer to GpGPU design concept with large and very fast register storage.

The first 29000 was released in 1988 which includes built-in MMU but floating-point support was offloaded to the 29027 FPU. My point, C= engineering team has to show their in-house CPU R&D skills 1st before embarking on CISC-RISC evolved 68060 projects.

Commodore's Amiga Hombre project requires R&D effort sourced from HP's PA-RISC R&D.

Last edited by Hammer on 27-Jun-2021 at 09:30 AM.
Last edited by Hammer on 27-Jun-2021 at 09:25 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

Quote:

amigadave wrote: ..., if the fools at Amiga Inc. hadn't given away their control of developing AmigaOS4 ...

Amiga Inc. hadn't given away their control before they where forced to do so by the court.

That was the major problem with Amiga Inc., they wanted to keep control and ownership but let someone else do the work and having risk of porting the OS.

That's what Ben Hermans told them they should do when he worked as an consultant for them and made a contract that was refused by Genesi / The MorphOS team.

The same foul contract was responsible for the hardware crisis when Amiga Inc. refused to give away AOS4 licences. I believe Hyperion never wanted to fulfil his part of the contract with Amiga Inc, they wanted them to go bankrupt so they can have the control on AOS4 alone.

Last edited by OneTimer1 on 27-Jun-2021 at 10:32 AM.

@matthey

Quote:

fan boys on this site have been humbled

Is this what your talking about?



The gray hair man, is pretty close the average age here.

Last edited by NutsAboutAmiga on 27-Jun-2021 at 01:43 PM.
Last edited by NutsAboutAmiga on 27-Jun-2021 at 12:46 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

@Hypex

Quote:

Hypex wrote: @Lou Quote: No one is disputing the process...but Yes I already read it. But it's also rather confusing. SAGA has it's own registers for newer features. AKIKO is a CD32 specfic feature. Sure, Apollo core is based on AGA, but AKIKO is an obscure feature not common on other AGA machines. But is it needed? The issue I see there is reimplementing another chip. Because AMMX is meant to fix that. The Blitter is there but looked down upon in new code as AMMX is considered better by keeping it in the CPU. And AMMX would be expected to perform C2P or P2C. It is but the old design also has overhead as mentioned. Since it needs to be written to and read from. Even the Blitter takes a pointer to data, converts if needed, then writes out the result itself. I think AKIKO has too much manual intervention. It doesn't seem to fit with the chipset design. The 040 and AKIKO look to be converting at the same speed. If you enhance then compatbiliy can break. Is it worth enhancing or replacing as SAGA does? I keep reading about this other CPU thread. Is this thread part of the 080 core? Or in the FPGA?

So AKIKO became a way to cost-reduce the Amiga. I imagine moving the 'code' into one chip package actually ends up saving some space due to elimination of redundancy of having separate chips. It also by default adds CDTV+CD32 compatibility. People seem to ignore its other functions other than C2P... /sigh

The tests are in. AKIKO is a performance boost. You can go on about overhead all you want but as I have said many times, doing it all in the CPU is hubris and not the true Amiga-way. The CELL processor in the PS3 is a perfect example of such a failure. In the end it still needed the NVIDIA gpu.

If you don't know that the '080 is dual-threaded then I guess you haven't been paying much attention.

Last edited by Lou on 27-Jun-2021 at 05:00 PM.
Last edited by Lou on 27-Jun-2021 at 04:56 PM.

@OneTimer1

Quote:

Amiga Inc. hadn't given away their control before they where forced to do so by the court.

They were not forced by the court. Their money man (Pentti Kour) died, so they ran out of cash minutes before Hyperion did. This is why they had to settle out of court.

Quote:

That was the major problem with Amiga Inc., they wanted to keep control and ownership but let someone else do the work and having risk of porting the OS.

Hyperion agreed to make OS3 run on the AmigaOne, for a fixed sum of 25,000 USD. A sane person would have only signed that deal if he/she didn't consider it too big a risk or too little payment.

Are you saying Ben Hermans is insane?

Quote:

The same foul contract was responsible for the hardware crisis when Amiga Inc. refused to give away AOS4 licences.

Since Amiga Inc. and Hyperion were in a stalemate and later on a legal battle at that point, blaming the contract for the lack of licenses doesn't make much sense.

Lou Quote:

So AKIKO became a way to cost-reduce the Amiga. I imagine moving the 'code' into one chip package actually ends up saving some space due to elimination of redundancy of having separate chips. It also by default adds CDTV+CD32 compatibility. People seem to ignore its other functions other than C2P... /sigh

Let's take a closer look at the functions of the Akiko ASIC.

Beauty - front (LED segment display?) panel controller on CDTV, buttons and infrared port
Budgie - expansion port and fast ram control (baby Buster from 1200)
Grace - CD-ROM and flash EEPROM support added to Gayle (IDE and PCMCIA support)
2x8520 - CIAs
c2p - chunky to planar acceleration

Beauty probably wasn't used in the CD32. If the infrared port was flexible enough, maybe it could be used for bluetooth but bluetooth may be supported through a USB Dongle (like Wi-Fi) on low priced Amiga hardware. The LED segment display could be useful through GPIO pins if there were pins available but traditional Amiga ports would likely get priority for GPIO pins. There is not much advantage for Beauty support.

Budgie doesn't add anything new that I'm aware of. It is just integrated into the Akiko ASIC to reduce cost.

Grace has the CD-ROM support which could be translated to another standard or perhaps drive a modern CD-ROM directly. I'm not sure the EEPROM support is useful as it works for small flash sizes and modern flash memory may work differently and support much larger sizes. It is questionable how useful this support is but it could help with compatibility which is more reliable than software patching.

The 2 CIAs are vital to Amiga operation. I wonder if the re-implementations in the ASIC have improved timings as 8520s are slow. I expect the serial port out the Aux port which doubles as a keyboard port on the CD32 uses one of the CIAs. This was clever to combine serial and keyboard port which may be easier and more CD32 compatible with Akiko support.

The chunky to planar support improves CD32 compatibility and may be useful for planar bitmap support but has limited importance where chunky is available and there is adequate memory to support it.

Overall, there is *not* much modern functionality here but detection and at least partial register mapping of the Akiko should be relatively cheap and improve CD32 compatibility without software patching.

Lou Quote:

The tests are in. AKIKO is a performance boost. You can go on about overhead all you want but as I have said many times, doing it all in the CPU is hubris and not the true Amiga-way. The CELL processor in the PS3 is a perfect example of such a failure. In the end it still needed the NVIDIA gpu.

The Akiko 68040 c2p likely does *not* give the best performance possible on the Apollo core. This means that an Apollo core optimized c2p is likely faster than using the Akiko. An Apollo core optimized c2p may *not* be available in older software and the Akiko c2p does perform well enough that there is no major bottleneck. New programs will usually use chunky which avoids the performance loss of c2p altogether so what exists seems adequate. I don't know why Gunnar would be touting Akiko c2p support which seems minor to me.

You seem to equate Akiko c2p and hardware support of any kind to GPU support being necessary instead of SIMD unit support for good performance of 3D graphics. It's really not as simple as that. Akiko c2p lacks efficiency as it is outside of the CPU unit pipeline which can cause multi-cycle bubbles where a SIMD unit instruction usually doesn't have to worry about these bubbles. While processor instructions are efficient, adding more instructions makes cores larger reducing the core count and parallel processing power. Some processors have separated some of the SIMD units from the CPU as CELL did. This gives more SIMD units (SPEs for CELL) for parallel work but they are more difficult to access and control. The 8 CELL SPE SIMD units were never meant to replace a GPU. They were designed to be used in multi-core networked computers like the IBM RoadRunner which had 103,680 SPEs. The Intel Larrabee project was a failed attempt to use CPU SIMD units as the GPU. See the Larrabee and CELL comparison in the following link too.

https://en.wikipedia.org/wiki/Larrabee_(microarchitecture)

Larrabee worked fine as a GPU but required too many fat x86 cores. Lighter weight cores or separating the SIMD units from the cores would have likely given better performance, reduced energy use and lowered cost. There is good reason to want to make multi-core multi-threaded CPU cores work for the GPU. GPUs have evolved from fixed rendering pipelines to more flexible rendering pipelines which CPU cores like this support well, especially for real time raytracing. Overall system parallel performance is more easily used as CPU tasks can use GPU cores and GPU cores can use CPU cores. Workload distribution and scheduling is also easier. Maybe such a setup would never be competitive with a GPU but I expect it is possible to come closer than the Larrabee project. The Larrabee project "was to include very little specialized graphics hardware, instead performing tasks like z-buffering, clipping, and blending in software" which did not help competitiveness. Specialized SIMD unit instructions for GPU acceleration and specialized hardware for fixed parts of the rendering pipeline would likely make a big difference.

Last edited by matthey on 28-Jun-2021 at 01:07 AM.
Last edited by matthey on 28-Jun-2021 at 12:59 AM.

cgutjahr Quote:

They were not forced by the court. Their money man (Pentti Kour) died, so they ran out of cash minutes before Hyperion did. This is why they had to settle out of court.

Amiga Inc. is rumored to have bailed out Hyperion when they were, or pretended to be, in financial trouble by cutting them a check for more than the agreed upon amount to continue AmigaOS 4 development. This has been claimed in some of the recent lawsuit documents where the Amiga parties are suing Hyperion. If true, Amiga Inc. was Hyperion's white knight but when it came to return the favor Ben stabbed them in the back. Was Ben ever a white knight?

cgutjahr Quote:

Hyperion agreed to make OS3 run on the AmigaOne, for a fixed sum of 25,000 USD. A sane person would have only signed that deal if he/she didn't consider it too big a risk or too little payment.

There are only two possibilities. Ben was naive or a con man where it helps to be a lawyer.

cgutjahr Quote:

Since Amiga Inc. and Hyperion were in a stalemate and later on a legal battle at that point, blaming the contract for the lack of licenses doesn't make much sense.

Why would Amiga Inc. give licenses which helps the former business partner who broke their contract?

@matthey

Quote:

https://en.wikipedia.org/wiki/Larrabee_(microarchitecture) Larrabee worked fine as a GPU but required too many fat x86 cores. Lighter weight cores or separating the SIMD units from the cores would have likely given better performance, reduced energy use and lowered cost. There is good reason to want to make multi-core multi-threaded CPU cores work for the GPU. GPUs have evolved from fixed rendering pipelines to more flexible rendering pipelines which CPU cores like this support well, especially for real time raytracing. Overall system parallel performance is more easily used as CPU tasks can use GPU cores and GPU cores can use CPU cores. Workload distribution and scheduling is also easier. Maybe such a setup would never be competitive with a GPU but I expect it is possible to come closer than the Larrabee project. The Larrabee project "was to include very little specialized graphics hardware, instead performing tasks like z-buffering, clipping, and blending in software" which did not help competitiveness. Specialized SIMD unit instructions for GPU acceleration and specialized hardware for fixed parts of the rendering pipeline would likely make a big difference.

Larrabee is a garbage GPU. There's a reason for modern GPUs has very large register storage since it's the fastest known data storage method i.e. it's faster than L1 cache.

AMD's RDNA has Zero Level cache to reduce latency which slots between registers and L1 cache.

AMD/ATI rammed the classic RISC's larger register argument against the non-X86 RISC camp with massive register storage advantage math co-processor aka GpGPU.

Quote:

You seem to equate Akiko c2p and hardware support of any kind to GPU support being necessary instead of SIMD unit support for good performance of 3D graphics. It's really not as simple as that. Akiko c2p lacks efficiency as it is outside of the CPU unit pipeline which can cause multi-cycle bubbles where a SIMD unit instruction usually doesn't have to worry about these bubbles. While processor instructions are efficient, adding more instructions makes cores larger reducing the core count and parallel processing power. Some processors have separated some of the SIMD units from the CPU as CELL did. This gives more SIMD units (SPEs for CELL) for parallel work but they are more difficult to access and control. The 8 CELL SPE SIMD units were never meant to replace a GPU. They were designed to be used in multi-core networked computers like the IBM RoadRunner which had 103,680 SPEs. The Intel Larrabee project was a failed attempt to use CPU SIMD units as the GPU. See the Larrabee and CELL comparison in the following link too.

FYI, The original PS3 design has two CELL configurations.

Unlike SSE, PS3's CELL SPE's IEEE-754 FP is not suitable for non-gaming workloads.

IBM RoadRunner CELL SPU has the fixed IEEE-754 FP support.



-----------------

For AMD GCN

Floating-point Arithmetic Datatypes:
16-bit, 32-bit, and 64-bit floating-point numbers as defined by IEEE 754-2008

IEEE Rounding and Sub-normal Handling Modes:
‒ Round to nearest even, Round toward +Infinity, Round toward–Infinity, Round toward zero
‒ Control for input sub-normal flush to zero and underflow flush to zero
‒ Provided under software control anywhere in the program
‒ Separate rounding mode and sub-normal control for single and double precision numbers

Exceptions Support
‒ Inexact, underflow, overflow, division by zero, sub-normal, and invalid operation
‒ Provided in hardware with mechanisms for software recording and reporting

----
AMD GCN beats CELL SPE in IEEE 754 feature support.

For NVIDIA RTX and AMD RDNA 2 era GPUs, specific hardware exists to accelerate BVH raytracing workloads.

Renderman has the hybrid raster-raytracing workloads, hence the need to hardware accelerate these workload types.

I support the argument position to combine graphics functions into a single chip to reduce latencies. A frame render workload is about the lowest time to render the frame, hence the lowest latency is important.

Last edited by Hammer on 28-Jun-2021 at 07:48 AM.
Last edited by Hammer on 28-Jun-2021 at 07:32 AM.
Last edited by Hammer on 28-Jun-2021 at 07:29 AM.
Last edited by Hammer on 28-Jun-2021 at 07:20 AM.
Last edited by Hammer on 28-Jun-2021 at 07:10 AM.
Last edited by Hammer on 28-Jun-2021 at 06:58 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

matthey wrote: The Akiko 68040 c2p likely does *not* give the best performance possible on the Apollo core.

You continue to miss the point. To me, what I see when AKIKO C2P matches the performance of a faster cpu doing C2P, I see it as a hardware limitation. In other words in PC-land - what's known as being cpu-limited or gpu-limited. In other works, 48.6 fps in Doom may be the limit of the CHIP ram's bus. Hence to do it any faster, you'd need RTG. At that point you wouldn't use AKIKO so the point is moot.

Quote:

You seem to equate Akiko c2p and hardware support of any kind to GPU support being necessary instead of SIMD unit support for good performance of 3D graphics. It's really not as simple as that. Akiko c2p lacks efficiency as it is outside of the CPU unit pipeline which can cause multi-cycle bubbles where a SIMD unit instruction usually doesn't have to worry about these bubbles. While processor instructions are efficient, adding more instructions makes cores larger reducing the core count and parallel processing power. Some processors have separated some of the SIMD units from the CPU as CELL did. This gives more SIMD units (SPEs for CELL) for parallel work but they are more difficult to access and control. The 8 CELL SPE SIMD units were never meant to replace a GPU. They were designed to be used in multi-core networked computers like the IBM RoadRunner which had 103,680 SPEs. The Intel Larrabee project was a failed attempt to use CPU SIMD units as the GPU. See the Larrabee and CELL comparison in the following link too. https://en.wikipedia.org/wiki/Larrabee_(microarchitecture) blah blah blah

Again - when the CPU is expected to do everything you run into a limit. When you can off-load some functions, now you have overcome some limits. That's what offloading C2P to AKIKO does. [and Paula ... etc ...]

You can produce a [useless] tech-demo of the '080 doing a single function faster than a chip designed in 1989. Great. Now do that and 16-bit sound and blitting and 3d transformations and handle user input, handle file access and run game code all on the cpu at the same time. Let me know what FPS you hit...and how many polygons you are pushing and oh, you have stuttering issues with your sound? Oh gee the cpu is too busy to do it all smoothly. Shucks.

...and that's why you have dedicated chips. The Amiga way is to off-load work to dedicated chips.
Multiple generations of consoles with much weaker cpus than the '080 continue to prove this.

The '080 is a better Atari cpu than it is an Amiga cpu. Why? Because Atari ST/Falcon barely used any custom chips. When that platform did - it was called a JAGUAR and blew the doors off previous Atari's.

Last edited by Lou on 28-Jun-2021 at 09:40 PM.
Last edited by Lou on 28-Jun-2021 at 01:55 PM.

@Lou

The JAGUAR was not able to match the features or advance power of Blazemonger on Amiga.

_________________
Sent from my Quantum Computer.

Hammer Quote:

Larrabee is a garbage GPU.

I mentioned Larrabee was a failure as a GPU. It was a later attempt somewhat like Hombre but with up to 32 times the SIMD parallelism per instruction, SIMD unit floating point support, 4 times the threads per core and initially 32 times followed by 48 times the number of cores, albeit with the x86 tax, yet still was not a competitive GPU. GPU and chip fab technology had advanced a huge amount from 1994 to 2009 and there was more and better competition. The flexibility of Larrabee allowed it to do real time raytracing in 2009 which is pretty good for a garbage GPU even if it used too much power and area to be practical. Real time raytracing uses more power although the algorithms have improved significantly since then and more hardware acceleration has been developed. Also, cores used for both CPU and GPU processing can be better utilized by the system even if the GPU performance is not competitive with the most advanced GPUs.

Hammer Quote:

There's a reason for modern GPUs has very large register storage since it's the fastest known data storage method i.e. it's faster than L1 cache. AMD's RDNA has Zero Level cache to reduce latency which slots between registers and L1 cache.

Generally, the smaller the storage the faster the access time. A small L0 cache is faster to access than a normal sized L1 cache but accessing the L1 may become a little bit slower. I doubt the register configuration had much to do with Larrabee not being competitive. With 512 bit wide SIMD unit registers and 4 copies of the registers for 4 threads per core, there was plenty of register file real estate.

Lou Quote:

You continue to miss the point. To me, what I see when AKIKO C2P matches the performance of a faster cpu doing C2P, I see it as a hardware limitation. In other words in PC-land - what's known as being cpu-limited or gpu-limited. In other works, 48.6 fps in Doom may be the limit of the CHIP ram's bus. Hence to do it any faster, you'd need RTG. At that point you wouldn't use AKIKO so the point is moot.

Chunky RTG avoids the extra work which Akiko partially does. What point is there with a moot point?

Lou Quote:

Again - when the CPU is expected to do everything you run into a limit. When you can off-load some functions, now you have overcome some limits. That's what offloading C2P to AKIKO does. [and Paula ... etc ...] You can produce a [useless] tech-demo of the '080 doing a single function faster than a chip designed in 1989. Great. Now do that and 16-bit sound and blitting and 3d transformations and handle user input, handle file access and run game code all on the cpu at the same time. Let me know what FPS you hit...and how many polygons you are pushing and oh, you have stuttering issues with your sound? Oh gee the cpu is too busy to do it all smoothly. Shucks. ...and that's why you have dedicated chips. The Amiga way is to off-load work to dedicated chips. Multiple generations of consoles with much weaker cpus than the '080 continue to prove this.

Akiko was a bad example as chunky RTG usually allows to avoid the unnecessary work of c2p altogether. Minimizing the amount of work is as much the Amiga way as off loading the work to co-processors and dedicated hardware.

For work that needs to be done, expanding processing power with SMP cores has many advantages over specialized co-processors and dedicated hardware. The extra cores can be used to do general purpose workloads rather than specific workloads. This is also why cores which can do CPU and GPU processing are interesting. The disadvantage is that more specialized hardware is more efficient at doing specific tasks. Specialized hardware typically uses fewer active transistors for the workload and it can be power gated when not in use saving power. Lots of specialized hardware does increase area but transistors are cheap with mass production. Modern consoles are a good example of using crazy amounts of specialized hardware to lower power at the expense of area. GPUs use specialized hardware to lower power but modern rendering requirements are reducing the amount of specialized hardware which can be used and increasing the GPU cores to be more flexible and general purpose like CPU cores. SMP cores are easy to add which is as simple as a copy and paste in the HDL code and they are already fully supported with SMP. Specialized hardware requires designing, implementing, programming and testing as much different specialized hardware as wanted but this is quite a bit of human labor to reduce power.

Lou Quote:

The '080 is a better Atari cpu than it is an Amiga cpu. Why? Because Atari ST/Falcon barely used any custom chips. When that platform did - it was called a JAGUAR and blew the doors off previous Atari's.

All those processors in the Atari Jaguar made it difficult to program too. The Atari Jaguar, Sega Saturn and Playstation 3 were not as popular partially because they were difficult to program with separate processors but high theoretical parallel processing power. The Amiga was more expensive than the Atari ST and more expensive to upgrade because of the specialized hardware which hindered it on introduction and it took a while for programmers to learn and take advantage of the complex hardware. I'm not arguing against specialized hardware but SMP is an easier and cheaper way to add performance. Newer consoles use both SMP and lots of specialized hardware to reduce power.

Last edited by matthey on 29-Jun-2021 at 07:29 AM.

@matthey

Quote:

matthey wrote: ...a lot of stuff about missing the point of why implementing AKIKO is a good thing... Lou wrote: Quote: The '080 is a better Atari cpu than it is an Amiga cpu. Why? Because Atari ST/Falcon barely used any custom chips. When that platform did - it was called a JAGUAR and blew the doors off previous Atari's. All those processors in the Atari Jaguar made it difficult to program too. The Atari Jaguar, Sega Saturn and Playstation 3 were not as popular partially because they were difficult to program with separate processors but high theoretical parallel processing power. The Amiga was more expensive than the Atari ST and more expensive to upgrade because of the specialized hardware which hindered it on introduction and it took a while for programmers to learn and take advantage of the complex hardware. I'm not arguing against specialized hardware but SMP is an easier and cheaper way to add performance. Newer consoles use both SMP and lots of specialized hardware to reduce power.

A lot of Jaguar games were 68k-based because programmers were too lazy to learn the RISC cpu.
All those systems you mention had cpus 1/10 as powerful as the '080 and still produced games 10x better than anything using SAGA....proving my point.

Heck, the Vampire has yet to produce 3D even on the level the the SNES and is stuck in the NEO-GEO (aka non-3D) era of capability.

It's funny to hear you call SMP a better solution when the Jaguar was actually hurt by lazy programmers who weren't yet versed in AMP and used it's 16mhz 68000 for almost everything instead of learning to program Tom and Jerry correctly. When they did - we got a masterpiece like Aliens vs. Predator.

Again - it's funny to hear you talk about newer consoles using SMP for performance while ignoring the fact that they use CUSTOM APUs with larger built-in gpus than any laptop...or even off-the shelf APUs.... Give me the AMD model # I can buy off the shelf with 8 Ryzen 2 cores and 56 RDNA2 compute units....PLEASE! Even the AMD 5800G (Ryzen 3) still only packs in 8 Vega graphics cores... According to your logic, they just just slap in a 16-core AMD CPU, no gpu, into a console and it will outperform an APU with half the cores in gaming. Sure.......

Because the Vampire is a cpu-centric system, the best it will ever be is a NeoGeo successor as it can hardly do 3D as well as an SNES. When you go on to mention the SuperFX2 chip, you will be proving my point about 'custom chips'.

Last edited by Lou on 29-Jun-2021 at 01:44 PM.

@Lou: So SAGA isn´t an advanced AGA-chipset after all?

_________________
AmigaOne X5000/40, 2.2 Ghz, 4 GB RAM, Radeon R9 280X, M-Audio Revolution 5.1, 240 GB SSD

@Lou

Quote:

All those systems you mention had cpus 1/10 as powerful as the '080 and still produced games 10x better than anything using SAGA....proving my point.

I think you need a large community, and an alive community, so far, they trying to sell it on retro, zombies and vampires, but no one can turn back the clock, so what we have is what we have. Amiga communities biggest game sell in later years has collection of hacked / cracked games from 80’s and 90’s distributed by Cloanto. There are no Indi developers or game companies coming back.

It’s fun little thing for people who are already amiga users, or maybe former users and developers if the price is right, but that’s it.

Anyway do not expect lot of new demos, the argument for AGA only, OCS is low speed hardware and, fixed demo categories, there just no interest in, new systems because they are not Amiga systems, according to this people, this is why we can’t have new nice things. Its always going be shutdown.

besides if only small % of community that owns Vampire, way not just continue to support larger OCS / 7mhz market.

Whit out games and demos for Vampire or NG systems (AHI/Picasso96), you just not going to sell vampire systems.

Last edited by NutsAboutAmiga on 29-Jun-2021 at 04:44 PM.
Last edited by NutsAboutAmiga on 29-Jun-2021 at 04:43 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Lou Quote:

A lot of Jaguar games were 68k-based because programmers were too lazy to learn the RISC cpu. All those systems you mention had cpus 1/10 as powerful as the '080 and still produced games 10x better than anything using SAGA....proving my point. Heck, the Vampire has yet to produce 3D even on the level the the SNES and is stuck in the NEO-GEO (aka non-3D) era of capability. It's funny to hear you call SMP a better solution when the Jaguar was actually hurt by lazy programmers who weren't yet versed in AMP and used it's 16mhz 68000 for almost everything instead of learning to program Tom and Jerry correctly. When they did - we got a masterpiece like Aliens vs. Predator.

The 68k is easier to program than the higher performance RISC processors and can use the 2 MiB of main memory. The Atari Jaguar RISC processors have a serious bug when using branches in main memory and can only use their 4kiB (GPU) and 8kiB (DSP) local memory while avoiding the bug. The Jaguar hardware wasn't impressive. An Amiga with faster CPU and memory but no 3D hardware should have been capable of playing Aliens vs. Predator. Just look at Genetic Species and Quake running on the Vampire SAGA.

Aliens vs. Predator (Atari Jaguar)
https://www.youtube.com/watch?v=3GEOTtpOFWw

Genetic Species (Vampire)
https://www.youtube.com/watch?v=lMmXAB1S3Qk

Quake (Vampire)
https://www.youtube.com/watch?v=0BCG3WXSeW8

Quake 2 (Vampire)
https://www.youtube.com/watch?v=M7hL_pn6bfg

Vampire SAGA looks better in most cases, runs at comparable fps and is easier to program. The Jaguar hardware may have close to the processing power of the Vampire with SAGA but it is difficult to get close to the theoretical performance with a bunch of AMP processors. It is not just about programmer laziness but time efficiency both in programming the games and creating the hardware. Good single thread performance is as important for games as specialized hardware and easier to use.

Lou Quote:

Again - it's funny to hear you talk about newer consoles using SMP for performance while ignoring the fact that they use CUSTOM APUs with larger built-in gpus than any laptop...or even off-the shelf APUs.... Give me the AMD model # I can buy off the shelf with 8 Ryzen 2 cores and 56 RDNA2 compute units....PLEASE! Even the AMD 5800G (Ryzen 3) still only packs in 8 Vega graphics cores... According to your logic, they just just slap in a 16-core AMD CPU, no gpu, into a console and it will outperform an APU with half the cores in gaming. Sure.......

I mentioned that modern consoles have greater need for specialized hardware to reduce power, which includes in the GPU.

Lou Quote:

Because the Vampire is a cpu-centric system, the best it will ever be is a NeoGeo successor as it can hardly do 3D as well as an SNES. When you go on to mention the SuperFX2 chip, you will be proving my point about 'custom chips'.

The Vampire has a single FPGA CPU core running around 100 MHz and isn't going to be great at 3D even if it gets some 3D hardware support as planned. Half way modern 3D GPUs use many times more transistors than the Vampire CPU core which is already using most of the affordable FPGA space.

The Vampire is likely to get poor 3D support. The SIMD unit support is also poor (64 bit SIMD, no fp). This is the result of planning for the hardware to remain in FPGA forever which is a self fulfilling prophesy as it is unlikely anyone will want to make an ASIC of a CPU and GPU with features and standards from the 90s. In my opinion, it would be better to leave out 3D and SIMD support for now so that more modern features could be added later. Kids like to play with their toys though and other kids keep asking for more toys when the toy box isn't big enough to hold everything.

Last edited by matthey on 30-Jun-2021 at 01:35 AM.

@matthey

Quote:

I mentioned Larrabee was a failure as a GPU. It was a later attempt somewhat like Hombre but with up to 32 times the SIMD parallelism per instruction, SIMD unit floating point support, 4 times the threads per core and initially 32 times followed by 48 times the number of cores, albeit with the x86 tax, yet still was not a competitive GPU. GPU and chip fab technology had advanced a huge amount from 1994 to 2009 and there was more and better competition. The flexibility of Larrabee allowed it to do real time raytracing in 2009 which is pretty good for a garbage GPU even if it used too much power and area to be practical. Real time raytracing uses more power although the algorithms have improved significantly since then and more hardware acceleration has been developed. Also, cores used for both CPU and GPU processing can be better utilized by the system even if the GPU performance is not competitive with the most advanced GPUs.

Crytek has a real-time octree raytracing Neon Noir tech demo without the need for hardware BVH raytracing on the DX12 class GPUs. https://www.youtube.com/watch?v=1nqhkDm2_Tw
Turing RTX still has the superiority in software octree raytracing over RDNA counterparts.

Both Larrabee's Quake Wars raytracing and Crytek Neon Noir raytracing tech demos have raytraced reflections. Crytek Neon Noir's CryEngine 5.0 raster workload is higher than the aging Quake Wars' ID Tech 4 engine.


World of Tanks Encore with CPU AVX 256 v1/v2, AVX512 powered software BVH raytracing.
https://www.youtube.com/watch?v=dXbjmF--QVc
Software BVH shadow raytracing guides the raster GPU on what to paint.

SMT has higher importance for in-order processors such as Larrabee and most GpGPUs (via ATI/AMD Hyper-Threading or NVIDIA Giga-threads).

No modern GpGPU has a small register size of Larrabee. Matrix math processing register storage stress is a major issue.

The major difference between ATI Xenos Tesselation on Xbox 360 vs Radeon HD 5870 DX11 Tesselation is the increased register storage to support DX11 hull and domain shader registers without reusing vertex shader registers and reduced register storage overspill situation.

Quote:

Generally, the smaller the storage the faster the access time. A small L0 cache is faster to access than a normal sized L1 cache but accessing the L1 may become a little bit slower. I doubt the register configuration had much to do with Larrabee not being competitive. With 512 bit wide SIMD unit registers and 4 copies of the registers for 4 threads per core, there was plenty of register file real estate.

RDNA's latencies are lower than Vega GCN.

Last edited by Hammer on 30-Jun-2021 at 04:29 AM.
Last edited by Hammer on 30-Jun-2021 at 04:27 AM.
Last edited by Hammer on 30-Jun-2021 at 04:20 AM.
Last edited by Hammer on 30-Jun-2021 at 04:17 AM.
Last edited by Hammer on 30-Jun-2021 at 03:53 AM.
Last edited by Hammer on 30-Jun-2021 at 03:15 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Lou

Quote:

Lou wrote: A lot of Jaguar games were 68k-based because programmers were too lazy to learn the RISC cpu. All those systems you mention had cpus 1/10 as powerful as the '080 and still produced games 10x better than anything using SAGA....proving my point. Heck, the Vampire has yet to produce 3D even on the level the SNES and is stuck in the NEO-GEO (aka non-3D) era of capability.

SNES needs 2nd gen Super FX at 21 Mhz to render cutdown Doom.
https://youtu.be/784MUbDoLjQ?t=1119
DF Retro: Doom - Every Console Port Tested and Analysed!

AC68080 or MC68060/XC68060 or any Pentium class CPU can play Quake and Doom at PCMR (PC Master Race) standard. :P

Comparing any SuperFX to a Pentium class CPU is unwise.

Last edited by Hammer on 30-Jun-2021 at 04:46 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

Hammer Quote:

SNES needs 2nd gen Super FX at 21 Mhz to render cutdown Doom. https://youtu.be/784MUbDoLjQ?t=1119 DF Retro: Doom - Every Console Port Tested and Analysed!

The CD32 can almost run Doom as well as the SNES.

https://www.youtube.com/watch?v=N5N8F1egmNc

With some display reduction and tweaking, the CD32 may have been capable of as good of port as the SNES and 3DO Doom ports. With a 68030 and fast memory, a CD32 Doom could have been better than the Sega Saturn and Atari Jaguar ports of Doom. A 68030 was low enough cost it could have been used in the CD32.

Hammer Quote:

AC68080 or MC68060/XC68060 or any Pentium class CPU can play Quake and Doom at PCMR (PC Master Race) standard. :P Comparing any SuperFX to a Pentium class CPU is unwise.

Yes. My 68060 Amiga is fast enough that I kick up the ADoom resolution to 512x384x8 RTG which looks much better and plays with better speed than the consoles up to the PS3/XBox Doom ports which also increase the resolution in the video. Quake is 3D and much more demanding than Doom. The 68060 is limited to low resolution for acceptable frame rates except with 3D hardware which allows me to run 512x384x16 at nearly the frame rate of Doom. The 68060 was too late and expensive for an Amiga console though. The CPU itself probably cost as much as most of the consoles in the 1990s. The 68060 was low enough power for a console (or laptop) but CBM would have had to work out a really good deal with Motorola to drop the price low enough for a higher end console, had CBM survived. We aren't even sure how well the CD32 would have sold with full production but it looks like it would have sold well in Europe at least, and likely better than the Jaguar console.

@Hammer

Quote:

Hammer wrote: @Lou [quote] SNES needs 2nd gen Super FX at 21 Mhz to render cutdown Doom. https://youtu.be/784MUbDoLjQ?t=1119 DF Retro: Doom - Every Console Port Tested and Analysed! AC68080 or MC68060/XC68060 or any Pentium class CPU can play Quake and Doom at PCMR (PC Master Race) standard. :P Comparing any SuperFX to a Pentium class CPU is unwise.

I did state SuperFX2 ... emphasis on the 2. And 21Mhz... Let that sink in against a 100Mhz '080.
I made no such comparisons. My comparisons were against the '080.