Pandora Rethinking Floating Point On Pandora.

[ldesnogu]

Heh FP computations are slow, but we are talking of less than of a dozen of cycles per instruction so that's 50 MFLOPS, which should be enough for many tasks

Given the option, yes.. I just don't know if Pandora will launch such that there's a compiler flag that uses NEON for scalar floats, or if auto-vectorization will work sufficiently (or if his code is a candidate for it).

Don't put your hopes too high on scalar NEON FP performance: http://infocenter.arm.com/help/index.jsp?t...h/BCGEIHDJ.html
This means you'll have to use vectorized code.

 

[benjymous]

I agree. Don't fix what isn't broken. Use the time you would spend optimizing by cleaning up your code (not to imply it's messy, but one can always improve comments, function structure, etc.). If it will be run decent on a pandora, you'll have a working program with a source you're not ashamed to show. If it runs slow, you'll have a nice, clean code to optimize.

Yup - and if you do have a feeling that stuff could be improved, don't just jump in and spend an hour rewriting functions left right and centre - it's far better to give your code a thorough profiling (this is easy enough to do just by making a helper class that lives on the stack and times its own existence, then stick them in your critical bits of code) - it's pretty common to discover that the bits you think need optimising only turn out to contribute to such a tiny proportion of each frame in your game, that you wouldn't notice the difference, when other simpler things (like caching frequently used calculations) can make big improvements for far less time spent at the keyboard!

 

[fusion_power]

It's a 2d space game with 40 million+ stars placed in fixed positions. It's critical that each player share the same data: star placement needs to be exact.

In theory each game will start in a different galaxy, but galaxy #12345 has the same for all players and calculated on the fly.

I'm not sure that's defined as simple or not.

Are the stars ALWAYS have a fix position or do you mean just per game? And are the Artifact Positions static too or is the Artifact Positions generated for each Game?

 

[Exophase]

Don't put your hopes too high on scalar NEON FP performance: http://infocenter.arm.com/help/index.jsp?t...h/BCGEIHDJ.html
This means you'll have to use vectorized code.


What I meant by scalar NEON is to use vector pair operations but ignore half of the vector. Actually, I find it rather strange that this never comes up as an option.

 

[darkblu]

Don't put your hopes too high on scalar NEON FP performance: http://infocenter.arm.com/help/index.jsp?t...h/BCGEIHDJ.html
This means you'll have to use vectorized code.


looking at the above, i can't say i don't wish we had iphone's VFP11 unit.. oh well, it's still all good.

 

[ldesnogu]

What I meant by scalar NEON is to use vector pair operations but ignore half of the vector. Actually, I find it rather strange that this never comes up as an option.

You'll admit your comment was poorly worded then And I agree that gcc should emit "half vector" NEON FP instructions if it can, provided the user is aware this is not correct due to these operations not being IEEE compliant.

 

[Exophase]

What I meant by scalar NEON is to use vector pair operations but ignore half of the vector. Actually, I find it rather strange that this never comes up as an option.

You'll admit your comment was poorly worded then And I agree that gcc should emit "half vector" NEON FP instructions if it can, provided the user is aware this is not correct due to these operations not being IEEE compliant.

Poorly worded, I don't know ;D It's analogous to the option for allowing scalar SSE to be used instead of x87 on GCC. But here this is actually SSE code, not a special mode that executes x87 on SSE. Now granted, there are actual scalar SSE instructions, but in this case I don't think there's really any benefit to doing half over full, except possibly cutting the register space in half.

 

[TrevorBradley]

Are the stars ALWAYS have a fix position or do you mean just per game? And are the Artifact Positions static too or is the Artifact Positions generated for each Game?

At the moment, star positions, types, classes are fixed, but I intend to make each new game have a new galaxy. If you go to the same sector the star will be at the same place, with the same name.

At the moment, artifact positions are also fixed. Same artifact at same location. There are "good patches" of space you could go back to each game. This will also change once I start randomizing the galaxy. It's pretty much a single parameter in my pseudo random function, but I've not gotten around to implementing it yet... no reason to at the moment.

 

[TrevorBradley]

What I meant by scalar NEON is to use vector pair operations but ignore half of the vector. Actually, I find it rather strange that this never comes up as an option.

You'll admit your comment was poorly worded then And I agree that gcc should emit "half vector" NEON FP instructions if it can, provided the user is aware this is not correct due to these operations not being IEEE compliant.

Poorly worded, I don't know ;D It's analogous to the option for allowing scalar SSE to be used instead of x87 on GCC. But here this is actually SSE code, not a special mode that executes x87 on SSE. Now granted, there are actual scalar SSE instructions, but in this case I don't think there's really any benefit to doing half over full, except possibly cutting the register space in half.


"vector pair" (two vectors?) or scalar pair (vector = pair)? I'm guessing NEON is optimized for mathematics on graphics then... but I'm in the dark here.

I've been giving some thought to NEON today, and I'd love it if we could spearhead a community project to implement a floating point NEON library for Pandora... a "PandoraNEONMath.h" we could all share. I'd love to help on this, but I have to admit I'm in the dark here. I don't have any assembly experience and looking at a few examples (ffmpeg's v4l code) things are cryptic at best.

