@amigakit

Quote:

We are hopeful you will not produce a duplicate "warp3d.library" as that will confuse users and for all the reasons I have iterated, it is not a technically proficient way of tackling the problem.

"Confuse" is not the word I would choose for a driver tailored for a specific board... how can you be confused by it?

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Karlos

Quote:

The env issue you referenced is a strawman argument. ... Most importantly, absolutely none of this is relevant to the monolith v multicomponent debate. A monolith driver for the Permedia2 would continue to need a mechanism for supporting both applications.

At this point I'm not even trying to argue/debate with you any more, because it's clearly pointless and would be a poor use of my time.

I'll spell this out to you: my view (based on writing two drivers from scratch) is that there are zero technical reasons to replace the Warp3D.library instead of writing a proper driver.

The only reasons for doing so are non-technical: basically, being unable or unwilling to use the Warp3D DDK to write a proper driver. Or, wanting to bypass a library that someone else owns.

Hans

Last edited by Hans on 21-Jan-2025 at 10:03 AM.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Hans

then why did thellier write a replacement for warp3d and not just a driver?

I still do not understand what this is about. So there is a plan to port "nova" to 68k?

In order to stay on topic and be objective, I'm just going to list the technical advantages as I see them of the proposal:

1. Open source: Anyone can contribute, development and issue resolution is completely transparent.
2. One single library to install for the end user.
3. Reduced complexity for development and test. A bug is either in your driver or it isn't, as opposed to an hitherto unknown issue in a parent library or adjacent one.
4. No dependency or complications to address or avoid arising other framework components. Technically this is the same point as 3 but applies in general rather than just to debugging.
5. Clean room implementation can have a fresh development take on how to approach other aspects, e.g. resource and state management and how to do these most effectively for the specific hardware.

Trade offs (neither good/bad, just different):
1. Runtime abstraction and modularity is swapped for compile time abstraction/modularity. I would argue this is an advantage for performance but it likely makes zero difference for the PiStorm. However if there are ever future targets for silicon 68K, it's a plus.

Disadvantages:
1. There's more to implement than there is for a pure HW driver which doesn't have as many responsibilities as the main library. Some of those additional things may be defunct, it all depends on how much coverage you want for the earliest applications.

Large Elephant in the Room:

I have no idea what state the legacy code is even in at this point but the last time I worked on it, it had been ported to OS4, including the DDK. This is just another complication to deal with for a 68K driver. I don't recall the last iteration used any macro replacements to generalise library calls between 3.x and 4.x and everything was updated to native OS4 standards.

Has anyone ever validated the existing components can be compiled for 68K since then? They used to compile in StormC4 relying on it's support for building 3.x library targets. In the event that you need to fix something external to your driver implementation, you may have code that is no longer compilable for 3.x to deal with.

I will steer clear of the nontechnical arguments to avoid another conflagration.

Last edited by Karlos on 21-Jan-2025 at 11:33 AM.
Last edited by Karlos on 21-Jan-2025 at 10:39 AM.

_________________
Doing stupid things for fun...

@Hans

I respect your opinions and we've had many sensible discussions in the past. The simple fact is that I don't agree with you about there being zero technical reasons for not wanting to write a W3DHW driver. I'm not arguing against you for no reason. I have a different point of view and naturally will take a stance contrary to yours.

I have detailed, as objectively as I can, reasons above.

_________________
Doing stupid things for fun...

@ppcamiga1

Quote:

ppcamiga1 wrote: @Karlos Wrong. Emu68 emulate whole os. Like winuae. Winuae may use 2D graphics, 3D graphics, audio, network, hdd from host without emulation.

Wrong,

WinUAE's P96 RTG, Wazp3D, AHI, storage, and network are bridged into the host machine's equivalent functions.

WinUAE's host CPU public ISA is translated to the CPU's internal instruction set via hardware decoders and microcode engines.

WinUAE emulates the entire Amiga machine which is slower than the Amithlon counterpart.

