|
|---|
| | 
Andrew Copland
Posts 113
10 May 2017 11:30
| A ray marcher would be a good example, I have one I wrote for PC but it will need translating back into C and then to Amiga I guess.
| |
| | 
Marcus Sackrow
Posts 37
10 May 2017 11:44
| Gunnar von Boehn wrote:
|
Vojin Vidanovic wrote:
|
Since its used in product, he is quite right.
|
You might not know this
the people porting the software,
the people writing new games for amiga,
the people writing documentation for vampires.
Is a very small team which does this for the love of AMIGA in their spare time.
If you want things to be done faster - then step up and offer your help!
|
You missed my point, I agree on that, I agree on the statement that the people should buy a Vampire at the current state not what it maybe will become in the future.
But you or the Vampire team have to make very clear what the people get when they buy it, to give them the possibility to decide that. This is my point, and at them moment it's a little bit confusing. All I ask for is a clear Statement, a single Page. What the people are getting if they decide to get a Vampire at the current State "Gold 2" and maybe more important what they do not get, but maybe expect (like FPU/MMU/AGA ... whatever). And maybe you are not the right target for that critics, but more towards the Vampire team. But you brought that sentence up. :)
| |
| | 
Jari Eskelinen
Posts 23
10 May 2017 11:47
| Two words: expectation management. Apollo Team is doing extraordinary job, but if people expect something else then threads like pop up everywhere. One could argue people are expecting stupid things but on the contrast people could argue that stupid things is being delivered.
Everybody is right from their perspective but since Apollo Team leads the show they go to decide. It is just that simple expectations management could instantly put end to all arguments.
To contribute something, I've re-compiled mpega_libmad to work without FPU and uploaded it to Aminet. That's best I can do as I am no software developer. I could write end user documentation as well but Apollo Accelerators Public Wiki is not open so...
| |
| | 
Gunnar von Boehn
(Apollo Team Member)
Posts 6220
10 May 2017 12:15
| Andrew Copland wrote:
|
A ray marcher would be a good example, I have one I wrote for PC but it will need translating back into C and then to Amiga I guess.
|
Hi Andrew,
You surely have the skill for this.
If you like to do this, then lets discuss details.
I will surely support you.
I hope its clear that the demo needs be coded in ASM.
| |
| | 
Obetto Sannala
Posts 61
10 May 2017 13:12
| Hello, I am a compiler.
I just scanned thousands of lines of code while you were reading this sentence. I browsed through millions of possibilities of optimizing a single line of yours using hundreds of different optimization techniques based on a vast amount of academic research that you would spend years getting at. I won't feel any embarrassment, not even a slight ick, when I convert a three-line loop to thousands of instructions just to make it faster. I have no shame to go to great lengths of optimization or to do the dirtiest tricks. And if you don't want me to, maybe for a day or two, I'll behave and do it the way you like. I can transform the methods I'm using whenever you want, without even changing a single line of your code. I can even show you how your code would look in assembly, on different processor architectures and different operating systems and in different assembly conventions if you'd like. Yes, all in seconds. Because, you know, I can; and you know, you can't.
P.S. Oh, by the way you weren't using half of the code you wrote. I did you a favor and threw it away.
| |
| | 
Saladriel Amrael
Posts 166
10 May 2017 14:25
| Obetto Sannala wrote:
|
Hello, I am a compiler.
I just scanned thousands of lines of code while you were reading this sentence. I browsed through millions of possibilities of optimizing a single line of yours using hundreds of different optimization techniques based on a vast amount of academic research that you would spend years getting at. I won't feel any embarrassment, not even a slight ick, when I convert a three-line loop to thousands of instructions just to make it faster. I have no shame to go to great lengths of optimization or to do the dirtiest tricks. And if you don't want me to, maybe for a day or two, I'll behave and do it the way you like. I can transform the methods I'm using whenever you want, without even changing a single line of your code. I can even show you how your code would look in assembly, on different processor architectures and different operating systems and in different assembly conventions if you'd like. Yes, all in seconds. Because, you know, I can; and you know, you can't.
P.S. Oh, by the way you weren't using half of the code you wrote. I did you a favor and threw it away.
|
I Guess Gunnar says so because there are still no compilers capable of optimizing code for Apollo FPU
| |
| |
Obetto Sannala
Posts 61
10 May 2017 14:28
| I was kidding...
| |
| | 
Kolbjørn Barmen
(Needs Verification)
Posts 219/ 2
10 May 2017 14:31
| http://web.archive.org/web/20140516224526 EXTERNAL LINK "Optionally, a fully pipelined, double precision FPU is available to be included in the Core."
_IS AVAILABLE_ (May 2014)
This line was later (march 2016 or so) removed.
| |
| |
Andrew Copland
Posts 113
10 May 2017 14:42
| Gunnar von Boehn wrote:
|
You surely have the skill for this.
If you like to do this, then lets discuss details.
I will surely support you.
I hope its clear that the demo needs be coded in ASM.
|
I can rewrite it as a bare bones C version, but I haven't done 68k ASM in ... nearly 20 years?I'm sure there are 68k wizards on here who could transform the core loops and maths to asm quickly enough as they'd have the C version to use a reference. The core of a raymarcher is just two loops with a piece of maths in the middle outputting a pixel. It's the maths in the middle that does all of the magic and hard work, hence why it should be a good example for the FPU. I'll look at stripping what I've got down to the core and changing it to C.
| |
| | 
Samuel Crow
Posts 424
10 May 2017 15:27
| Andrew Copland wrote:
|
Gunnar von Boehn wrote:
|
You surely have the skill for this.
If you like to do this, then lets discuss details.
I will surely support you.
I hope its clear that the demo needs be coded in ASM.
|
I can rewrite it as a bare bones C version, but I haven't done 68k ASM in ... nearly 20 years?
I'm sure there are 68k wizards on here who could transform the core loops and maths to asm quickly enough as they'd have the C version to use a reference.
The core of a raymarcher is just two loops with a piece of maths in the middle outputting a pixel.
It's the maths in the middle that does all of the magic and hard work, hence why it should be a good example for the FPU.
I'll look at stripping what I've got down to the core and changing it to C.
|
I need practice writing FPU code anyway. If you write it in C, I'll compile down to Assembly source and pick through the code and see if I can make it better.
| |
| | 
E Penguin
Posts 46
10 May 2017 16:13
| Whilst we're discussing a wish list, can we get an MMU?
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6220
10 May 2017 16:35
| Andrew Copland wrote:
|
The core of a raymarcher is just two loops with a piece of maths in the middle outputting a pixel.
|
Can you tell us more?
What type of math is it mainly?
How many FPU instructions are executed per drawn pixel?
| |
| |
Andrew Copland
Posts 113
10 May 2017 17:13
| I'm just leaving work now to go to gym, I'll try to post it later, mostly muls and adds, a few divs. Easier to show than explain :)
| |
| | 
John William
Posts 563
10 May 2017 21:48
| Wait...does that mean we are going to have FPU?
| |
| |
Andrew Copland
Posts 113
10 May 2017 22:05
| This is the basic idea behind a raymarcher -> EXTERNAL LINK
Like a ray tracer you step through a "scene", the difference is that the scene is defined as a bunch of mathematical functions that define the distance from a point in space to the surface of a primitive shape.
It's the basis of a _lot_ of what you see o EXTERNAL LINK for example.
All of those operate per-pixel/fragment on a GPU of course, but there's no reason you cannot do it on a CPU and I've written a few versions that do that just to practice optimisation techniques, multi-threading, OMP, SIMD etc.
Gunnar von Boehn wrote:
|
What type of math is it mainly?
How many FPU instructions are executed per drawn pixel?
|
What type of math is it mainly?:
--------------------------------
A lot of mul, add, sub, try to avoid div of course. There's also a lot of sin/cos/tan, min/max and abs plus some sqrt's for luck. It covers quite a bit of stuff.
I've ported it to command line and simplified it massively now, written a TGA exporter along with a simple scalar (non-SIMD) vec3 floating point class.
The slow part is converting it back down into C from C++ I wrote it in.How many FPU instructions are executed per drawn pixel?
-------------------------------------------------------
That varies a LOT per-pixel.
When it won't make a collision with anything it can march out of the scene quite rapidly and avoid doing a lot of the work. Or it can go directly into an object and again avoid a lot of work. However if it merely grazes an object then it wastes a huge amount of time doing calculations that don't matter.
For performance I've capped it to 100 steps and a distance through the scene of 100. These are arbitrary values though chosen for the scene in question.
| |
| |
Andrew Copland
Posts 113
10 May 2017 22:22
| Ah, uploaded a gif of the images it outputs
EXTERNAL LINK
And a 7z file with current source code along with 2 compiled WINDOWS exe's, I haven't gotten around to converting it to C (from C++) so no point trying to learn how to cross compile to Amiga yet.
EXTERNAL LINK
Hopefully people can access it from there.There's a readme.txt in there to explain what's what.
| |
| | 
Wawa T
Posts 695
10 May 2017 22:23
| there is an aros raytracer test, they use to demonstrate multicore support. its in c/c++, two source files, but i think it is too heavy and complex a testcase, even for parallel execution. but i can link you to the sources if you like.
| |
| |
Andrew Copland
Posts 113
10 May 2017 22:40
| wawa t wrote:
|
there is an aros raytracer test, they use to demonstrate multicore support. its in c/c++, two source files, but i think it is too heavy and complex a testcase, even for parallel execution. but i can link you to the sources if you like.
|
They're a great use-case, if there's an already semi-native raytracer that can be used that'd be good to have.
| |
| |
Wawa T
Posts 695
10 May 2017 22:55
| Andrew Copland wrote:
|
They're a great use-case, if there's an already semi-native raytracer that can be used that'd be good to have.
|
EXTERNAL LINK
there is also a port of povray in contribs, might be more of it, but isnt there any sources on aminet?edit: you will have to ignore certificat warning. not sure why they cant take care of it..
| |
| |
Wawa T
Posts 695
10 May 2017 23:13
|
[SMP-Smallpt] main: detected 1 CPU cores.
[SMP-Smallpt] main: Created window with inner size of 640x480.
[SMP-Smallpt] main: Tiles amount 20x15.
[SMP-Smallpt] main: Creating renderer task.
[SMP-Smallpt] main: waiting for welcome message form renderer.
[SMP-Smallpt-Renderer] Renderer started, ParentMailBox = 0862db00.
[SMP-Smallpt-Renderer] Sending welcome msg to parent.
[SMP-Smallpt] main: renderer alive. sending startup message.
[SMP-Smallpt-Renderer] Parent replied to welcome msg.
[SMP-Smallpt-Renderer] recieved startup message at 08648938.
[SMP-Smallpt-Renderer] Bitmap size 640x480, chunky buffer at 08667d58.
[SMP-Smallpt-Renderer] Preparing work packages.
[SMP-Smallpt-Renderer] creating 1 workers.
[SMP-Smallpt-Renderer] worker stack size : 1016384 bytes.
[SMP-Smallpt] main: enter main loop.
[SMP-Smallpt-Renderer] all set up, doing work.
[SMP-SmallPT-Task] hello, msgport=086368f0.
[SMP-SmallPT-Task] Just told renderer I'm hungry.
|
abysmally slow even under jit winuae, at least with default setup..
| |
|
Information about the Apollo CPU and FPU.