No big deal, just reboot.

You ask for a test case for FPU but I dont see much softwares that use it intensively (even if lots of serious apps for A4000 used more or less the fpu)
So I think there are mainly:

- Modeler/Cad/Architecturing tools that draw huge geometric objects in real time as wireframe
- RayTracers but I dont think the computation are very massive/parallelizable as the ray of light hit several objects (I mean not always the same) and got also lots of "find the hitted face" stuff
- 3D Games but they also draw the stuff textured (so will need Warp3D... ) and do also the lighting so FPU speed will not do all the job

So I dont see much "perfect case" for FPU but I can be wrong

Once said having a multipylymatrices & transformvectors functions especially made for your FPU will allways found a good usage

Something like this but in optimized/pipelined FPU ASM

BTW a transformvectors function is much more used than a multipylymatrices ones that is only used one time per object

This transformvectors can be unrolled to treat several vector per loop

Alain Thellier

/*=================================================================*/
inline void MultM(register float *M1,register float *M2,float *M3)
{      /* multiply 2 matrices to athird matrice */
float M[16];

  M[0 ]= M1[0]*M2[0] + M1[1]*M2[4] + M1[2]*M2[8] + M1[3]*M2[12];
  M[1 ]= M1[0]*M2[1] + M1[1]*M2[5] + M1[2]*M2[9] + M1[3]*M2[13];
  M[2 ]= M1[0]*M2[2] + M1[1]*M2[6] + M1[2]*M2[10] + M1[3]*M2[14];
  M[3 ]= M1[0]*M2[3] + M1[1]*M2[7] + M1[2]*M2[11] + M1[3]*M2[15];

  M[4 ]= M1[4]*M2[0] + M1[5]*M2[4] + M1[6]*M2[8] + M1[7]*M2[12];
  M[5 ]= M1[4]*M2[1] + M1[5]*M2[5] + M1[6]*M2[9] + M1[7]*M2[13];
  M[6 ]= M1[4]*M2[2] + M1[5]*M2[6] + M1[6]*M2[10] + M1[7]*M2[14];
  M[7 ]= M1[4]*M2[3] + M1[5]*M2[7] + M1[6]*M2[11] + M1[7]*M2[15];

  M[8 ]= M1[8]*M2[0] + M1[9]*M2[4] + M1[10]*M2[8] + M1[11]*M2[12];
  M[9 ]= M1[8]*M2[1] + M1[9]*M2[5] + M1[10]*M2[9] + M1[11]*M2[13];
  M[10]= M1[8]*M2[2] + M1[9]*M2[6] + M1[10]*M2[10] + M1[11]*M2[14];
  M[11]= M1[8]*M2[3] + M1[9]*M2[7] + M1[10]*M2[11] + M1[11]*M2[15];

  M[12]= M1[12]*M2[0] + M1[13]*M2[4] + M1[14]*M2[8] + M1[15]*M2[12];
  M[13]= M1[12]*M2[1] + M1[13]*M2[5] + M1[14]*M2[9] + M1[15]*M2[13];
  M[14]= M1[12]*M2[2] + M1[13]*M2[6] + M1[14]*M2[10] + M1[15]*M2[14];
  M[15]= M1[12]*M2[3] + M1[13]*M2[7] + M1[14]*M2[11] + M1[15]*M2[15];

  CopyM(M3,M);
}
/*=================================================================*/
void CopyTransformV(register float *M,Vertex3D* V,Vertex3D* V2,LONG Vnb)
{      /* copy & transform points with a given matrix */
register float x;
register float y;
register float z;
register ULONG n;

  for(n=0;n<Vnb;n++)
  {
  x=V[n].x;y=V[n].y;z=V[n].z;
  V2[n].x= M[0]*x + M[4]*y+ M[8] *z+ M[12];
  V2[n].y= M[1]*x + M[5]*y+ M[9] *z+ M[13];
  V2[n].z= M[2]*x + M[6]*y+ M[10]*z+ M[14];
  }

}

