Guest NetRipper Posted November 14, 2009 Report Share Posted November 14, 2009 FYI, results on the Leo/HD2: 25 functions were unpatched, only divs/addd/subd/muld/divd were kept patched. Others had an average of like 60%. "divd" improved by 411%, and the 4 others by 150%. SKtools before patch: Integer: 805.9 Floating: 19.5 SKtools after patch: Integer: 812.6 Floating: 55.2 It's hard to see if it improves anything in everyday apps with a 1GHz cpu :) FPSEce (ps emu) might be a good candicate to try with, but waiting for their 1.0 release first... Link to comment Share on other sites More sharing options...
Guest NuShrike Posted November 19, 2009 Report Share Posted November 19, 2009 (edited) FYI, results on the Leo/HD2: 25 functions were unpatched, only divs/addd/subd/muld/divd were kept patched. Others had an average of like 60%. "divd" improved by 411%, and the 4 others by 150%.Thanks for the interesting stats. Sounds like Qualcomm didn't improve the FPU to keep up in throughput with the Integer in the Snapdragon. Even the "slow" S3C6410 @ 533MHz reaches the same FPU throughput in the SKTools test! Due to lacking kernel support by any WinMob ODM, the way we implement also robs the FPU 2x full-native speed anyways. Can't directly support NEON either because there's no public documentation on it. Status: partial driver has been implemented, but there's still some work for feature parity with FPUenabler. No visuals as a driver so a separate app will be needed to give that. Edited November 19, 2009 by NuShrike Link to comment Share on other sites More sharing options...
Guest naTpuoT87 Posted November 19, 2009 Report Share Posted November 19, 2009 NuShrike Hi! Is it possible to do autopatch in Fpu Enabler? Link to comment Share on other sites More sharing options...
Guest Chainfire Posted November 19, 2009 Report Share Posted November 19, 2009 You are not reading. We are working on a driver. Once that is finished, all you have to do is install the CAB and not worry about it ever again :) Link to comment Share on other sites More sharing options...
Guest bluhound Posted November 20, 2009 Report Share Posted November 20, 2009 Thanks for the interesting stats. Sounds like Qualcomm didn't improve the FPU to keep up in throughput with the Integer in the Snapdragon. Even the "slow" S3C6410 @ 533MHz reaches the same FPU throughput in the SKTools test! Due to lacking kernel support by any WinMob ODM, the way we implement also robs the FPU 2x full-native speed anyways. Can't directly support NEON either because there's no public documentation on it. Status: partial driver has been implemented, but there's still some work for feature parity with FPUenabler. No visuals as a driver so a separate app will be needed to give that. Just being curious, what does 'feature parity' mean? Link to comment Share on other sites More sharing options...
Guest Ganhiru Posted December 1, 2009 Report Share Posted December 1, 2009 (edited) Hi Chainfire, I'm still using v0.70 of your pachter, I read a lot of comics on my device and with the FPU calls pachted the time needed to load a page has decreased as well. Also some games ( like Tower Defence ) seem to run just that bit smoother. So ty for the work so far. Edited December 1, 2009 by Ganhiru Link to comment Share on other sites More sharing options...
Guest dwallersv Posted December 3, 2009 Report Share Posted December 3, 2009 Yeah they are doing a great job indeed! However what is the point of having 3D in spb 3.5? I've seen it on HTC TP2 and its no use at all. If thats related to any other useful 3D app its ok but if its only for spb 3d carosel view its no point indeveloping that as its useless.. eye candy only :DI constantly shake my head at responses like this. Some people like Death Metal (a genre of music). I think it sounds like incomprehensible screaming and noise, akin to 40 people scratching their fingernails on blackboards. Does that make people who like DM fools with bizarre taste in music? Only to the small-minded. Asthetic taste is a personal, and utterly subjective thing. There is no good/bad in any universal sense. Such it is with "eye candy", or from the perspective of someone that values it, "really cool graphical features". Such is the case with the 3D effects in MS3.5, and I'd bet money there are enough users out there that think it's awesome and are willing to select MS3.5 over shells with similar functionality (i.e. not the presentation asthetics) that SPB decided this was well worth the development investment. Proof is in all the people posting on their forums about the devices that DON'T support the UI feature -- as well as a healthy number here. You don't think it matters, hence it is "eye candy" to you. No problem. You might give some thought, though, to respecting other people's differing perspectives and values in regard to this sort of thing. It would expand your understanding. Link to comment Share on other sites More sharing options...
Guest dwallersv Posted December 3, 2009 Report Share Posted December 3, 2009 It's the difference between a i386, and an i386 + i387. Hope that helps.. ;-) :D That's likely complete gibberish to anyone under 35! Link to comment Share on other sites More sharing options...
Guest dwallersv Posted December 3, 2009 Report Share Posted December 3, 2009 Just being curious, what does 'feature parity' mean? Means has the same feature set as the other. For example, the current app-based implentation has a UI to control the thing. A driver can't do that (it's "headless"). So, some interfaces into the driver need to be added that can be accessed by an external application to implement the same capability to control the patch (i.e. turn it "on" and "off"). Absent this, there's no way to control the state of the patch with a driver alone. By anology, consider WiFi. The underlying software that makes it all work is in a driver module. However, without the user apps in windows to control wifi, you wouldn't be able to search for and select networks, configure them, turn wifi on and off, etc. There'd be no way to interact with the low-level software that drives the hardware. This is the same thing. Link to comment Share on other sites More sharing options...
Guest bluhound Posted December 5, 2009 Report Share Posted December 5, 2009 Means has the same feature set as the other. For example, the current app-based implentation has a UI to control the thing. A driver can't do that (it's "headless"). So, some interfaces into the driver need to be added that can be accessed by an external application to implement the same capability to control the patch (i.e. turn it "on" and "off"). Absent this, there's no way to control the state of the patch with a driver alone. By anology, consider WiFi. The underlying software that makes it all work is in a driver module. However, without the user apps in windows to control wifi, you wouldn't be able to search for and select networks, configure them, turn wifi on and off, etc. There'd be no way to interact with the low-level software that drives the hardware. This is the same thing. Now I understand. Thanks! :D Link to comment Share on other sites More sharing options...
Guest da_mafkeez Posted December 6, 2009 Report Share Posted December 6, 2009 hello chainfire and nushrike! can you guys give us an update of the progress making the 'fpu driver' -cab? thanks for the hard work again :D you do great! Link to comment Share on other sites More sharing options...
Guest HOOLA Posted December 6, 2009 Report Share Posted December 6, 2009 this is gread stuff!! I have no idea what any of it mean but i like the sound of it. :D Thanks go out to all devs out there. Without you all, people like me would be stuck with what the big man gives us. Its you guys/gals that really make it worth the money we spend on our devices. Thanks again!! Link to comment Share on other sites More sharing options...
Guest almar Posted December 10, 2009 Report Share Posted December 10, 2009 If I understand it correctly: even if the oems use the ARM_VFPv2 in their ROM build, the method how is similar to yours? Somekind of hooks are build into the coredll which lead back to the injected library? So for optimal perfomance, the compiler should use the VFP instruction set (which WM6.x doesnt support)? Scanning through the FPCRT.def, there are many functions you haven't build in yet, is that because you haven't found the time or because there was no performance gain? (otherwise I will try to add them myself. Using this library and some patch code should do the trick) Link to comment Share on other sites More sharing options...
Guest Chainfire Posted December 11, 2009 Report Share Posted December 11, 2009 (edited) If I understand it correctly: even if the oems use the ARM_VFPv2 in their ROM build, the method how is similar to yours? Somekind of hooks are build into the coredll which lead back to the injected library? So for optimal perfomance, the compiler should use the VFP instruction set (which WM6.x doesnt support)? Scanning through the FPCRT.def, there are many functions you haven't build in yet, is that because you haven't found the time or because there was no performance gain? (otherwise I will try to add them myself. Using this library and some patch code should do the trick) FPCRT is not supported on Windows Mobile 6 (though it should be supported on Windows Mobile 7), we are patching exported coredll functions directly. Some functions have indeed not been implemented due to time restrictions but also performance. To make it all compatible we had to jump through some hoops that do influence floating point calculation speed (kmode, dis/enable interrupts, etc) - it could still be faster. Aside from FPCRT not being supported on WM6, the thread context switching code in the kernel does not preserve FPU registers, thus if you were to use the VFP library directly in your software you either have to wrap all FPU using instructions between dis/enable interrupts calls (which require KMODE) or other software using the FPU (through our patch) might crash. Ideally we would patch the the context switching code in the kernel to work around this issue (it would get rid of both ALLKMODE and interrupt requirements) however we have not done so yet (there are other issues with that). Not to mention you do have to take special care of suspending and resuming. In other words, don't use VFP libraries directly unless you are sure you are the only app using it, or satisfy the above requirements. NuShrike may expand (or correct) on the above when he reads it. Tbh I haven't spoken to him in a while. Edited December 11, 2009 by Chainfire Link to comment Share on other sites More sharing options...
Guest ruskival Posted December 11, 2009 Report Share Posted December 11, 2009 FPCRT is not supported on Windows Mobile 6 (though it should be supported on Windows Mobile 7), we are patching exported coredll functions directly. Some functions have indeed not been implemented due to time restrictions but also performance. To make it all compatible we had to jump through some hoops that do influence floating point calculation speed (kmode, dis/enable interrupts, etc) - it could still be faster. Aside from FPCRT not being supported on WM6, the thread context switching code in the kernel does not preserve FPU registers, thus if you were to use the VFP library directly in your software you either have to wrap all FPU using instructions between dis/enable interrupts calls (which require KMODE) or other software using the FPU (through our patch) might crash. Ideally we would patch the the context switching code in the kernel to work around this issue (it would get rid of both ALLKMODE and interrupt requirements) however we have not done so yet (there are other issues with that). Not to mention you do have to take special care of suspending and resuming. In other words, don't use VFP libraries directly unless you are sure you are the only app using it, or satisfy the above requirements. NuShrike may expand (or correct) on the above when he reads it. Tbh I haven't spoken to him in a while. Link to comment Share on other sites More sharing options...
Guest ruskival Posted December 11, 2009 Report Share Posted December 11, 2009 (edited) In Advance I want to say thank you to all the guys who are putting i their time and effort into improving our devices for us. it is greatly appreciated i just downloaded the fpu enabler and using SKTools v4.4.7.14 i did a FULL Benchmark test to see the full extend of what the fpu enabler does heres my results: BEFORE AFTER INTEGER 517.221 521.8808 Moves/25 usec FLOATING POINT 11.136 58.845 MWIPS RAM ACCESS 968 2144 Speed Index DRAW BITMAPS 1435 1400 Speed Index MAIN STORAGE (WRITE) 4050.10 3661.5 KB/sec MAIN STORAGE (READ) 10893.62 9295.01 KB/sec MY STORAGE (WRITE) 484.93 493.97 KB/sec MY STORAGE (READ) 2142.26 2211.66 KB/sec STORAGE CARD (WRITE) 912.93 928.66 KB/sec STORAGE CARD (READ) 3362.89 3372.12 KB/sec FILE LIST 3050 3071 Items/s FL: MY STORAGE 4228 4283 Items/s FL: STORAGE CARD 3430 3614 Items/s SKTOOLS LOADING 2393 2452 ms BTW this test was done on The Omnia I8000 wm6.1 stock australian rom pda: i8000dtih5 csc: i8000opsih5 also im running SPB MObile shell 3.5.2 with samsung widgets desabled as you can see some of the results are a bit weird in my eyes as they dropped with the program running, maybe this will help with further development and maybe assist in your research just wondering if someone maybe can explain why some of the values dropped with the fpu enabler running? ;) and would the effect vary between rom versions and windows mobile versions? ;) ONCE AGAIN THANKS FOR THE GREAT WORK!!!!! ;) ;) :P Edited December 12, 2009 by ruskival Link to comment Share on other sites More sharing options...
Guest Breit Posted December 12, 2009 Report Share Posted December 12, 2009 your ram access is more than 2 times faster with fpuenabler? how is that possible? Link to comment Share on other sites More sharing options...
Guest ruskival Posted December 12, 2009 Report Share Posted December 12, 2009 your ram access is more than 2 times faster with fpuenabler? how is that possible? that's what i dont get some values went up by a lot, some only a bit and some even went down and that's what im trying to figure out. i was a bit surprised with the results myself and i double checked then but after about 10 tests he results were the same. that's why i was asking why is it like that? what effects the results and does the type of rom and os im running have anything to do with it Link to comment Share on other sites More sharing options...
Guest steveman29 Posted December 12, 2009 Report Share Posted December 12, 2009 This program is great! I have the htc hd2 and the fpu and ram access in sktools is dramatically increased! Well done. I can't wait to try a permanent service of fpu enabler. Link to comment Share on other sites More sharing options...
Guest Chainfire Posted December 13, 2009 Report Share Posted December 13, 2009 your ram access is more than 2 times faster with fpuenabler? how is that possible? I'm not sure if that should be... might well be that specific test uses some floating point by accident and that is why the results are higher... benchmarks are only as good as the person who wrote them ;) Link to comment Share on other sites More sharing options...
Guest ALEKANDER2 Posted December 14, 2009 Report Share Posted December 14, 2009 Wow! I've just installed and tried with iGO 8 on Acer F900 WVGA and the improvement is awesome. Now let me read the whole thread ;) Congratulations to the devs ;) Link to comment Share on other sites More sharing options...
Guest dwallersv Posted December 14, 2009 Report Share Posted December 14, 2009 Wow! I've just installed and tried with iGO 8 on Acer F900 WVGA and the improvement is awesome. Now let me read the whole thread ;) Congratulations to the devs ;) That's enough for me to give it a try! As an aside, I never understand why the numbnuts in R&D at these maufacturers don't bother implementing to take full advantage of this stuff. From my own decades of experience in software development, the effort would be minimal -- certainly more straightforward than the hacks/hooks/kludges that our boys here have to do to try and patch it back in. It's really frustrating, isn't it? Link to comment Share on other sites More sharing options...
Guest Dias1 Posted December 19, 2009 Report Share Posted December 19, 2009 (edited) My Glofiish (Acer) X900 has the samsung S3C6400 CPU with windows 6.5 (cooked) build 23016.5.3.0 with Sktools 3.1.6.0 and FPU Enabler off i get integer 307.3796 Moves/25usec floating point 7.396 MWIPS with FPU Enabler on i get integer 327.0528 Moves/25usec floating point 38.996 MWIPS HUGE Difference!! Edited December 19, 2009 by Dias1 Link to comment Share on other sites More sharing options...
Guest costipl Posted December 19, 2009 Report Share Posted December 19, 2009 What applications actually benefit from this? Apart from ALEKANDER2 mentioning iGO8, all that everyone does is test benchmarks ;) Link to comment Share on other sites More sharing options...
Guest rul3s Posted December 20, 2009 Report Share Posted December 20, 2009 what about a service of FPU enabler? It's dificult to remember not to close the app!! But works great! Nice job guys. ;) Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now