WinUAE runs on top of a memory-protected/logical memory-paged/task-switching host OS. When running memory-protected/logical memory-paged/task-switching host OS, the host CPU's MMU and cache need to be very fat.

VS

Emu68's storage, RTG, and WiFi are real hardware drivers for AmigaOS.

Emu68 doesn't emulate Commodore's value-added Amiga chipset.

Emu68 runs an efficient bare-metal 64-bit lite-hypervisor beyond 32-bit aware AmigaOS.

Emu68 reconfigures Pi hardware for Amiga AutoConfig's expectations.

Emu68 translates the CPU. Refer to Transmeta's Codemorph example.

Emu68's bare metal approach eliminates the bloated host Linux/Windows NT OS.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@ppcamiga1

Quote:

yes this AGA should have chunky pixel in 1992

The alternative, AGA needs VGA's "Michael Abrash" optimized software evangelist.

Michael Abrash was hired by Microsoft to optimize baseline VGA drivers for Windows 3.x and Windows NT 3.x around the same time as Abrash's VGA optimization evangelism. Windows will use X87 FPU to speed up GUI's calculations.

Grind/Dread game proves stock A1200 can do 1st perspective shooter games beyond Wolfenstein 3D with a good frame rate when the game is optimized for Amiga hardware.

Sega Mega Drive's Wolfenstein 3D port had Grind/Dread's line skip trick.

Amiga's Grind/Dread used Amiga's line draw acceleration, hardware OCS sprites, and blitter C2P.

There are two missing pathways for AGA i.e.
1. AGA needs VGA's "Michael Abrash" optimized software evangelist. Remove software C2P API is slow remarks in the official Commodore's Amiga reference manuals which is bad PR.
Abrash's optimized VGA code snippets are publicly published.

or

2. Memory bandwidth conservative 8-bit chunky pixel hardware support.

Last edited by Hammer on 21-Jan-2025 at 12:35 PM.
Last edited by Hammer on 21-Jan-2025 at 12:06 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Can we leave the ppcamiga1 sideshow for once? I know, I'm just as bad usually.

_________________
Doing stupid things for fun...

@Hans

Quote:

Hans wrote: @Karlos My first thought when I read this was: "why not just write an actual Warp3D driver?" I've written two of them from scratch (for Southern Islands GPUs, and then the W3D_NovaBridge driver that makes Warp3D Nova backward compatible). The driver API is straightforward, and I didn't have any trouble with its design. In both cases I bypassed the Picasso96 driver, because I put a render manager API in the 2D driver which let me allocate VRAM without having to play silly games with Picasso96/Cybergraphics. This eliminated the annoying need to lock the graphics system during Warp3D operations. Hans

PiStorm and Emu68 are open-source projects. Your work with Warp3D Nova drivers for AMD GCN 1.0 is a close-sourced commercial adventure.

PiStorm and Emu68's goal is to create a freely clonable hardware Amiga platform.

AmigaKit has benefited from the wannabee clone Orange Pi 3 and clone PiStorms.

AmigaKit/A-EON can offer their full System 54 68K port for PiStorm-Emu68 as a close-sourced commercial with bundled eStore adventure.

PiStorm-Emu68-CM4+modfied Nanomig stand-alone would be the fastest/low-cost Amiga 68K platform without using the UAE with hosted platform route.

This would enable any Amiga box shippers (including AmigaKit) to propagate and grow the Amiga market again.

AmigaKit/A-EON can modify PiStorm32+ CM4 + Nanomig stand-alone designs with PCIe slots for AMD GPUs.

For big-endian capable CPU and low cost, ARM is the only choice for keeping up with current generation mainstream game consoles e.g. Nintendo Switch and the incoming Switch 2.

In a given generation, Amiga 500's 68000 CPU selection is contemporary with mainstream game consoles e.g. Sega Mega Drive's 68000. A modern "Amiga 500" concept is a "Nintendo Switch" with open desktop access and gaming bias.

PowerPC camp had its chance and blew it. Vampire's "more than 10,000 unit sales" have shown potential with Amiga 68K.

ARM CPU selection can lead to handheld form factors.