I think you are right.

thellier alain wrote:

- 3D Games but they also draw the stuff textured (so will need Warp3D... )

Drawing might be a good thing.
A "demo" could also draw without any libs.

I think if you see something then the effect is much higher.
Like RIVA the video player.. Just fast decoding the videos and not showing them would have been much less impressive.

Good point(s)...
In a couple of years, even a 10x faster Next Gen 68k Amiga will be slow for future workloads compared even to Raspberry Pie 5 (give or take a version number or similar cheap hardware of the time) so putting a lot of effort into doing "modern stuff" will probably be an interesting challenge for the devs but at the same time, an uphill battle at best - and its mostly motivated with "because why not".
[I](Lets say they could play full 24bit full HD movies at say 20fps.. would be an amazing technical achievement worthy a nobel prize right, but would you watch it there? Or would you watch 8k HDR @60Hz powered by your smartphone.)[/I]

At the same time, this legacy software support issue will be there "forever". What happens with new software in the future is anyone's guess, but the current Amiga user base surely is interested in current software library running as good as it possibly can, no? Preferably on their actual Amiga computers that they once fell in love with - and not only enjoying this ride based on speculative additions that might come at some point in the future.. pending developer interest and commitment.

Hmm.. Its possible we could have both though, right? (both improved legacy and future possibilities  - and maybe in that order :-)

Our project goal are clear.
* Develop most advanced 68K CPU
* Develop Superior AMIGA chipset
* Create good Accelerators for existing AMIGA.
  These Accelerator will unify the AMIGA hardware.
  All AMIGAs using these Accelerators will have
    > 100 MIPS
    > 100 MB Memory
    AGA
    "Infinite" amount of chipmem
    44KHz Audio
    Chunky/HiColor/TrueColor
* Develop Standalone (Natami like) system
  This standalone comes with the same features as the accelerators.

This means software develop which runs on all these system is made easier.

These are our project goals.
FPU is part of these goals.
It goes without saying that all this is a huge amount of work.
Companies have normally teams of hundreds of engineers for this.
Its obvious that the work items need to be prioritized.
We prioritize the items in a way which we believes benefits the people the most.

Yes thanks for pointing this out again.

PLEASE PEOPLE: MIND THIS !
IF YOU BUY AN VAMPIRE, THEN ALWAYS ORDER IT FOR THE FEATURES AVAILABLE AT THAT DATE - DO NOT BUY IT FOR STUFF WE WORK ON.

While we have a track record of reaching our goals.
You never know what happens in the future.
Priorities might need be changed, and an item you might wait for can take many month before finished.

ONLY BUY the vampire if you are fully happy with the features available today.

As an OS4 user, I am reminded here of where the OS4 way has fallen short. Compatibility with the legacy Amiga software base is insufficient to hold my interest in OS4 captive now. And the promise of new "NG" hardware capabilities has not been fulfilled by the software. Old Amiga programs are hit and miss. And new software that takes full advantage of the hardware is in short supply, including the OS, which leaves parts of the motherboards untouched.

Vampire holds appeal for me in two important areas: Closer (not perfect) to 100 percent compatibility with the legacy Amiga software base, and a cheaper hardware price.

A lot of this discussion regarding FPU stuff has been over my head, I freely admit. And I won't be a whiner. I promise! At this juncture, I only want to chime in with my two cents about what is important to me as a user.

And now that I have put it down here, I will stop harping on it and leave the subject alone. If I'll eventually be able to run all my favorite Amiga programs on Vampire systems, I'll keep buying Vampire hardware and will be happy. If not, well I can only just be disappointed. I lack the skills to actually help with the workload. ;)

So I shut up now and enjoy my new Vampire board for what it is (for now).

Here EXTERNAL LINK it says:

DNetC challenge wrote:

Why doesn't an FPU make my computer crack RC5-72 faster? RC5 involves a large number of integer additions, rotates and XORs. It doesn't require floating point calculations and won't, in general, benefit from them. There has been quite a lot of recent discussion on whether or not it might be possible to boost keyrates (on x86 architectures at least) by taking advantage of the fact that there are separate pipelines for integer and floating point instructions. (We leave it to the reader to figure out how to do floating-point XORs and rotates!) Currently none of the clients attempt to make use of FPUs and we believe any use of the FPU will result in slower clients rather than faster ones. At least one bright person has suggested this is not necessarily the case and indeed he may be right. If anyone can develop an RC5-72 core that takes advantage of the x86 FPU for an overall client speed boost we would be very interested in hearing from them! If you are interested in looking into it the x86 core code is available and can be downloaded from http://www.distributed.net/source/.

So, maybe floating point could work on generating RC5-72 keys. The source code is there available for altering to use a FPU.

While here EXTERNAL LINK 

AresTechnica Users wrote:

hanser: Try folding@home. That uses FPU, and it is for a better cause than seti@home. ZeroZanzibar: What's your beef? I don't automatically get the problem here. OK, so the floating point unit is maybe 10% utilized by SETI. So what? I do performance for a living and I think you have more to do before you are able to back your claim. Problems: 1. Are you sure SiSoft and the SETI measures have the same definition? Believe me, for a lot of this kind of thing, the units aren't always comparable even when you think they are. Dig deeper first. It could be that SETI is far closer to your synthetic measures than you think. For one thing, the SETIDriver probably uses an approximation based on total run time. But, if you are on Windows and have enough else going on, your SETI units get charged for "wall clock" time (i.e. other work), making your FPU appear idle in SETI when it is in fact at the disposal of other things. This would be but one source of depressing your reported MFLOP score. 2. Are you sure everything important about searching for ET requires floating point operations to start with? I know, it is mostly FFT calculations, but it also is array references and that is all integer math. Who knows what else it does? Why must it ipso facto require floating point for everything? As near as I can tell from the SETI FAQ, there are something like three or four distinct phases of calculation. What if one of them happened not to need much/any floating point? 3. I've never necessarily understood 100% access of the floating point unit as necessarily equating to efficiency. In fact, there's a lively literature out there chock full of ideas to convert floating point operations into fixed point operations instead whereever possible. This has been considered a sign of efficiency since, oh, about 1965. Less important today than in '65, of course, and one would expect some of the fixed operations to overlap with float nowadays, but there's still some advantage to using fixed in place of float. Maybe they're doing some of that. If SiSoft is an artificial sequence of all floating point ops (and, it probably is since it is trying to test the unit as opposed to do real work) then it is unrealistic to expect anything to get close to that when you have to deal with main store, array calcs, and all. Do you have any evidence of real world applications that are, say, even 50% floating point operations, for instance? Now, while I do performance for a living, I must admit I don't do floating point stuff. However, I know a lot about sequences. I would be unsurprised to find even heavy floating point applications coming in at 50% FP instructions and 50% other stuff. Branch instructions are commonly about 1/3 of everything. These are counted as integer ops, so that makes a real app max out at 67% before anything else is even considered. ******* What you want to stay away from is floating point heavy projects like SETI and probably Folding@Home because with floating point usually comes fair to middling sized arrays and that means complicated dependencies on cache size, main store speed, and a whole lot more. It gets messy. SETI for sure won't behave as you like. Meanwhile, RC5, an encryption algorithm is (I believe) designed to mostly execute using integer operations in registers. No floating point, little or no main storage used (someone once said it fit in a MB or two). That is exactly the kind of program that will scale with MHz with minimal interference from other system components.

folding@home and seti@home, may or may not be heavy FPU reliant users?!

Here there is a big list of distributed computing projects. EXTERNAL LINK 
Maybe some are really slanted toward heavy usage of FPUs, I don't know.

