@kolla

Quote:

kolla wrote: @MagicSN Just because it appears as if you are not aware… AmigaKit are (ironically) not using (British) Raspberry Pi in their A600GS and A1200NG, they are using (Chinese) Orange Pi 3, quite different hardware than Raspberry Pi 3.

I believe they have some ARM native replacements for various graphical operations so perhaps they'll do something similar to support 3D acceleration too.

I wish them well, I think the 1200NG in particular looks very nice from what I've seen so far.

_________________
Doing stupid things for fun...

@amigakit

The attitude you are showing in this thread. Stuff like claiming even a replacement would only be acceptable to you in case of cleanroom-development. Stuff like trying to intimidate my author by email (if it would not have been meant as intimidation you would have written to *me* - I am clearly marked as *project manager* on the campaign page).

And I did not contact you before announcement as I think I made it clear this is not using your IP and a reimplementation. Just like Wazp3D or the Library from Paraj. They are around since ages and it was not a problem for anyone.

I did explain in the FAQ of the campaign from the start it is a replacement to avoid any sort of legal problems with you. You proved my point. And yes, I just read you again and they absolutely tell me I have been right in planning it like I did.

And for doing a replacement of Warp3D Library I do not need to contact A-EON. I would need to contact you if I wanted to write an official driver.

After all you did here and wrote (both in public and in email to my developer) I would be CRAZY to put it on official library. Had you reacted in a different way, it might be otherwise. But your reaction strengthened all my fears about it.

If this rests your worries - I now edited the wording of the campaign to remove the word "Warp3D".

@kolla

Thanks, I was indeed not aware of Orange Pi3 to be such different.

@Karlos

i agree with you

For me it hears like old people fighting about who own, what name right on what. it brings much talk but no solution, yes in old times all was better (blalbla)

fact is that new drivers will improve what we have. to hold on old ip to interact against is like coroprate thinking still in 90s.

to be true i would not take help from anybody and code from 0 all new, becouse it will escalte sooner or later again about code snippets that were used.

to say another true, people pay for the drivers... so hell give them what they pay for. sadly that AEON or AmiKit did not pay for new drivers and let me guess who will later use the opensource for there products.

People have just enough of this comercial usage of Amiga and/or retro at all, the love for there systems is used to get into there pockets and at end, the only good products the last years, are these that were made by Fans for Fans.

Last edited by manga303 on 20-Jan-2025 at 06:37 PM.

@manga303

It's a misunderstanding in this case. Nobody is stealing anyone else's bucket and spade.

_________________
Doing stupid things for fun...

@matthey

Quote:

Debugging is so difficult on PPC that bugs were not found and fixed but rather kludges were added as replacements. https://wiki.amigaos.net/wiki/UserDoc:Warp3D#Configuration

As "kludges" go, that was a good one, even if I don't say so myself :p

When I fired up the gaming PC back then, my Nvidia drivers did exactly the same thing, albeit with a nice user interface. I could tweak all sorts of 3D parameters for every installed game and for some older ones I had to.

The fact is that you can't just fix a bug in a driver that is found found in a new application that an old application now depends on to work correctly, especially when there is no chance that the old application will ever be fixed. You either implement some sort of multiple driver versions installed at the same time mess (which is absolutely not practical for a multi component library framework), or you find a way to support the older application when fixing the bug(s) it depends on that kick in only for that application when it runs.

So that's what I did. Contrary to your claim, the bugs *were fixed* and you have to enable the "bug" behaviour as a feature for your incompatible-but-nobobody-will-ever-fix-it-now application. It's explained in the very documentation you linked to. Which I also wrote :p

Last edited by Karlos on 20-Jan-2025 at 07:45 PM.
Last edited by Karlos on 20-Jan-2025 at 07:40 PM.
Last edited by Karlos on 20-Jan-2025 at 07:39 PM.
Last edited by Karlos on 20-Jan-2025 at 07:39 PM.

_________________
Doing stupid things for fun...

@MagicSN

A-EON and AmigaKit are looking foward to a Pistorm 3D driver being developed and offered free of charge for users in the near future. It will push the Pistorm in new directions and opens opportunities for A-EON software to be ported for Pistorm. For some years AmigaKit has been manufacturing and distributing Pistorm at low prices supporting the project's growth in users.

As mentioned several times, A-EON is more than happy to support an official Warp3D driver without monetisation or royalties.

I take it from your comments, that you are now considering a different name for the Pistorm 3D driver, which is welcome. 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. Hans De Ruiter has already expressed a better way of implementation in this very thread.

Regarding your comments about a cleanroom environment: it is taken on trust that both you and the developer does not have access to the original Warp3D source code in Hyperion's source code repository.

Last edited by amigakit on 20-Jan-2025 at 07:52 PM.
Last edited by amigakit on 20-Jan-2025 at 07:51 PM.

