I had a look upon pspvfpu.c and was very scared about this unoptimizable code to save/restore VFPU registers, especially when using it while you know exactly which matrices are used in GUM functions.
By "unoptimizable", I mean compiler will fail to generate the minimal necessary code to run function pspvfpu_use_matrices with arguments keepset and tempset being constant.
My question is :
- if I have just one thread using VFPU in my module/executable, can I just have to use THREAD_ATTR_VFPU in the macro PSP_MAIN_THREAD_ATTR instead of using pspvfpu_use_matrices ? (using a dummy pspvfpu.h)
- if you could explain to me why this code is necessary, i would be glad to find a way to allow compiler to generate a better code.
Using pspvfpu.h instead of THREAD_ATTR_VFPU ?
pspvfpu was designed to ease the use of vfpu inside applications and libraries without forcing you to manage register usage, instead you just make sure you call the method to keep away from conflicts that might arise, as long as there are no conflicts no copying will happen. If you want to, there's no problem to skip using the library in your own application, this was more from a library POV, since you might link with multiple libraries that all use the VFPU. If you make sure that you manage the registers correctly, you can write your code as optimized as you like.
For example, pspgum uses M000-M002 as temporaries and M003 as the current matrix, it will never touch registers M004-M007. I think pspgl uses M007 for its current matrix (haven't looked much at the vfpu-support in there). These libraries should actually co-exist quite nicely since they do not clash in any permanent registers and only temporaries. If you write your code similar to this, I doubt the occasional function-call into pspvfpu will be neglectable.
For example, pspgum uses M000-M002 as temporaries and M003 as the current matrix, it will never touch registers M004-M007. I think pspgl uses M007 for its current matrix (haven't looked much at the vfpu-support in there). These libraries should actually co-exist quite nicely since they do not clash in any permanent registers and only temporaries. If you write your code similar to this, I doubt the occasional function-call into pspvfpu will be neglectable.
GE Dominator
okay, using pspvfpu.c would help for managing multiple libraries using VFPU in the SAME thread because some library tends to use some VFPU registers as permanent register. Am I correct ?
If I create another thread in my executable which also use VFPU, I just need to pass THREAD_ATTR_VFPU to sceKernelCreateThread. Am I correct ?
Thanx
If I create another thread in my executable which also use VFPU, I just need to pass THREAD_ATTR_VFPU to sceKernelCreateThread. Am I correct ?
Thanx
Yes, THREAD_ATTR_VFPU just tells the kernel to context switch the VFPU registers, the reason it needs the flag it cause of the large cost of context switching the vfpu register set. If only one thread has the flag it still will not context switch, it is only if you have multiple threads with it then it does something.