Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

Vulkan Software Renderer?

Samuel Crow

Posts 424
04 Oct 2018 16:50


EXTERNAL LINK is a software renderer originally written in C++14.  It's being rewritten in Rust for concurrent execution and compile-time memory safety.  Once complete, could the algorithms be used on a V4?  There are lightweight utilities to convert OpenGL ES 2 to Vulkan and, as OS4 users are aware, GL4ES runs most OpenGL software on that.  Granted, it'll likely be dog slow at 114 MHz but it would be a way to look to the future....


Tango One

Posts 102
04 Oct 2018 22:20


oh yes would love to see vulkan api for v4. Vulkan is one of my wet dreams for linux if that could be ported to amiga/vampire then I think we would have a very bright future.


Andrew Copland

Posts 113
05 Oct 2018 14:25


If you want to "look at the future" use a PC running Windows/Linux.
 
If you want 3D rendering on Vampire then write a native software renderer.
 
Vulkan is only a big deal because of the overhead of OpenGL on certain implementations (Gallium, MESA, AMD, Intel etc)


Samuel Crow

Posts 424
07 Oct 2018 06:42


Spir-V bytecode is used by Warp3D Nova as well as Vulkan for a software representation of shaders.  Being able to represent them in as few opcodes as necessary would be the means to a modern graphics pipeline on future cores.

BTW, Andrew, I might have to postpone the purchase of a Vampire board if I were to get an upgraded PC.  My Debian-running Mac Mini is 10 years old this year.


Thellier Alain

Posts 141
08 Oct 2018 09:51


Samuel Crow wrote:

There are lightweight utilities to convert OpenGL ES 2 to Vulkan and, as OS4 users are aware, GL4ES runs most OpenGL software on that.

It is a few too short description

In fact on OS4 there is:

GL4ES use GL-ES that use Nova that also use GLSL shaders compiled as Spir-V bytecode (=Vulkan)

So having a Vulkan virtual cpu is only a small part of the job as Vampire dont have Nova nor GL-ES nor GL4ES

Even if we restrain to the Nova part (that truly do the job of drawings 3d thigs) there is not only the "shader part" that somehow modify the fragments but also Nova itself that truly draw the triangles to obtain fragments.
I mean the shader part is only a part of a 3D engine like Nova

BTW there are also other softwares that claim to do GLSL shaders langage as software
EXTERNAL LINK  EXTERNAL LINK  EXTERNAL LINK 
Talking about shaders when Vampire dont have any 3D driver is really "Mettre la charrue avant les bœufs"

Alain




Samuel Crow

Posts 424
10 Oct 2018 04:34


@Alain
The reason I'm bringing this up is that most high-level drivers are based on some sort of compiler infrastructure to optimize and generate code for shader and buffer entities.  Vulkan leaves most of that up to the engine or higher-level patch codes like the GLOVes patch on GitHub and likewise GL4ES on top of that.  Basing this on simpler drivers like Vulkan makes the driver infrastructure easier to implement than something based on any modern Mesa implementation.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
14 Oct 2018 21:20


It would be really nice to jump straight to Vulkan, and optimize from there. Eventually, SAGA driver could be done, then if we get any 3D helper in FPGA that could be supported, as well as 080-AMMX used to help a bit, leaving as much as possible to OS.
    If done in software, would love to see its core libraries in enhanced Kickstart - making it faster, configurable which to load and responsive even using software mode only.
   
    Now, who is up to the task when all OS4 side of the force with brute RadeonHD cant quite reach there, even they do are oblivious of all other past announced apps?
   
    Lovely-jovely stil waiting for HQ work on Firefox
 
  "Timberwolf is the AmigaOS port of Mozilla’s Firefox browser. Currently, the code is based on Firefox 4.0.1, but we’re working on bringing it up to the latest build (18.0.1 at the time of writing, although 19.x is more likely)."
 
  EXTERNAL LINK  Friedens HQ even now
   
    " The Amiga developer community is also very active and programs like Timberwolf (Firefox) and Open Office are currently being ported to AmigaOS 4"
  Trevor 2010
 
  As well as what x1000 was promised to be
 
  ". Custom chipsets are no longer viable but with the additional of Xena and software defined silicon we can at least have "customisable chips" which will hopefully appeal to Amiga enthusiasts and developers alike."
 
  "It was our hardware partners who originally suggested the X-Core technology. They have a lot of experience working with XMOS products and said "why not add an XMOS chip?" The original Amiga had custom chips, so we decided to give the A1-X1000 "customisable" chips. XMOS calls it "Software Defined Silicon", we call it 'Xena', a nod to the old Amiga custom chip names. It's a cheap addition to the board and in some ways is a gift to the Amiga's geek heritage. It's also the inheritor of the 'transputer' concept, and it's something we're quite excited about. Capable of eight concurrent real-time threads with shared memory space, at up to 500 MIPS, Xena gives the A1-X1000 a very flexible, very expandable co-processor. The uses are endless; control hardware, DSP functions, robotics, display - even SID chip and console emulators."
 
  "In the initial A1-X1000 release, AmigaOS 4.1 will not make use of the second CPU core but this is something that the AmigaOS 4 developers are planning for a subsequent update."
    Trevor May 2010
    EXTERNAL LINK 
* * *

x1000 rant was a demo, CFE is what is really wrong there. I really like OS4 driver developer and have been buying 6870 and 7700 Radeons first time to use em. Paid 2D with x1000, again after FE because they just dont work together, then Enhancer v1.3 with drivers. But when I discovered he asks for more money for old Warp3D driver (not included) promised long timme even for 4xxx - 6xxx and never done there, I just stopped.

So he might bring OS4 and Warp3DNOVA near newest OpenGL. Nice basis, yet there will be just few ports to use it and I dont see Alladin 4D using it any day near. I would, if possible, jump over that fence (Hype owned w3d and p96) and go to real OpenGL if possible. As it always was. May we have to use infamous SiS Xabre chip in FPGA (company seems to be alive and independent) - a half of Radeon 9000 speed and some software tricks, but OpenGL in h/w ... sort of.
EXTERNAL LINK 
What else would be cheap? If nVIDIA released Voodo :-)

Here were some GER discussions of infamous Vodoo 5 6000 in FPGA. Nobody tried!
EXTERNAL LINK 



Samuel Crow

Posts 424
16 Oct 2018 16:08


@Vojin Vidanovic
Thanks for the link to the SiS Xabre.  It looks as if vertex shaders in AMMX are what Gunnar's trying to do also.  If its Windows drivers suck we don't need to care because we'll be using our own.  Here's a review of the Xabre600 card: EXTERNAL LINK 

This would only leave the software end of the vertex shader implementations in AMMX but we'll need an up-to-date compiler infrastructure to implement the actual shaders.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
16 Oct 2018 16:34


Samuel Crow wrote:

      This would only leave the software end of the vertex shader implementations in AMMX but we'll need an up-to-date compiler infrastructure to implement the actual shaders.
     

     
      Yes, I was aware they did dirty magic to hide non implemented hw 3d feats (and used CPU as muscle instead of other way around), but did not know it can go to our behalf. Even I have quite bad memories on SiS cheap components flooding East Europe, I respect anyone willing to fight the big names.
     
      There seems to be Linux drivers EXTERNAL LINK     
    Toms hardware explains it well
 
 
    EXTERNAL LINK   
    "The final consideration, and the point that resonated with us, is that the Xabre 600 scales with processor performance.  Mated to a 3.06GHz Pentium 4, the graphics processor is able to compete. 
    ...
    More likely, the Xabre 600 would find itself in a 2GHz Celeron system or an Athlon XP 1500+ machine.  As indicated by SiS, the performance picture in either situation wouldn't be nearly as optimistic. "
   
    So, we need to optimize that solution rather better :-)


Samuel Crow

Posts 424
16 Oct 2018 21:06


Given sufficient memory bandwidth, an SoC can keep up with a discrete GPU.  In the most extreme case:  EXTERNAL LINK is the chip that drives the XBoxOneX.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
16 Oct 2018 21:44


Samuel Crow wrote:

      Given sufficient memory bandwidth, an SoC can keep up with a discrete GPU.  In the most extreme case:  EXTERNAL LINK is the chip that drives the XBoxOneX.
     

     
      Core and instructions development not affected:
     
      OK wishlist for
     
  2019+    V6: DDR4 system RAM,2MB XDR ROMs ,SiS Xabre 600+, SATA, EIDE 4x buffered, built in scandoubler
     
  2022 + V8: Scorpio Sounds nice :-), Fast low latency DDR5 64 bit RAM soldered to CPU, Firewire, Bluetooth, SCSI/SATA2/EIDE 4x buffered, GDDR6 RAM slot, One Zorro III, one PCI-E 4x. 4MB+ XDR ROMs, scandoubler, DDR4 RAM slot
     
      Does not affect support for v4


Gregthe Canuck

Posts 274
23 Oct 2018 07:36


Updated info: EXTERNAL LINK 


Andrew Copland

Posts 113
23 Oct 2018 11:56


Samuel Crow wrote:

Given sufficient memory bandwidth, an SoC can keep up with a discrete GPU.  In the most extreme case:  EXTERNAL LINK is the chip that drives the XBoxOneX.

No it can't, that SoC contains a GPU.

If you scroll down to the graphics section it lists the Scorpio as having 40 "Compute Units", that's the GPU.
40 graphics oriented processors backed by additional dedicated graphics hardware with 2MB of dedicated ram (on the chip itself) plus other caches.

The example is an 8 core GPU + 40 core GPU + seperate bus for the GPU entirely with additional hardware.


Samuel Crow

Posts 424
23 Oct 2018 17:08


gregthe canuck wrote:

Updated info: https://www.phoronix.com/scan.php?page=news_item&px=Rust-Kazan-Shader-Compiler

Thanks for the update.  I knew Rust is an LLVM based compiler but the fact that the resulting shader compiler uses LLVM insures that it requires more than 512 MiB RAM in its current state.

@Andrew Copland
Thanks for your insight as well.  I had heard that the Scorpio chip was MIMD architecture all the way through so I was hoping some subset of that would be possible through opcode fusion alone.  I was wrong.

@thread
Nothing more to see here, move along.

posts 14