That being said I pick up things quickly and feel that if someone could generate some 1.1+1.1=2.2 code (or perhaps (1.1,2.2)+(3.3,4.4)=(4.4,6,6) code if we're talking about 2D vectors) I could probably run with it, as I pick up things pretty quickly. Heck, I hadn't touched C or C++ for 16 years until I started this one up. I'd be especially interested in implementing more complex mathematical functions.

Not having access to a Neon isn't going to help though.

Hmmm... here's a crazy idea. Individually we don't have access to dev boards and early pandora... it's just too cumbersome. But I'm wondering if it might be possible for Craig, or ED, or MWeston to set up a single pandora somewhere as a dev server. It would allow us to run console level test code like this... NEON access, floating point tests... stuff we could run from an ssh console only. Access would really need to be restricted, it would really have to be low maintenance for the Pandora crew, and if things got out of hand they could literally "pull the plug" on the idea. But it would allow us early access to pandora hardware without distributing dev boards... more bang for the buck.

In the past they used to run entire hospitals from machines a tenth this powerful... there's no reason why we shouldn't be able to share a pandora as a multi-user system and start doing some early tests on the hardware.

Dunno if it will fly with the OP team though. Might be worth a shot asking.

 

[DasFool]

Ha, a timeshare computer, someone build a time machine and hit up MIT.

In all seriousness though, it could work.

 

[TrevorBradley]

Ha, a timeshare computer, someone build a time machine and hit up MIT.

In all seriousness though, it could work.



It's no joke. Universities, hospitals, medical clinics in the past have used dumb terminals connected to a single central computer. My university used a single IRIX system in the 90s to host tens of thousands of users for email, coding, and whatever else they needed to do. Assignments were frequently developed and compiled on these machines by hundreds of users simultaneously. I was assuming universities still do this, but perhaps they've transitioned everyone over to PC's and IDEs.

The issues here are convincing the Pandora team this can be done with minimal impact on their time, and that some level of control is run over who gets access. *Everyone's* going to want to log into a real pandora because it's "cool"... that could be a real nightmare.

Plus there are issues of what happens if it needs to be rebooted. Maybe it could be put one of those timers that turns your lights on when you're away from home.

I can think of a half dozen ideas why this might be a really bad idea from the Pandora team's perspective... but it might also give us a head start on some aspects of development and optimization...

 

[warmi]

What I meant by scalar NEON is to use vector pair operations but ignore half of the vector. Actually, I find it rather strange that this never comes up as an option.

You'll admit your comment was poorly worded then And I agree that gcc should emit "half vector" NEON FP instructions if it can, provided the user is aware this is not correct due to these operations not being IEEE compliant.

Poorly worded, I don't know ;D It's analogous to the option for allowing scalar SSE to be used instead of x87 on GCC. But here this is actually SSE code, not a special mode that executes x87 on SSE. Now granted, there are actual scalar SSE instructions, but in this case I don't think there's really any benefit to doing half over full, except possibly cutting the register space in half.


"vector pair" (two vectors?) or scalar pair (vector = pair)? I'm guessing NEON is optimized for mathematics on graphics then... but I'm in the dark here.

I've been giving some thought to NEON today, and I'd love it if we could spearhead a community project to implement a floating point NEON library for Pandora... a "PandoraNEONMath.h" we could all share. I'd love to help on this, but I have to admit I'm in the dark here. I don't have any assembly experience and looking at a few examples (ffmpeg's v4l code) things are cryptic at best.