_________________
Amiga Kit Amiga Store
Links: www.amigakit.com | New Products | A600GS

Counterfeit?

ROFLMAO.

You can't just say things like that, I almost drowned in my tea.

Quote:

Hans De Ruiter has already expressed a better way of implementation in this very thread.

You did read what he said, right? In detail, I mean? Implement the driver in the framework so that you can have a "proper" one that sits beside the other components (that you don't need) and solve all the problems the unmaintained framework throws in your face by bypassing it, at least where you can. All this simply to avoid having a single file solution instead because the (future) potential of having separate versions of that one file for different hardware configurations is his actual main objection. Despite the fact we are all used to having hardware tuned libraries for countless other things.

I must be reading a different thread or something.

Last edited by Karlos on 20-Jan-2025 at 08:22 PM.
Last edited by Karlos on 20-Jan-2025 at 07:59 PM.

_________________
Doing stupid things for fun...

@Karlos

Wrong choice of words, I have changed it.

_________________
Amiga Kit Amiga Store
Links: www.amigakit.com | New Products | A600GS

@amigakit

Clearly we aren't going to agree on the approach. I hope you don't take my position as antagonistic to you, your business or your products. Far from it.

I just think some things are worth standing up for. If someone has a clean room solution that is fully open, it's the most logical way forwards. Especially when dealing with what is in truth a completely legacy stack.

I've benefitted directly from other people's open work and some may even have benefitted from mine. Once you get into that, there's no going back.

For the avoidance of doubt, I shalln't be doing any implementation for this, because I have worked on the code (albeit well before it was AEONs IP), I do respect the IP holder's rights and have no desire to jeopardise the project.

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

_________________
Doing stupid things for fun...

@amigakit

Quote:

amigakit wrote: @Karlos Wrong choice of words, I have changed it.

Respectfully, while I acknowledge the gaffe and your change of wording, I do think the original wording sums up your real feelings about it. A counterfeit is an illegal duplicate that is passed off as the original. That is absolutely not what is being proposed by anyone: a reimplementation is not a duplicate, it's a work-alike.

As someone else observed that you are creating replacement system libraries for some of your products in order to make them more functional and performant. Did you reach out to / seek permission from the respective IP holder(s) of the components you modify/replace to do that?

_________________
Doing stupid things for fun...

@Karlos

at end it is always about money... what should a lawcase else bring ? justice

@manga303

Sometimes I think Amiga is the dog that bites its own tail.

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

@Karlos

Quote:

Karlos wrote: @matthey Quote: Debugging is so difficult on PPC that bugs were not found and fixed but rather kludges were added as replacements. https://wiki.amigaos.net/wiki/UserDoc:Warp3D#Configuration As "kludges" go, that was a good one, even if I don't say so myself :p When I fired up the gaming PC back then, my Nvidia drivers did exactly the same thing, albeit with a nice user interface. I could tweak all sorts of 3D parameters for every installed game and for some older ones I had to. The fact is that you can't just fix a bug in a driver that is found found in a new application that an old application now depends on to work correctly, especially when there is no chance that the old application will ever be fixed. You either implement some sort of multiple driver versions installed at the same time mess (which is absolutely not practical for a multi component library framework), or you find a way to support the older application when fixing the bug(s) it depends on that kick in only for that application when it runs. So that's what I did. Contrary to your claim, the bugs *were fixed* and you have to enable the "bug" behaviour as a feature for your incompatible-but-nobobody-will-ever-fix-it-now application. It's explained in the very documentation you linked to. Which I also wrote :p

Nvidia Profile Inspector gives better game profile control for the end user e.g. manual ReBar enable per game, manual profile selection per game, and 'etc' before NVIDIA's monthly driver updates.

https://github.com/Orbmu2k/nvidiaProfileInspector

_________________
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

@amigakit

Quote:

We are hopeful you will not produce a duplicate "warp3d.library" as that will confuse users

Really? Is this ... wisdom ... based on your own experience with producing duplicates of OS components by any chance?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@ppcamiga1

Quote:

ppcamiga1 wrote: @Hammer szulc fool you. what you wrote is pure bs. uae also has JIT since year 2000.

Transmeta Code Morph also has a JIT decode cache.

Modern X86 CPUs have uOp cache cache e.g. AMD Zen 4's op cache can hold 6.75K micro-ops.
The Op Cache is crucial because it stores pre-decoded micro-operations (uOps). When instructions are fetched repeatedly (such as in loops), the CPU can pull these uOps directly from the Op Cache instead of decoding the instructions again.

This is particularly beneficial in architectures like x86, where decoding is complex due to variable-length instructions. Instead of re-parsing and re-decoding instructions every time they are executed, the CPU can skip this step by grabbing the micro-operations from the Op Cache, improving the overall efficiency of the pipeline.


ARM Cortex A78 has a 1.5K macro-OP (MOPs) cache.

Intel Skylake has a 1.5K entry micro-op cache.

Reference
https://www.computerenhance.com/p/esoterica-next-gen-x64-cores-and
Next-gen x64 Cores and Micro-op Caches


https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F52cc9f7e-afd3-463f-abed-9d697ab44e69_1920x1080.webp
1. Zen 5 SMT CPU core gives each thread a four-wide decoder pipe, hence there are two four-wide decoder pipes.

2. 33 percent increase in micro-op cache dispatch rate. i.e. Zen 5's 12 per cycle vs Zen 4's 9 per cycle.

_________________
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:

You did read what he said, right? In detail, I mean? Implement the driver in the framework so that you can have a "proper" one that sits beside the other components (that you don't need) and solve all the problems the unmaintained framework throws in your face by bypassing it, at least where you can. All this simply to avoid having a single file solution instead because the (future) potential of having separate versions of that one file for different hardware configurations is his actual main objection. Despite the fact we are all used to having hardware tuned libraries for countless other things. I must be reading a different thread or something.

That's because you're interpreting everything that I wrote in a manner to suit your own arguments. It almost felt like you were arguing with yourself, not me.

Warp3D drivers aren't required to use the GFX drivers (e.g., the Warp3D P96 one). You can simply choose to NOT use it. Zero effort is needed to "bypass" it. I did NOT need to work around bugs, limitations or other problems.

This includes this item from matthey:
Quote:

Debugging is so difficult on PPC that bugs were not found and fixed but rather kludges were added as replacements. https://wiki.amigaos.net/wiki/UserDoc:Warp3D#Configuration

The NovaBridge driver works perfectly with every Warp3D program/game/demo we could find, without any ENV vars or bug workarounds. The only exception that I'm aware of is the game Payback, and debugging showed that was caused by bugs in its Warp3D engine, and NOT the drivers.

Hans

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

@Hans

Not quite. You said your yourself you provided external dependencies to replace the functionality of those libraries. The responsibility of those libraries include memory allocation/deallocation and locking. I don't recall exactly but there may have been others too (card identification etc). Which is fine when you are in a position to be able to do that.

Most of the legacy drivers I saw regarded the main warp3d library as a trampoline directly into a hardware library driver for all the other rendering functionality.

If the HW driver takes over all the key responsibilities that were provided by the gfx driver then there's really not a great deal left in the main library to worry about. Even all the indirect rendering management was dropped in v5, which is one key responsibility it used to have that wasn't delegated to the hardware driver. Almost every remaining W3D_X library call forwards to a W3DHW_X implementation for it. Sure there's still a bit of state management and capability query logic and maybe the old screen requester for applications that rely on W3D itself to provide a screen mode but I don't recall many at all, and it's nothing you couldn't just incorporate into a monolith build.

You said that the main reason was to avoid having multiple different versions of the main library, but when the main library itself is reduced to a trampoline and you only have a single hardware driver installed to deal with, really and honestly, what purpose does it serve?

We are only discussing a single variation for now - for the CM4 videocore. But let's imagine the project increased and people began adding other targets and we have versions for Pi3 Radeon R200, whatever else, for all those other legacy combinations people have no existing driver for.

Why are multiple versions of the main library even an issue to be avoided? Who hasn't installed a version of a library specific to their CPU? Have we been reduced to the level of Mac users or something?

You don't give any justification for why this should a problem, you just imply that it is.

_________________
Doing stupid things for fun...

@amigakit

you are benefitting from open source in your recent projects so you should be more supportive in my view

I still do not understand what you debate about

On 68k there was Warp3D/Stormmesa from H&P where Warp3D is for lowlevel stuff. Later there was Wazp3D/Stormmesa2010 that was a clean room updated version where you simply renamed it to warp3d.

Later Aeon acquired source codes and updated it to "Nova" but only on PPC (4.X). I am not aware of any 68k support announced. Now if this library is called something else like it was wazp3d and clean room and people simply rename it themselves problem is solved. Everybody knows that "nova" from enhancer package is something different. I do not understand how you think anyone not knows the difference

@Hans

The env issue you referenced is a strawman argument. The reason they were needed for P2 is because there were plenty of applications for Permedia that *did not work* properly since Heretic 2 update came along and hacked a faked blending mode to the driver. The most obvious example was Wipeout2097 which no longer rendered properly or Hereric2 which no longer rendered properly. Hardware that properly supported the full set of blending modes never had the issue in the first place which is why "all the other stuff worked" is to be expected. A similar bug was the shadow which used a chroma test, which was actually broken in the high level library (the assumed format was incorrect), fixed by someone and then left the game broken again on other cards.

The issue is grossly overstated. Almost every other option you can set env overrides for are performance related, for the tinkerers to enjoy, including myself.

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.

Last edited by Karlos on 21-Jan-2025 at 09:31 AM.

_________________
Doing stupid things for fun...