Is it possible to write hardware renderer for Wazp3D?

[alexh]

Originally Posted by thellier

i dont have any clue about: how to call native OS from within the emulation ?

There isn't one for Emu68. It's exposes the RPi hardware addresses to the 68k effectively as a Zorro III card and you "port" the Linux RPi 3D driver to AmigaOS 68k. as if it was a card plugged in.

To know exactly how Emu68 exposes the VideoCoreIV to the Amiga, addresses etc. you'd need to talk to the Emu64 developer MShultz.

Originally Posted by thellier

what to provide the Raspberry PI as 3D driver? is it basic OpenGL driver or something else ?

The Raspberry Pi is just translating code from 68k to ARM and mapping address X to address Y including register writes, DRAM writes and VRAM writes etc.

This is a monster task because the author needs to work with MShultz to discover Emu68 functionality then the RPi community to work out how the VideoCore IV/VI works (at least how the linux side works) and then the AmigaOS community for 2D/3D driver writing.

The number of users with a PiStorm32 is growing. I imagine almost every A1200 user will have one soon. At under £100 for a basic setup you'd be mad to buy anything else.

[VladR]

Originally Posted by alexh

There isn't one for Emu68. It's exposes the RPi hardware addresses to the 68k effectively as a Zorro III card and you "port" the Linux RPi 3D driver to AmigaOS 68k. as if it was a card plugged in.

To know exactly how Emu68 exposes the VideoCoreIV to the Amiga, addresses etc. you'd need to talk to the Emu64 developer MShultz.

Emu68 is one path. Another would be talking to the VideoCore IV directly.

Is there any known documentation on how to get access to the rPi from within AmigaOS ?
Zorro remapping seems like the best approach - but there has to be a way how to access the HW directly, even from within 68000 code.
There must be some sort of HW register/address mapping available, no ?

Originally Posted by alexh

The number of users with a PiStorm32 is growing. I imagine almost every A1200 user will have one soon. At under £100 for a basic setup you'd be mad to buy anything else.

Exactly. Within a year or two, this will surpass the combined number of all other active HW extensions on Amiga.

[VladR]

Originally Posted by eXeler0

Not that it is necessarily convenient from a wazp3d perspective, but there are already some hardware solutions out there based on ARM that are meant to be used as coprocessors (The ZZ9000, the Warp-cards etc). From that perspective it would be nice if there was a driver that could do something useful like 3d calculations etc on those ARM CPUs.

Indeed. Unfortunately, the number of those cards in the wild is pretty low compared to rPi, so it doesn't make much sense to invest years of dev into it.

In theory, if you just used C, you could have the same shared codebase and just recompile it for different ARM targets, but it's not that simple. Just spending half a day at ZZ9000 docs reveals that it requires a very peculiar upload of the code, so in the end you just have to hardwire everything to ZZ9000's workflow and not much of that would be applicable on other ARMs.


rPi is the only one which makes remotely any sense to devote coding time towards.

[eXeler0]

Originally Posted by VladR

Indeed. Unfortunately, the number of those cards in the wild is pretty low compared to rPi, so it doesn't make much sense to invest years of dev into it.

In theory, if you just used C, you could have the same shared codebase and just recompile it for different ARM targets, but it's not that simple. Just spending half a day at ZZ9000 docs reveals that it requires a very peculiar upload of the code, so in the end you just have to hardwire everything to ZZ9000's workflow and not much of that would be applicable on other ARMs.


rPi is the only one which makes remotely any sense to devote coding time towards.

Fair enough, warp cards arent plentyful either unfortunately, and they also use some other ARM variant.

[VladR]

Originally Posted by eXeler0

Fair enough, warp cards arent plentyful either unfortunately, and they also use some other ARM variant.

Is 250-500 Warp active cards out there a reasonable estimate ? What do you think ?

Meaning, in terms of HW accelerators, would Warp cards place 2nd ?

[eXeler0]

Originally Posted by VladR

Is 250-500 Warp active cards out there a reasonable estimate ? What do you think ?

Meaning, in terms of HW accelerators, would Warp cards place 2nd ?

on paper Warp cards have a lot of good things going for them, but questions about availability so I dont have a good guesstimate.. Devs seemed very active for a while but then things slowed down due to devs needing to focus on other stuff.. so I dont knowvthe status of software maturity for the extra stuff , may be also lagging a bit (also, pricing and ordering procedure, where you need to post your expensive 060 to Poland for assembly..)
Someone with a warp 1260, could commentnon how it works in 2024?

I got a BFG9060 for my A4000 instead and there you have the space to put proper cooling on so the rev6 runs 100MHz permanently overclocked easy. Otherwise, the Warp has the best cooler of all A1200 cards. Its specifically designed to fit in the tight space under the keyboard.

[Hedeon]

I thought the Warp guys made it very clear that the ARM cores were not freely accessible.

[VladR]

Originally Posted by Hedeon

I thought the Warp guys made it very clear that the ARM cores were not freely accessible.

You mean to upload custom code or HW availability ?

[thellier]

Originally Posted by alexh

There isn't one for Emu68. It's exposes the RPi hardware addresses to the 68k effectively as a Zorro III card and you "port" the Linux RPi 3D driver to AmigaOS 68k. as if it was a card plugged in.
.

You mean we only see the RPI hardware registers in a Zorro card memory page so we need to write a whole 3D driver that use only registers = that is an HUUGE task, almost impossible to be done

I was hoping that the Zorro III card will give access to a more high level functions from the RPI like functions for drawing 3d triangles

Edit: it will need a smart desassembleur/decompiler/resource to automatically convert the RPI 3d driver to a 68k one that will be usable Amiga side
Edit: something that will convert each RPI asm instructions to their C code equivalents then that could be recompiled to 68k binary with all compiler optimisations options to remove the extraneous code