Current handheld gaming devices are powered by either ultra mobile X64 or AArch64 SoCs.

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

Going forward, the AMD's Radeon RX 7600 series lost the "value for money" to Intel's Battlemage B580 GPU. https://www.techpowerup.com/review/intel-arc-b580/

Last edited by Hammer on 21-Jan-2025 at 12:05 PM.
Last edited by Hammer on 21-Jan-2025 at 12:01 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Karlos

Quote:

Karlos wrote: @Hammer Can we leave the ppcamiga1 sideshow for once? I know, I'm just as bad usually.

You're not ppcamiga1.

I think it's safe to say that most Amiga fans want to see Make Amiga Great Again (MAGA).

PowerPC is not the right choice for the modern "Amiga 500" concept.

ARM has been used for relatively low-cost wedge Acorn desktop microcomputers in the 1980s/1990s, modern-day Raspberry Pi 500 keyboard desktop computers, and Nintendo Switch handheld/hybrid desktop game console.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

I meant I'm just as bad at falling into the trap of replying to his nonsense.

_________________
Doing stupid things for fun...

@OlafS25

Quote:

OlafS25 wrote: I still do not understand what this is about. So there is a plan to port "nova" to 68k?

That seems very unlikely, given legacy v5 hasn't even been ported.

_________________
Doing stupid things for fun...

Ironically, I suspect that - all issues aside - Nova would be a reasonable target for the Videocore. After all, it's not a fixed function render pipeline and uses a more modern shader model.

I have no experience of Nova and I don't know how high or low level the shader language is.

_________________
Doing stupid things for fun...

OlafS25 Quote:

then why did thellier write a replacement for warp3d and not just a driver?

Likely, there were non-technical reasons why Alain wrote a Warp3D replacement. The 68k Warp3D and AmigaOS development had been arrogantly abandoned at that time and there was no interest in supporting them. I believe Alain was interested in the AmigaOS 4 version of Warp3D too so it is possible he could have obtained the Warp3D DDK for it and used it for the 68k as well. He was creating a software rendering device/library for Warp3D which would have improved Warp3D but perhaps there was IP protection BS, like exhibited in this thread, and oppressive non-disclosure agreements all for a legacy API that was not going to make anyone rich. This is the same clinched fist IP protectionism that has divided the Amiga market and kept it from proliferating for the last 30 years of failure. I could have helped Alain work out the Warp3D driver library function calls which I mostly had figured out other than the actual names but Wazp3D was already created and working by that time, the 68k Warp3D.library was poorly optimized and unmaintained and he probably did not want to take any chances of being threatened by the Warp3D IP owners. Who would have thought a programmer writing programs for free that benefit the Warp3D IP owner would threaten such efforts but who thinks otherwise after this thread? How many good programmers like Alain have been pushed away from the Amiga and to other divided Amiga camps? What is there left of the Amiga that is even so valuable after 30 years of this BS? A desktop wannabe AmigaOS 4 lacking modern desktop features, especially SMP, on expensive hardware that is being outperformed by $25 USD low end SBCs using in-order CPU cores needs protecting? Will these guys ever wake up from their fantasies before they completely wipe away the Amiga?

OlafS25 Quote:

I still do not understand what this is about. So there is a plan to port "nova" to 68k?

As far as I am aware, there is a limited number of 68k users using or that have the potential to use newer Radeon GPUs (there are no PCIe graphics cards used on the 68k that I am aware of). New drivers for the integrated RPi/VideoCore GPUs and A600GS/OrangePi Mali GPU would be extra work beyond porting. Maybe a VideoCore driver would have been worthwhile but the A600GS chose to embed an Orange Pi instead of a more standard RPi with better documented GPU. Why? Perhaps the less public documentation better protects their IP? Perhaps it was the better LPDDR4 memory spec used to boost performance although why not choose a SBC with a more efficient and better for 68k emulation Cortex-A55 with the load-to-use penalty reduced to 2 cycles from the Cortex-A53 3 cycles? Perhaps non-techical reasons win out in Amiga Neverland floundering in non-intellectual pursuits?