That being said I pick up things quickly and feel that if someone could generate some 1.1+1.1=2.2 code (or perhaps (1.1,2.2)+(3.3,4.4)=(4.4,6,6) code if we're talking about 2D vectors) I could probably run with it, as I pick up things pretty quickly. Heck, I hadn't touched C or C++ for 16 years until I started this one up. I'd be especially interested in implementing more complex mathematical functions.

Not having access to a Neon isn't going to help though.



Not very practical ... the problem here is that Neon ( just like VPF on the iPhone ) requires explicit set of instructions to switch into vector mode and these instructions are serializing ( meaning slow).

You can't just leave Neon in that mode because you are going to trip the compiler and thus you will have to switch it back into scalar mode which is again , slooooow.

In other words, using vector mode works best if you need to perform a long set of operations - having simple inline math library where you constantly enable/disable vector mode will kill your performance.

Now, I don't have access to Neon at this point, but I have done a lot of asm coding for the iPhone which is quite similar so I could be wrong ... but , judging from what they have on their site in terms of documentation , it doesn't look promising.

 

[ldesnogu]

Not very practical ... the problem here is that Neon ( just like VPF on the iPhone ) requires explicit set of instructions to switch into vector mode and these instructions are serializing ( meaning slow).

You can't just leave Neon in that mode because you are going to trip the compiler and thus you will have to switch it back into scalar mode which is again , slooooow.

In other words, using vector mode works best if you need to perform a long set of operations - having simple inline math library where you constantly enable/disable vector mode will kill your performance.

That's just wrong, you don't need specific instructions to switch NEON into vector mode; it has instructions that operate on vectors and they don't need any specific mode setting.
Or did I misunderstand what you were trying to say?

 

[warmi]

Not very practical ... the problem here is that Neon ( just like VPF on the iPhone ) requires explicit set of instructions to switch into vector mode and these instructions are serializing ( meaning slow).

You can't just leave Neon in that mode because you are going to trip the compiler and thus you will have to switch it back into scalar mode which is again , slooooow.

In other words, using vector mode works best if you need to perform a long set of operations - having simple inline math library where you constantly enable/disable vector mode will kill your performance.

That's just wrong, you don't need specific instructions to switch NEON into vector mode; it has instructions that operate on vectors and they don't need any specific mode setting.
Or did I misunderstand what you were trying to say?

Actually, you are right .... the FPSCR register only applies to VFP lite ... and despite the fact that both of them share same registers it appears vector length and stride control only applies to VFP.

So that's very good - I assumed it applied to both - the docs aren't very clear (at least what I have now )

 

[fusion_power]

Are the stars ALWAYS have a fix position or do you mean just per game? And are the Artifact Positions static too or is the Artifact Positions generated for each Game?

At the moment, star positions, types, classes are fixed, but I intend to make each new game have a new galaxy. If you go to the same sector the star will be at the same place, with the same name.

At the moment, artifact positions are also fixed. Same artifact at same location. There are "good patches" of space you could go back to each game. This will also change once I start randomizing the galaxy. It's pretty much a single parameter in my pseudo random function, but I've not gotten around to implementing it yet... no reason to at the moment.

Interesting. I didn't noticed, that Artifacts are also fix...but with 40 Million Stars and random starting positions I think it is not so easy to find out.
I like the idea of different galaxies. Maybe with different graphics? There are mor than just Spiral galaxies out there, I remember very interesting Photos of such objects.

I really hope, the Pandora will allow easy Acess to Hardware components like the NEON thing. it would be too bad if we have such a unit inside and nobody can use it. (I thought, such problems like accessing the GP2X second processor problem is a thing of the past)

 

[Exophase]

NEON is part of the CPU and is accessed like any other CPU instructions are, so you don't need to do anything special to use it.

 

[Butterman]

Hehe. I was starting to really consider floating point math as a problem for TINCS, as this thread got bigger and bigger and I started to see specifications for Pandora floating point performance. Then I remembered, I'm doing all of my floating point calculations on the server anyway . While I will have some floating point stuff with OGL, it wont be anything like what I would have if this was a single player game, OR I was a really rubbish dev, and I was doing all of the calculations on the client (opening the door for easy cheating).

 

[ldesnogu]

NEON is part of the CPU and is accessed like any other CPU instructions are, so you don't need to do anything special to use it.

That's more or less exact. The fact is that NEON is a separate unit in the CPU with its own register file and pipelines. This explains for instance why register transfers between NEON and ARM are slow.

 

[darkblu]

NEON is part of the CPU and is accessed like any other CPU instructions are, so you don't need to do anything special to use it.

That's more or less exact. The fact is that NEON is a separate unit in the CPU with its own register file and pipelines. This explains for instance why register transfers between NEON and ARM are slow.

i was left with the impression that VFP's latency in fast mode (i.e. when delegating to NFP) comes from the lack of register forwarding in neon's pipeline, no?

 

[Exophase]

NEON is part of the CPU and is accessed like any other CPU instructions are, so you don't need to do anything special to use it.

That's more or less exact. The fact is that NEON is a separate unit in the CPU with its own register file and pipelines. This explains for instance why register transfers between NEON and ARM are slow.

i was left with the impression that VFP's latency in fast mode (i.e. when delegating to NFP) comes from the lack of register forwarding in neon's pipeline, no?

The documents do not say outright, however if you look at the timing charts for NEON instructions you will see that the results are written when the relevant execution stage is ready, which varies per instruction. So the latency should only be the difference between the result stage for the register you want and the source stage for the instruction where you want to use it. For floating point operations that's usually N5 (as opposed to N6) and for integer it's quite sooner.

I imagine that the reason why VFP on NEON takes the full pipeline latency (probably always writes back at N6 and probably always reads at N1 if not sooner) is because of the conversion boilerplate going between the two and not because of general limitations in the NEON pipeline. The NEON pipe might not be capable of writing partial results (scalar instead of vector) or to non-aligned regions, which would require VFP operations to go to a temporary register so that the operation doesn't damage the register file.

Personally, I think Laurent has been greatly exaggerating the cost here. A latency of 7 cycles instead of 6 cycles is not exactly earth shattering, or at least it's nothing compared to going to that from a throughput of 8-9+ cycles. The VFP11 that you have much praise for also only saved one latency cycle by forwarding. In fact, forwarding makes the latency for the main arithmetic instructions on VFP11 exactly the same as it is in runfast mode on NEON. 7-8 cycles is hardly anything praiseworthy.

I think that a proper benchmark for runfast vs IEEE VFP needs to be done. Bytemark results are not valid because they use double precision. All we've seen is the improvement in Quake 2, which may not be as floating point dependent as we've been led to believe (or else I don't think Wiz would be running it at even the speed it does).