[alexh]

Originally Posted by VladR

Emu68 is one path. Another would be talking to the VideoCore IV directly.

Erm, that's what you do when you use Emu68... you run 68k code which Emu68 dynamically recompiles into ARM code which accesses the VideoCore directly.

Originally Posted by VladR

Is there any known documentation on how to get access to the rPi from within AmigaOS ?

AFAIK, only the example Picasso96 RTG driver. And talking to Michal Schulz

https://github.com/michalsc/Emu68-to...oCore.card/src

Originally Posted by VladR

but there has to be a way how to access the HW directly, even from within 68000 code. There must be some sort of HW register/address mapping available, no?

??? Yes that's what I said. That is how Emu68 works. It allows you to access RPi HW from 68k code as if it were just in the Amiga address map.

[alexh]

Originally Posted by thellier

You mean we only see the RPI hardware registers in a Zorro card memory page so we need to write a whole 3D driver that use only registers = that is an HUUGE task, almost impossible to be done

But the source code for the VideoCore 3D driver already exists. It has been 100% released. Albeit written for ARM Linux not 68k AmigaOS.

Originally Posted by thellier

I was hoping that the Zorro III card will give access to a more high level functions from the RPI like functions for drawing 3d triangles

Not if you use Emu68.

Originally Posted by thellier

Edit: it will need a smart desassembleur/decompiler/resource to automatically convert the RPI 3d driver to a 68k one that will be usable Amiga side

No. No. I think the idea is to convert the source code VideoCore driver written for ARM Linux to 68k AmigaOS. It is still a huge task.

To put it in perspective I don't think anyone has tried to write a 2D driver which uses the VideoCore 2D HW functions let alone it's 3D functions.

Emu68 exposes RPi HW as if you had plugged it directly into the Amiga via Zorro or Mediator PCI etc.

[frozen]

Originally Posted by thellier

You mean we only see the RPI hardware registers in a Zorro card memory page so we need to write a whole 3D driver that use only registers = that is an HUUGE task, almost impossible to be done

I was hoping that the Zorro III card will give access to a more high level functions from the RPI like functions for drawing 3d triangles

Edit: it will need a smart desassembleur/decompiler/resource to automatically convert the RPI 3d driver to a 68k one that will be usable Amiga side
Edit: something that will convert each RPI asm instructions to their C code equivalents then that could be recompiled to 68k binary with all compiler optimisations options to remove the extraneous code

Hi Alan maybe you can join Pistorm Discord to talk with MShulz and Claude about this?
There are already some interesting ideas, maybe check and help, given your skills....

[Mr-Z]

Originally Posted by alexh

To put it in perspective I don't think anyone has tried to write a 2D driver which uses the VideoCore 2D HW functions.

Michal already showed a proof of concept quite some ago using VPU for 2D accel on PiStorm/Emu68.


See this YT video he made:

[ Show youtube player ]

[frozen]

Originally Posted by frozen

Hi Alan maybe you can join Pistorm Discord to talk with MShulz and Claude about this?
There are already some interesting ideas, maybe check and help, given your skills....

And I was the guy who asked you time ago, via email, if you were available for a possible porting of Mesa to AOS3.....

[thellier]

Yes but I almost no more coding
Last time I coded seriuously it was at Covid start, so some years ago

Recently I have tried to make a Wazp3D for Maggie3D for Vampire (so hardware accelerated) but I didnt finished it (bugs in cube,quake,glexcess.... + perspective texturing is not implemented)
Also I am currently trying to recompile the recent WipeOut port to make it use directly Warp3D (not OpenGL) but it progress very slowly (perhaps one hour per day)

I think I have no more the courage to dig into thousands of line of code anymore to find vicious bugs

So I am sure I will not engage in such a big project as the Pistorm 3D driver

[hammer]

[ Show youtube player ]
A500's PiStorm-Emu68-RPi 3A+ work-in-progress Warp 3D hardware acceleration test for Broadcom VideoCore 4 for GLQuake, Quake 2, and Quake 3.

[Seiya]

Quake II seem fast enough to excellent play in high resolution

[paraj]

Yeah, so I wrote the "WIP" driver, and it does use the VC4 chip (only on pi2/3, pi4 has a the newer VC6). It does work, but since the chip is not used "properly" I've hit a performance dead end and it will have to be reworked, so the project is stalled until I gather appetite again. Code is here: https://github.com/mras0/vc4d in case somebody wants to take over/play around with it.

[alexh]

Out of curiosity is the the driver for 68k? It runs 100% on the 68k side of Emu68? Do you need a particular build of Emu68 which exposes the VC4 to the 68k address space?

I'm not going to try it, I'm just curious how it works.

Well done BTW.

[paraj]

Originally Posted by alexh

Out of curiosity is the the driver for 68k? It runs 100% on the 68k side of Emu68? Do you need a particular build of Emu68 which exposes the VC4 to the 68k address space?

I'm not going to try it, I'm just curious how it works.

Well done BTW.

Like all the other pistorm drivers (RTG, sdcard/emmc, etc.) it runs all the driver code on the 68k side. Emu68 exposes the memory mapped I/O to 68k, so all peripherals can at least in principle be used fully by 68k code. No special version required (*).


Now, the actual driver makes use of the fragment/pixel shader HW of the VC4 chip, so there is actually non-68k code in there, but it is all handled Amiga side and uploaded to the VC4, bypassing the ARM processor, so while not 100% 68k I think this is not what you're asking


(*): If/when this works better we may want a special (newer) version to better arbitrate the hardware between different drivers and add proper interrupt support etc, but again this is not a material change to what is already available/possible