You are asking good questions but do not expect to receive logical answers in Amiga Neverland. Amiga software and hardware development defies logic here. There is no change in plans to fix problems or even recognize that there are problems. There is no attempt to be competitive or improve economies of scale to become competitive. Trevor just injects cash from time to time into an endless abyss for his hobby while RPI Holdings has grown to a market cap of 1.32B GBP.

https://www.google.com/finance/quote/RPI:LON

How many more lost Amiga decades will the Amiga suffer before disappearing forever?

Last edited by matthey on 21-Jan-2025 at 08:10 PM.

@matthey

Pairing a physical 68K with a Radeon R200 era part over a PCI bus with potentially single digit MB/s write bandwidth (depending on how it's attached, maybe double digit on a GRexx) is already pretty bonkers. Especially when your just using it as a rasterizer and having to shovel your software transformed vertex data to it every frame. Doing the same thing for a more modern GPU like Radeon HD... I guess that would fall purely into the realm of "because you can". I have no issue with that per se, but the practicality of it... Hmmm.

Even the proposed solution for PiStorm is of course going to be an underutilisation of considerable proportion. However, building it will doubtless be very educational for anyone interested in taking a different approach later - for example, creating a direct GL implementation that leverages much more of the hardware capabilities more directly.

Everything has to start somewhere.

Last edited by Karlos on 21-Jan-2025 at 08:29 PM.

_________________
Doing stupid things for fun...

@matthey

the graphic drivers where not open source,

Wazp3D started of as simple software renderer, I believe OS4 version took advantage of Composition for texturing, but can’t take advantage of z-buffering and so on, it was nice for some broken games, but now I believe most of the old games have been recompiled and updated, Wazp3D should be needed anymore.

the onboard graphic chip on the Sam460 did not support 3D i belive, you need a external graphic card, or use Wazp3D. I belive.

Last edited by NutsAboutAmiga on 21-Jan-2025 at 08:31 PM.
Last edited by NutsAboutAmiga on 21-Jan-2025 at 08:31 PM.

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

@zErec

Quote:

zErec wrote: �Warp3D�for PiStorm! Up to now 3D Games on PiStorm equipped Amiga Computers were limited to pure software rendering despite a Pi4/CM4 having a good 3D Chip (Videocore VI).

It would be better to be implemented as OpenSource so UAE (WinUAE, Amiberry, AUE on AOS4) could benefit from that "Warp3D" wrapper.

Last edited by OneTimer1 on 21-Jan-2025 at 08:39 PM.

@OneTimer1

One of the things I think would be nice is to work backwards. Once you have a fully working, v5 API compatible implementation for videocore, the groundwork for other implementations is laid. Even if the code is quite coupled for MVP, it can be refactored to separate out the concerns and the appropriate compile time abstractions put in place.

All the R100 and R200 hardware documentation is fairly easy to find these days.

_________________
Doing stupid things for fun...

@OneTimer1

Quote:

It would be better to be implemented as OpenSource so UAE (WinUAE, Amiberry, AUE on AOS4) could benefit from that "Warp3D" wrapper.

Not always possible, low-level implementations are often different between Linux and AmigaOS, but yeh.. Having something to look at, is good template, for a port / reimplementation, when the code can’t be reused.

Last edited by NutsAboutAmiga on 21-Jan-2025 at 10:11 PM.

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

@MagicSN

Quote:

MagicSN wrote: @manga303 I had looked into a possible Shogo 68k port some while ago. I had some problems with the source-code (might be there is an outdated file or something in what I got) - the source code I got BTW being the one of the OS4 version. I currently do not continue on it (too many other projects) but not impossible that I would look at it again sometimes in the (undefined) future. OpenLara uses OpenGL Shaders. Might be possible to translate to what GLES uses, but probably you really need a Shader expert (I am not that!) for this. Also the 3D for PiStorm will not include Shader Support (it will use Shaders internally, but not offer actual Shader support).

What about 3DO or Sega 32X OpenLara ports?

https://github.com/XProger/OpenLara/releases

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB