|
|---|
| | 
Thierry Atheist
Posts 644
10 May 2017 23:21
| Andrew Copland wrote:
| | This is the basic idea behind a raymarcher -> http://iquilezles.org/www/material/nvscene2008/nvscene2008.htm |
There's a link on that page to a PDF titled:"Rendering Worlds with Two Triangles with raytracing on the GPU in 4096 bytes"
PDF link EXTERNAL LINK
The presentation (link is on same page) is actually a demo with slides and realtime images. You can download it (zip file) from EXTERNAL LINK
| |
| | 
Andrew Copland
Posts 113
11 May 2017 08:47
| Yeah a path tracer is never going to be quick, it's not quick even running natively :) The commandline raymarcher I just uploaded will be slow as hell too at the current resolution, I'll have to make the configurable, add upscaling support back in.
| |
| | 
A1200 Coder
Posts 74
11 May 2017 14:24
| Let's not get too carried away by my earlier comment about the badness of 68060. I'll try to be brief here.
Quake 1/2 has been ported to AGA Amigas, but they both require an overclocked 68060 to run well (75-80 MHz), i.e. a standard 68060/50 MHz is not enough. Also, Quake approximates perspective correct texture mapping, and some other approximations may have been made in the port to Amiga to make it run fast enough. 68060 FPU is relatively weak (no pipelining) in comparison to e.g a Pentium FPU. Strong points of 68060 is the integer performance, like multiply and bit shifting, which are needed in fixed point arithmetic. But there are some other details that makes fixed point arithmetic more difficult on 68060, like no hardware support for 64-bit muls and divs (like earlier CPUs had), and also 68060 still has good performance with mixed CPU/FPU code.Since the Quake code was done originally with an FPU in mind, it was sensible to also use FPU on 68060 in the port. I saw a comment somewhere that some parts were tried to be optimimized with fixed point arithmetic, but no speed gains were observed. I don't have the source code, so cant comment in more detail. The comment about using MMX instruction set for texturemapping was interesting, but MMX was not available for earlier Pentium models, so an FPU was first used, like in Quake. I'm also not against an FPU in apollo core, it seems like some people want it badly, because of the recent success in porting Quake to Amiga. Ultimately, the performance then depends on how well the system is able to handle mixed code, with CPU/FPU/AMMX instructions to get best possible throughput, and how easy it is to handoptimize this. Intel CPUs had some issues with both CPU/FPU and MMX/FPU instruction mixes, but I don't know much about this.
| |
| | 
Jan Vonka
Posts 60
11 May 2017 15:22
| Last weekend I was demonstrating Vampire 500v2+ on our local Amiga party as the first piece in our country, so it was a premiere for Czech Republic. Of course I demonstrated games, mac emulator and riva video player. But demonstration of demos was the hardest thing for find a demos that really work. Most of the RTG supporting demos required FPU, so only few were working. Anyway presentation was successful and I am happily waiting for Gold3 core. Then I wish FPU will be enabled in the next cores.
| |
| |
Andrew Copland
Posts 113
11 May 2017 15:38
| Something I read the other day about the A3000+ by dave haynie (http://www.bigbookofamigahardware.com/bboah/product.aspx?id=24) With the line:
| The DSP3210 could do some floating point operations (single precision only) ten times faster than the 68040. |
The PS2 had VU0 & VU1 (https://en.wikipedia.org/wiki/PlayStation_2_technical_specifications#Central_processing_unit) for doing geometry transforms/processing. A 3D engine is a good use case and one of the reasons the Amiga doesn't have a lot of them is because there's no FPU that can do instructions in parallel with integer code. If you guys just drop the extended registers from 80bit to 64bit you'd have the FPU most of us want/need. I doubt any programs would even notice. Also using Quake would save us from having to write an entire 3D game just to show you that it was worth it ;)
| |
| | 
John William
Posts 563
11 May 2017 16:22
| Andrew Copland wrote:
|
Something I read the other day about the A3000+ by dave haynie (http://www.bigbookofamigahardware.com/bboah/product.aspx?id=24)
With the line:
| The DSP3210 could do some floating point operations (single precision only) ten times faster than the 68040. |
The PS2 had VU0 & VU1 (https://en.wikipedia.org/wiki/PlayStation_2_technical_specifications#Central_processing_unit) for doing geometry transforms/processing.
A 3D engine is a good use case and one of the reasons the Amiga doesn't have a lot of them is because there's no FPU that can do instructions in parallel with integer code.
If you guys just drop the extended registers from 80bit to 64bit you'd have the FPU most of us want/need. I doubt any programs would even notice.
Also using Quake would save us from having to write an entire 3D game just to show you that it was worth it ;)
|
I like how you think :D
| |
| | 
Tango One
Posts 102
11 May 2017 16:36
| Andrew Copland wrote:
|
Something I read the other day about the A3000+ by dave haynie (http://www.bigbookofamigahardware.com/bboah/product.aspx?id=24)
|
If you watch Dave Haynie's movie "Deathbed vigil" movie think it is after 3-4 min he shows that cbm in 1993 did have many projects like A3000+ that was "design but dont build". Did watch it last night, makes me very depresed everyhtime I watch it.
| |
| | 
Crow Mohikan
Posts 78
11 May 2017 19:29
| I am happy somebody doing something for this machine . Software or hardware side. I dont want to see this machine dead.
| |
| |
Andrew Copland
Posts 113
13 May 2017 15:33
| New version, converted to C now EXTERNAL LINK
When compiled takes two paramters, the start frame and the end frame, inclusive, which means that the parameters (0 60) will produce 61 frames total whereas (0 59) will produce 60 frames in total. I can't take it any further on Amiga as I'm not setup for development on one.
I bet the Amiga C compilers will have their own quirks that won't allow it to compile at first however anyone with a tiny bit of knowledge of C should be able to fix up any issues. Andy
| |
| |
Andrew Copland
Posts 113
14 May 2017 09:26
| Gunnar, Something occurred to me the other day, you have this fully working FPU right now (yes?) and you've already tested it and know it works (yes?). Ok, so on the PC we don't acutally use the FPU anymore, or on Xbox360/One, or on PS3/4. Even when we do FPU math we do it all in SSE2 (SIMD). The FPU we want ideally is a 32-bit single precision FPU with pipelining and lots of registers ... multiplied by 4
So, and I've suggested this before, something like the VFPU:
EXTERNAL LINK http://hitmen.c02.at/files/yapspd/psp_doc/chap4.html#sec4.5
EXTERNAL LINK EXTERNAL LINK
Perhaps without the broken ulv instruction obviously ;) My first thoguht was that this won't fit in the FPGA, however I'm not actually suggesting having 4 FPU units ganged together. You can stil get a lot of benefit from having VFPU/SSE2 style instructions by pipelining the operations.
A SIMD block of 4 FPU operations can better fill the pipeline than trying to code to arrange 4 FPU operations. The next thing is that this doesn't have to be in this generation of FPGA at all.
With the PC, PPC, MIPS, ARM etc they all started by introducing weak SIMD units (MMX, 3DNow!, SSE1) and letting them coexist for a very long time until compilers stopped using the FPUs at all. Now they're just for legacy software or in case things are explicitly compiled for them. What all this waffling means is that:
1) You have a legacy FPU, right now, that does exactly what everyone wants.
2) You could cut it down to handle future improvements but that breaks some compatibility AND it doens't give us what we want.
3) You could afford to introduce a much smaller 32-bit SIMD with lots of registers and new instructions which _IS_ what you and we want. You've already laid some of the groundwork with AMMX for new custom CPU features. I think it'd be better to continue that. Put in the existing 80-bit FPU you've already got.
Add in 32-bit single precision FPU/SIMD in the future.
| |
| | 
Gunnar von Boehn
(Apollo Team Member)
Posts 6219
14 May 2017 10:38
| Andrew
we are working on a design with 12 digit FLOPS performance.
I'm happy to share you the details, lets talk about this offline.
| |
| | 
Javier R. Santurde
Posts 16
14 May 2017 12:22
| Only a simple question.
Will the fpu you are working on be available for the current vampire v500/v600?
If the answer is yes then there is no problem.
If answer is no then you say current users never can use their classic fpu programs.
Will be good to know.
In the other side...I think your work is fantastic. The best thing Amiga has had in the last decades.
| |
| | 
Chris H
Posts 65
14 May 2017 13:50
| Gunnar always mentioned and said many times that you should only buy the Vampire 2 if you are good with the features it provides right now. People who are not good with this should not buy Vampire 2. You can speculate about future Core Updates and maybe get what you're still missing, but this is not sure or promissed at all. Thats how I see it. Myself I am good with it and already have a Vampire 600 and a Vampire 500+, received last week from majsta. Thats all I can do for now, next to some testing and start coding again to support the team. I am back to Amigaland and very glad to see the Amiga rising again, thanks to people like Gunnar and all the others supporting Apollo Team.
| |
| |
Andrew Copland
Posts 113
16 May 2017 15:01
| Gunnar von Boehn wrote:
|
I'm happy to share you the details, lets talk about this offline.
|
Happy too, do you still have my email address from Natami days?
| |
| | 
FRAXINOUS Eric
(Needs Verification)
Posts 48/ 1
18 May 2017 12:53
| Javier R. Santurde wrote:
|
Only a simple question.
Will the fpu you are working on be available for the current vampire v500/v600?
If the answer is yes then there is no problem.
If answer is no then you say current users never can use their classic fpu programs.
Will be good to know.
In the other side...I think your work is fantastic. The best thing Amiga has had in the last decades.
|
Maybe, the good question shall be : Is a 68882 emulator exists on AmigaOS ?
It's not very important to have it on FPGA if we can use emulator which works.
| |
| | 
Roman S.
Posts 149
18 May 2017 13:33
| No, it doesn't. And even if it did, it would be much slower than real FPU.
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6219
18 May 2017 14:07
| The MAC OS did have a SoftFPU.Roman S. wrote:
|
No, it doesn't. And even if it did, it would be much slower than real FPU.
|
On a with CPU (68080) a SoftFPU can be faster than an old 68881 FPU.
| |
| |
Roman S.
Posts 149
18 May 2017 19:13
| 68881? Probably just about everybody upgraded to 68882, which can run twice as fast. And the 68040 FPU is something like 10 times faster than 68882...
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6219
18 May 2017 21:57
| Roman S. wrote:
|
68881? Probably just about everybody upgraded to 68882, which can run twice as fast. And the 68040 FPU is something like 10 times faster than 68882...
|
You miss the point.
The point of the SoftFPU is enabling all Software requiring an FPU.
And the SOFT-FPU did this even with speed of the 68040 as basis.
Apollo is in the order of 5 times faster than the 68040 - so this works even better now.
| |
| |
John William
Posts 563
18 May 2017 22:13
| Gunnar von Boehn wrote:
|
Roman S. wrote:
|
68881? Probably just about everybody upgraded to 68882, which can run twice as fast. And the 68040 FPU is something like 10 times faster than 68882...
|
You miss the point.
The point of the SoftFPU is enabling all Software requiring an FPU.
And the SOFT-FPU did this even with speed of the 68040 as basis.
Apollo is in the order of 5 times faster than the 68040 - so this works even better now.
|
Ok...where is the SoftFPU? Where can I download it?
| |
|
Information about the Apollo CPU and FPU.