There are very few on YouTube. I can't find another one that I saw before, that is better than this one (from what I can remember), unfortunately! It might have been taken off?!

It would be interesting to see how long it would take to render one of these with our nifty new FPU!

Let's shoot for the STARS!

EXTERNAL LINK 
"The stress-test feature in Prime95 can be configured to better test various components of the computer by changing the fast fourier transform (FFT) size. Three pre-set configurations are available: Small FFTs and In-place FFTs, and Blend. Small and In-place modes primarily test the FPU and the caches of the CPU, whereas the Blend mode tests everything, including the memory."

Edit:

Here's another recommend for Prime95.
EXTERNAL LINK 

rectifire wrote:

As said above, prime95 is pretty much all FPU when it comes to using your processor. It gives quite a workout to your memory also, since all the FPU calculations are constantly writing and reading results to memory. Prime95 is also very sensitive to any hardware failures, be it CPU or memory..........it errors out when most other programs would run fine. I think it's an excellent CPU test.

EXTERNAL LINK 
It does other types of Mandelbrot and Julia derived sets too.

Maybe that's a part of the problem you are facing here with some people. You and especially some of the project pages give very mixed signals about the availability of a FPU in the current product.

For example the name of the CPU core is 68080 and claims to be a 100% 68k  so the name should be 68LC080 (atm.), shouldn't it.

Also this page here if you click on "Home"/"Features" on the top you end up here: CLICK HERE  Which gives the impression the FPU is already there.

in the wiki is just ONE place where you could get the impression that the FPU is not included atm.
EXTERNAL LINK 
But on Advantages it sounds like its already there
"Fully Pipelined Double/Extended FPU"
the only Hint you get is from the list
"Features"
a little "soon" in the table, which might point that is not implemented. If I click on FPU I get here
EXTERNAL LINK  also not clear is the FPU self work in progress (which Firmware version?) or just the Doku for it.

More confusion when go to "Supported instructions"
"All instructions from MC68000 to MC68060 are supported, except rare ones." so that means including FPU/MMU? if you click on "Apollo Instructions" you land here: CLICK HERE  and there are definitely FPU commands written, again mixed signals (they give a 404 like some other entries)

But in the Roadmap it's nothing written about a FPU.

And that goes on, on all the other pages of the Project. When I started to look deeper into the things I did find that very confusing. The only clear indication are the complains in the different boards about the missing FPU.

Don't get me wrong. I'm very satisfied with the product. I mainly bought it to have a GFX Card in a transportable Amiga :-P

Thanks for the explanation.

This wasn't clear to me. Now I understand a little better.

Sorry, but this explanation makes it even worse... because nowhere on the wiki or other pages this "difference" (if there is any) is stated and made clear. Of course I know that the Vampire is the card itself and the Apollo is the processor core. But all the Wiki/Forum/Information and so on are tightly connected.
If this projects are really not connected that closely, as they seem to be, there should be a clear separation of both, on the Wiki on the Forum and so on. Or how I can be sure what I read in the Wiki is Vampire or Apollo related and fits to the Software and Hardware I'm using atm. In best case that's just confusing...

Since its used in product, he is quite right.
Example is right here CLICK HERE currently claim both INTEGRATED and PIPELINED FPU. Its enough not just to suppose working FPU that exceeds 68882, and not an 040EC in practice.

advantages list claim "Fully pipelined, double/extended FPU"

Vampire pages simply fail to stress that current 080 implementation is 040EC and that no FPU 68k binary cant be
used in present times.

Its obvious to you, and surely is "subject to change" with next core, but it seems it caused a lot of confusion and some frustration.

Solution is list on Apollo accelerators sale page and here at feature list only what is currently fully implemented and updated just what is done :-) This was slight "jump to future", or might be that FPU was expected to be done sooner. But its fair to acknowledge info might be misleading to non fully informed people.

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!