fixed point in irrlicht?

[huntersh2014]

I am trying to port irrlicht to android platform, the port is done, but the fps on android is very low. I heard that replacing float point with fixed point could improve the performance on mobile platform. Anyone has experience on this? Thanks very much

[hybrid]

Which driver do you use? Best thing is to move most calculations to the GPU, which has FP support. Doing calculations in fixed point would mean that you have to find enough consecutive calculations that would make the initial and final conversions from and to floating point neglectable. So meaning to change a lot of the engine. And there have been many reports that Irrlicht on Android does work with decent FPS as well. So I guess the problem is elsewhere for you.

[huntersh2014]

Which driver do you use? Best thing is to move most calculations to the GPU, which has FP support. Doing calculations in fixed point would mean that you have to find enough consecutive calculations that would make the initial and final conversions from and to floating point neglectable. So meaning to change a lot of the engine. And there have been many reports that Irrlicht on Android does work with decent FPS as well. So I guess the problem is elsewhere for you.

Yes, I see there're many posts talking about the irrlicht optimization on android, but seems no one mention which technology being used. So I just wonder the fixed point might be a good choice.

Yes, there are lots of things to do in the engine when swtiching from float point to fixed point. But I don't think we need to change all of floats, but just those key ones. I used intel vtune tool to find out operator + - and dotproduct in vector3d are the top 3 time consuming float compution functions. So I tried to use fixed point in these 3 function, but without luck,I even got performance downgrade - I think the reason of the downgrade is the overahead of fixed point, the right way should be convert float to fixed once and do the compuation for many times, but here converion is called for every single computation. but anyway I didn't find a good way to resolve it yet.

[hendu]

Intel VTune, isn't that only on Intel-based Windows? Most ARM vendors have their own profiling toolchains with which you can profile on the actual device, those would give better stats, as with a PC profile you're just guessing what goes down on the device.

Also, many of the ARM profilers are able to profile the GPU too, which may prove useful.

edit: Most features of vtune requre Intel/windows, basic ones seem available for amd and linux too. Doesn't change the main point.

[huntersh2014]

Intel VTune, isn't that only on Intel-based Windows? Most ARM vendors have their own profiling toolchains with which you can profile on the actual device, those would give better stats, as with a PC profile you're just guessing what goes down on the device.

Also, many of the ARM profilers are able to profile the GPU too, which may prove useful.

edit: Most features of vtune requre Intel/windows, basic ones seem available for amd and linux too. Doesn't change the main point.

vtune doesn't matter too much here, the key thing is if replacing float point with fixed point is the right approach and how to do that

[CuteAlien]

You could try replacing f32 and f64 by corresponding fixed-point classes. Can't help you much with that - it's been decades since I last worked with fixed-point math as optimization and my classes from back then probably sucked (I was learning c++ at the time). But in theory it sounds like that could work, although there are probably troubles (like if the sizes are not the same, so anything using sizeof would fail).

edit: Uhm, no - horrible idea. Will not work. As there are lots of places where we pass on f32 to system-functions expecting floats (for example opengl...).

[hendu]

The point is that you can't know if floats are the bottleneck by only testing on a PC.

[huntersh2014]

You could try replacing f32 and f64 by corresponding fixed-point classes. Can't help you much with that - it's been decades since I last worked with fixed-point math as optimization and my classes from back then probably sucked (I was learning c++ at the time). But in theory it sounds like that could work, although there are probably troubles (like if the sizes are not the same, so anything using sizeof would fail).

edit: Uhm, no - horrible idea. Will not work. As there are lots of places where we pass on f32 to system-functions expecting floats (for example opengl...).

I think you're pointing out the right thing. My original thought is also to replace f32 and f64 with some fixed-point classes, but I got so many build errors there and the most important thing is I am not sure if the rendering still works even get the build works - because I don't know where and when should we convert the fixed point back in the engine.

[huntersh2014]

edit: Uhm, no - horrible idea. Will not work. As there are lots of places where we pass on f32 to system-functions expecting floats (for example opengl...).

this is also my concern, we need to convert the fixed point back on the right places, such as when passing f32 to opengl as you mentioned here. So it looks a horrible and complicate work to do if we want to replace f32 with some fixed point class for the whole engine.