 |
forums.ps2dev.org
Homebrew PS2, PSP & PS3 Development Discussions
|
| View previous topic :: View next topic |
| Author |
Message |
cooleyes
Joined: 18 May 2006
Posts: 125
|
 Posted: Mon Nov 13, 2006 5:23 pm Post subject: How to use VFPU?? |
 |
|
I have some code like
| Code: |
#define EXPAND_16_TIMES(CODE) CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE
void Adapt(short * pM, const short * pAdapt, int nDirection, int nOrder)
{
nDirection = -nDirection;
nOrder >>= 4;
if (nDirection < 0)
{
while (nOrder--)
{
EXPAND_16_TIMES(*pM++ += *pAdapt++;)
}
}
else if (nDirection > 0)
{
while (nOrder--)
{
EXPAND_16_TIMES(*pM++ -= *pAdapt++;)
}
}
}
|
I want to use VFPU code to instead of
so I wrote that
| Code: |
#define vfpuadd16 \
__asm__ volatile( \
".set push\n" \
".set noreorder\n" \
"lv.q R100, 0+%0\n" \
"lv.q R000, 0+%1\n" \
"vadd.q R100, R100, R000\n" \
"sv.q R100, 0+%0\n" \
"lv.q R101, 16+%0\n" \
"lv.q R001, 16+%1\n" \
"vadd.q R101, R101, R001\n" \
"sv.q R101, 16+%0\n" \
"lv.q R102, 32+%0\n" \
"lv.q R002, 32+%1\n" \
"vadd.q R102, R102, R002\n" \
"sv.q R102, 32+%0\n" \
"lv.q R103, 48+%0\n" \
"lv.q R003, 48+%1\n" \
"vadd.q R103, R103, R003\n" \
"sv.q R103, 48+%0\n" \
".set pop\n" \
: "+m" (blockM32), \
"+m" (blockAdapt32) ) ;
#define vfpusub16 \
__asm__ volatile( \
".set push\n" \
".set noreorder\n" \
"lv.q R100, 0+%0\n" \
"lv.q R000, 0+%1\n" \
"vsub.q R100, R100, R000\n" \
"sv.q R100, 0+%0\n" \
"lv.q R101, 16+%0\n" \
"lv.q R001, 16+%1\n" \
"vsub.q R101, R101, R001\n" \
"sv.q R101, 16+%0\n" \
"lv.q R102, 32+%0\n" \
"lv.q R002, 32+%1\n" \
"vsub.q R102, R102, R002\n" \
"sv.q R102, 32+%0\n" \
"lv.q R103, 48+%0\n" \
"lv.q R003, 48+%1\n" \
"vsub.q R103, R103, R003\n" \
"sv.q R103, 48+%0\n" \
".set pop\n" \
: "+m" (blockM32), \
"+m" (blockAdapt32) ) ;
static inline void AdaptVFPUAdd(short * pM, const short * pAdapt) {
float __attribute__((aligned(64))) blockM32[16];
float __attribute__((aligned(64))) blockAdapt32[16];
int i;
for(i = 0; i < 16; i++)
{
blockM32[i] = *(pM+i);
blockAdapt32[i] = *(pAdapt+i);
}
vfpuadd16;
for(i = 0; i < 16; i++)
{
*(pM+i) = (short)blockM32[i];
}
}
static inline void AdaptVFPUSub(short * pM, const short * pAdapt) {
float __attribute__((aligned(64))) blockM32[16];
float __attribute__((aligned(64))) blockAdapt32[16];
int i;
for(i = 0; i < 16; i++)
{
blockM32[i] = *(pM+i);
blockAdapt32[i] = *(pAdapt+i);
}
vfpusub16;
for(i = 0; i < 16; i++)
{
*(pM+i) = (short)blockM32[i];
}
}
void Adapt(short * pM, const short * pAdapt, int nDirection, int nOrder)
{
nDirection = -nDirection;
nOrder >>= 4;
if (nDirection < 0)
{
while (nOrder--)
{
AdaptVFPUAdd(pM, pAdapt);
pM+=16;
pAdapt+=16;
//EXPAND_16_TIMES(*pM++ += *pAdapt++;)
}
}
else if (nDirection > 0)
{
while (nOrder--)
{
AdaptVFPUSub(pM, pAdapt);
pM+=16;
pAdapt+=16;
//EXPAND_16_TIMES(*pM++ -= *pAdapt++;)
}
}
}
|
It can be complied, But not work, It let's my psp halt. :( |
|
| Back to top |
|
 |
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Mon Nov 13, 2006 6:37 pm Post subject: |
|
|
address in lv.q/sv.q must be aligned to 16-byte region. Remember they load/store 4 floats, that is 16 bytes.
I don't know if ulv.q/usv.q for unligned access may be the right solution (but slower).
I'm must leave so i didn't take too much time to read all your code.
EDIT:
sorry i didn't read very well your code, you're aligning your floats at 64-bytes it sounds a bit much but i guess if it is for cache reason you're right.
while i'm trying to understand your code, I may point out the fact that you may use vs2i/vi2s and vi2f/vf2i instructions to convert your shorts into/from floats in a more efficient way that you're doing.
Last edited by hlide on Mon Nov 13, 2006 8:00 pm; edited 2 times in total |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Mon Nov 13, 2006 7:43 pm Post subject: |
|
|
To my last own problems with the VFPU, it seems that the align macro doesn't apply to stack variables, therefore causing your unaligned accesses to crash the psp.
Two possible solutions:
- memalign the two buffers instead of declaring them on stack [or write your own stack align function] (bad)
- use unaligned access (ulv.q/usv.q) and drop the buffers completely (good)
To my findings, unaligned accesses also aren't slower when the data is fetched from/written to memory, and takes 2 cycles instead of 1 for cached reads and 14 instead of 7 cycles for cached writes. Not that much [waste], if you take into account that reads/writes from memory will take 68/111 cycles independant of unaligned/aligned.
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Mon Nov 13, 2006 7:58 pm Post subject: |
|
|
| Raphael wrote: | To my last own problems with the VFPU, it seems that the align macro doesn't apply to stack variables, therefore causing your unaligned accesses to crash the psp.
Two possible solutions:
- memalign the two buffers instead of declaring them on stack [or write your own stack align function] (bad)
- use unaligned access (ulv.q/usv.q) and drop the buffers completely (good)
To my findings, unaligned accesses also aren't slower when the data is fetched from/written to memory, and takes 2 cycles instead of 1 for cached reads and 14 instead of 7 cycles for cached writes. Not that much [waste], if you take into account that reads/writes from memory will take 68/111 cycles independant of unaligned/aligned. |
can we at least force an GCC options to align stack to 16-byte for isntance ? |
|
| Back to top |
|
|
cooleyes
Joined: 18 May 2006
Posts: 125
|
| Posted: Mon Nov 13, 2006 8:46 pm Post subject: |
|
|
| Raphael wrote: | To my last own problems with the VFPU, it seems that the align macro doesn't apply to stack variables, therefore causing your unaligned accesses to crash the psp.
Two possible solutions:
- memalign the two buffers instead of declaring them on stack [or write your own stack align function] (bad)
- use unaligned access (ulv.q/usv.q) and drop the buffers completely (good)
To my findings, unaligned accesses also aren't slower when the data is fetched from/written to memory, and takes 2 cycles instead of 1 for cached reads and 14 instead of 7 cycles for cached writes. Not that much [waste], if you take into account that reads/writes from memory will take 68/111 cycles independant of unaligned/aligned. |
thanks for your help
when I use ulv.q/usv.q instead of lv.q/sv.q, it can work, no crash
but it was slower than the code not use VFPU. :( |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Mon Nov 13, 2006 9:01 pm Post subject: |
|
|
I didn't test it but you may do the same thing without temporary float buffer, please keep in mind there may be some bugs :
| Code: |
static inline void AdaptVFPUAdd16(short *pM, const short *pAdapt)
__asm__ volatile(
".set push;"
".set noreorder;"
"ulv.q R100, 0(%0);"
"ulv.q R000, 0(%1);"
"ulv.q R101, 16(%0);"
"ulv.q R001, 16(%1);"
"vs2i.q R100, R100;"
"vs2i.q R101, R120;"
"vs2i.q R102, R101;"
"vs2i.q R103, R121;"
"vs2i.q R000, R000;"
"vs2i.q R001, R020;"
"vs2i.q R002, R001;"
"vs2i.q R003, R020;"
"vi2f.q R100, R100, 16;"
"vi2f.q R101, R101, 16;"
"vi2f.q R102, R102, 16;"
"vi2f.q R103, R103, 16;"
"vi2f.q R000, R000, 16;"
"vi2f.q R001, R001, 16;"
"vi2f.q R002, R002, 16;"
"vi2f.q R003, R003, 16;"
"vadd.q R100, R100, R000;"
"vadd.q R101, R101, R001;"
"vadd.q R102, R102, R002;"
"vadd.q R103, R103, R003;"
"vf2iz.q R100, R100, 16;"
"vf2iz.q R101, R101, 16;"
"vf2iz.q R102, R102, 16;"
"vf2iz.q R103, R103, 16;"
"vi2s.p R100, R100;"
"vi2s.p R120, R101;"
"vi2s.p R101, R102;"
"vi2s.p R121, R103;"
"usv.q R100, 0(%0);"
"usv.q R101, 16(%0);"
".set pop" : : "r"(pM), "r"(pAdapt) : "memory");
...
void Adapt(short * pM, const short * pAdapt, int nDirection, int nOrder)
{
nDirection = -nDirection;
nOrder >>= 4;
if (nDirection < 0)
{
while (nOrder--)
{
AdaptVFPUAdd16(pM, pAdapt);
pM+=16;
pAdapt+=16;
}
}
else if (nDirection > 0)
{
while (nOrder--)
{
AdaptVFPUSub16(pM, pAdapt);
pM+=16;
pAdapt+=16;
}
}
}
|
By the way, i didn't try to reorder vfpu instructions for better scheduling to ease the reading. |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Mon Nov 13, 2006 10:20 pm Post subject: |
|
|
[quote="cooleyes"] | Raphael wrote: | To my last own problems with the VFPU, it seems that the align macro doesn't apply to stack variables, therefore causing your unaligned accesses to crash the psp.
Two possible solutions:
- memalign the two buffers instead of declaring them on stack [or write your own stack align function] (bad)
- use unaligned access (ulv.q/usv.q) and drop the buffers completely (good)
To my findings, unaligned accesses also aren't slower when the data is fetched from/written to memory, and takes 2 cycles instead of 1 for cached reads and 14 instead of 7 cycles for cached writes. Not that much [waste], if you take into account that reads/writes from memory will take 68/111 cycles independant of unaligned/aligned. |
no wonder !
1) copy of shorts in a float buffer using FPU (not VFPU !)
2) VFPU computation temporary buffer
3) copy of float buffer in the short buffers using FPU conversion (not VFPU again !)
That's definitely not the fast path to do ! |
|
| Back to top |
|
|
cooleyes
Joined: 18 May 2006
Posts: 125
|
| Posted: Mon Nov 13, 2006 10:42 pm Post subject: |
|
|
to hlide:
thanks for help
I have read the code you posted, and change some to make it can be compiled, but it crash , :(
| Code: |
#define vfpuadd16ex \
__asm__ volatile( \
".set push\n" \
".set noreorder\n" \
"ulv.q R100, 0+%0\n" \
"ulv.q R000, 0+%1\n" \
"ulv.q R101, 16+%0\n" \
"ulv.q R001, 16+%1\n" \
"vs2i.p R100, R100\n" \
"vs2i.p R101, R120\n" \
"vs2i.p R102, R101\n" \
"vs2i.p R103, R121\n" \
"vs2i.p R000, R000\n" \
"vs2i.p R001, R020\n" \
"vs2i.p R002, R001\n" \
"vs2i.p R003, R020\n" \
"vi2f.q R100, R100, 16\n" \
"vi2f.q R101, R101, 16\n" \
"vi2f.q R102, R102, 16\n" \
"vi2f.q R103, R103, 16\n" \
"vi2f.q R000, R000, 16\n" \
"vi2f.q R001, R001, 16\n" \
"vi2f.q R002, R002, 16\n" \
"vi2f.q R003, R003, 16\n" \
"vadd.q R100, R100, R000\n" \
"vadd.q R101, R101, R001\n" \
"vadd.q R102, R102, R002\n" \
"vadd.q R103, R103, R003\n" \
"vf2iz.q R100, R100, 16\n" \
"vf2iz.q R101, R101, 16\n" \
"vf2iz.q R102, R102, 16\n" \
"vf2iz.q R103, R103, 16\n" \
"vi2s.q R100, R100\n" \
"vi2s.q R120, R101\n" \
"vi2s.q R101, R102\n" \
"vi2s.q R121, R103\n" \
"usv.q R100, 0+%0\n" \
"usv.q R101, 16+%0\n" \
".set pop\n" \
: "+m" (pM), \
"+m" (pAdapt) );
static inline void AdaptVFPUAdd(short * pM, const short * pAdapt) {
vfpuadd16ex;
} |
|
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Mon Nov 13, 2006 10:44 pm Post subject: |
|
|
| cooleyes wrote: | to hlide:
thanks for help
I have read the code you posted, and change some to make it can be compiled, but it crash , :(
| Code: |
#define vfpuadd16ex \
__asm__ volatile( \
".set push\n" \
".set noreorder\n" \
"ulv.q R100, 0+%0\n" \
"ulv.q R000, 0+%1\n" \
"ulv.q R101, 16+%0\n" \
"ulv.q R001, 16+%1\n" \
"vs2i.p R100, R100\n" \
"vs2i.p R101, R120\n" \
"vs2i.p R102, R101\n" \
"vs2i.p R103, R121\n" \
"vs2i.p R000, R000\n" \
"vs2i.p R001, R020\n" \
"vs2i.p R002, R001\n" \
"vs2i.p R003, R020\n" \
"vi2f.q R100, R100, 16\n" \
"vi2f.q R101, R101, 16\n" \
"vi2f.q R102, R102, 16\n" \
"vi2f.q R103, R103, 16\n" \
"vi2f.q R000, R000, 16\n" \
"vi2f.q R001, R001, 16\n" \
"vi2f.q R002, R002, 16\n" \
"vi2f.q R003, R003, 16\n" \
"vadd.q R100, R100, R000\n" \
"vadd.q R101, R101, R001\n" \
"vadd.q R102, R102, R002\n" \
"vadd.q R103, R103, R003\n" \
"vf2iz.q R100, R100, 16\n" \
"vf2iz.q R101, R101, 16\n" \
"vf2iz.q R102, R102, 16\n" \
"vf2iz.q R103, R103, 16\n" \
"vi2s.q R100, R100\n" \
"vi2s.q R120, R101\n" \
"vi2s.q R101, R102\n" \
"vi2s.q R121, R103\n" \
"usv.q R100, 0+%0\n" \
"usv.q R101, 16+%0\n" \
".set pop\n" \
: "+m" (pM), \
"+m" (pAdapt) );
static inline void AdaptVFPUAdd(short * pM, const short * pAdapt) {
vfpuadd16ex;
} |
|
as I told you I didn't test it. And I may be wrong on row naming too... so... you can have a look on vfpu diggings for the purpose of each instruction and you may find the bugs. |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Mon Nov 13, 2006 10:47 pm Post subject: |
|
|
| cooleyes wrote: | to hlide:
thanks for help
I have read the code you posted, and change some to make it can be compiled, but it crash , :(
| Code: |
#define vfpuadd16ex \
__asm__ volatile( \
".set push\n" \
".set noreorder\n" \
"ulv.q R100, 0+%0\n" \
"ulv.q R000, 0+%1\n" \
"ulv.q R101, 16+%0\n" \
"ulv.q R001, 16+%1\n" \
"vs2i.p R100, R100\n" \
"vs2i.p R101, R120\n" \
"vs2i.p R102, R101\n" \
"vs2i.p R103, R121\n" \
"vs2i.p R000, R000\n" \
"vs2i.p R001, R020\n" \
"vs2i.p R002, R001\n" \
"vs2i.p R003, R020\n" \
"vi2f.q R100, R100, 16\n" \
"vi2f.q R101, R101, 16\n" \
"vi2f.q R102, R102, 16\n" \
"vi2f.q R103, R103, 16\n" \
"vi2f.q R000, R000, 16\n" \
"vi2f.q R001, R001, 16\n" \
"vi2f.q R002, R002, 16\n" \
"vi2f.q R003, R003, 16\n" \
"vadd.q R100, R100, R000\n" \
"vadd.q R101, R101, R001\n" \
"vadd.q R102, R102, R002\n" \
"vadd.q R103, R103, R003\n" \
"vf2iz.q R100, R100, 16\n" \
"vf2iz.q R101, R101, 16\n" \
"vf2iz.q R102, R102, 16\n" \
"vf2iz.q R103, R103, 16\n" \
"vi2s.q R100, R100\n" \
"vi2s.q R120, R101\n" \
"vi2s.q R101, R102\n" \
"vi2s.q R121, R103\n" \
"usv.q R100, 0+%0\n" \
"usv.q R101, 16+%0\n" \
".set pop\n" \
: "+m" (pM), \
"+m" (pAdapt) );
static inline void AdaptVFPUAdd(short * pM, const short * pAdapt) {
vfpuadd16ex;
} |
|
keys :
"v(u)s2i"
"vi2(u)s"
"vi2f"
"vf2iz"
the rest should be okay for you |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Mon Nov 13, 2006 11:06 pm Post subject: |
|
|
I inverted two pairs of instructions :
| Code: | #define vfpuadd16ex \
__asm__ volatile( \
".set push\n" \
".set noreorder\n" \
"ulv.q R100, 0+%0\n" \
"ulv.q R000, 0+%1\n" \
"ulv.q R101, 16+%0\n" \
"ulv.q R001, 16+%1\n" \
"vs2i.p R100, R100\n" \
>>>"vs2i.p R102, R101\n"<<< \
>>>"vs2i.p R101, R120\n"<<< \
"vs2i.p R103, R121\n" \
"vs2i.p R000, R000\n" \
>>>"vs2i.p R002, R001\n"<<< \
>>>"vs2i.p R001, R020\n"<<< \
"vs2i.p R003, R021\n" \ <<< R020 should be R021
"vi2f.q R100, R100, 16\n" \
"vi2f.q R101, R101, 16\n" \
"vi2f.q R102, R102, 16\n" \
"vi2f.q R103, R103, 16\n" \
"vi2f.q R000, R000, 16\n" \
"vi2f.q R001, R001, 16\n" \
"vi2f.q R002, R002, 16\n" \
"vi2f.q R003, R003, 16\n" \
"vadd.q R100, R100, R000\n" \
"vadd.q R101, R101, R001\n" \
"vadd.q R102, R102, R002\n" \
"vadd.q R103, R103, R003\n" \
"vf2iz.q R100, R100, 16\n" \
"vf2iz.q R101, R101, 16\n" \
"vf2iz.q R102, R102, 16\n" \
"vf2iz.q R103, R103, 16\n" \
"vi2s.q R100, R100\n" \
"vi2s.q R120, R101\n" \
"vi2s.q R101, R102\n" \
"vi2s.q R121, R103\n" \
"usv.q R100, 0+%0\n" \
"usv.q R101, 16+%0\n" \
".set pop\n" \
: "+m" (pM), \
"+m" (pAdapt) );
|
i don't know if it is a the reason why it crashes. I suppose you a crash into this code when running and not at compiling ? or do you crash later because of the result of this function ?
Last edited by hlide on Mon Nov 13, 2006 11:12 pm; edited 1 time in total |
|
| Back to top |
|
|
cooleyes
Joined: 18 May 2006
Posts: 125
|
| Posted: Mon Nov 13, 2006 11:10 pm Post subject: |
|
|
en, I have found the error, new code like this, no crash, but also slower.
| Code: |
#define vfpuadd16ex \
__asm__ volatile( \
".set push\n" \
".set noreorder\n" \
"ulv.q R100, 0+%0\n" \
"ulv.q R000, 0+%1\n" \
"ulv.q R101, 16+%0\n" \
"ulv.q R001, 16+%1\n" \
"vs2i.p R300, R100\n" \
"vs2i.p R301, R120\n" \
"vs2i.p R302, R101\n" \
"vs2i.p R303, R121\n" \
"vs2i.p R200, R000\n" \
"vs2i.p R201, R020\n" \
"vs2i.p R202, R001\n" \
"vs2i.p R203, R020\n" \
"vi2f.q R300, R300, 16\n" \
"vi2f.q R301, R301, 16\n" \
"vi2f.q R302, R302, 16\n" \
"vi2f.q R303, R303, 16\n" \
"vi2f.q R200, R200, 16\n" \
"vi2f.q R201, R201, 16\n" \
"vi2f.q R202, R202, 16\n" \
"vi2f.q R203, R203, 16\n" \
"vadd.q R300, R300, R200\n" \
"vadd.q R301, R301, R201\n" \
"vadd.q R302, R302, R202\n" \
"vadd.q R303, R303, R203\n" \
"vf2iz.q R300, R300, 16\n" \
"vf2iz.q R301, R301, 16\n" \
"vf2iz.q R302, R302, 16\n" \
"vf2iz.q R303, R303, 16\n" \
"vi2s.q R100, R300\n" \
"vi2s.q R120, R301\n" \
"vi2s.q R101, R302\n" \
"vi2s.q R121, R303\n" \
"usv.q R100, 0+%0\n" \
"usv.q R101, 16+%0\n" \
".set pop\n" \
: "+m" (pM), \
"+m" (pAdapt) );
|
|
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Mon Nov 13, 2006 11:17 pm Post subject: |
|
|
| cooleyes wrote: | en, I have found the error, new code like this, no crash, but also slower.
| Code: |
#define vfpuadd16ex \
__asm__ volatile( \
".set push\n" \
".set noreorder\n" \
"ulv.q R100, 0+%0\n" \
"ulv.q R000, 0+%1\n" \
"ulv.q R101, 16+%0\n" \
"ulv.q R001, 16+%1\n" \
"vs2i.p R300, R100\n" \
"vs2i.p R301, R120\n" \
"vs2i.p R302, R101\n" \
"vs2i.p R303, R121\n" \
"vs2i.p R200, R000\n" \
"vs2i.p R201, R020\n" \
"vs2i.p R202, R001\n" \
"vs2i.p R203, R020\n" \ <<<<<<< should be R021
"vi2f.q R300, R300, 16\n" \
"vi2f.q R301, R301, 16\n" \
"vi2f.q R302, R302, 16\n" \
"vi2f.q R303, R303, 16\n" \
"vi2f.q R200, R200, 16\n" \
"vi2f.q R201, R201, 16\n" \
"vi2f.q R202, R202, 16\n" \
"vi2f.q R203, R203, 16\n" \
"vadd.q R300, R300, R200\n" \
"vadd.q R301, R301, R201\n" \
"vadd.q R302, R302, R202\n" \
"vadd.q R303, R303, R203\n" \
"vf2iz.q R300, R300, 16\n" \
"vf2iz.q R301, R301, 16\n" \
"vf2iz.q R302, R302, 16\n" \
"vf2iz.q R303, R303, 16\n" \
"vi2s.q R100, R300\n" \
"vi2s.q R120, R301\n" \
"vi2s.q R101, R302\n" \
"vi2s.q R121, R303\n" \
"usv.q R100, 0+%0\n" \
"usv.q R101, 16+%0\n" \
".set pop\n" \
: "+m" (pM), \
"+m" (pAdapt) );
|
|
first you may need to reorder instuctions to hide latencies, because i'm sure it is not optimal here.
but anyway why do you need to use float to add shorts !?!? i'm coding something stupid ! |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Tue Nov 14, 2006 1:36 am Post subject: |
|
|
| hlide wrote: |
can we at least force an GCC options to align stack to 16-byte for isntance ? |
Not sure about that. Last time I needed that, I wrote a work-around like that:
| Code: |
float myarray[SIZE + 4];
float* myarray16 = (float*)(((int)myarray+16)&~0xF);
|
which worked (but is ugly).
| hlide wrote: |
first you may need to reorder instuctions to hide latencies |
Unfortunately to my findings this seems hardly possible, if at all. I would suppose the VFPU isn't pipelined, or if it is, the pipeline is very short and most ops use all it's stages. You can however hide MIPS code inside the VFPU latencies.
| cooleyes wrote: | | en, I have found the error, new code like this, no crash, but also slower. |
The problem is that you only want to add shorts together, which requires you to load the data into VFPU registers, convert them, add them, reconvert them and write them back to memory. A lot of overhead for a simple functionality like that, so you won't get it faster with VFPU.
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
cooleyes
Joined: 18 May 2006
Posts: 125
|
| Posted: Tue Nov 14, 2006 12:30 pm Post subject: |
|
|
to hlide:
I have made a mistake, the new code didn't work.
I found my demo app use the old code last night,
so it can work no crash.
but when I use the new code , it crashed.
but you are right, use vfpu to do this is stupid, too slower
| Code: |
#define vfpuadd16ex \
__asm__ volatile( \
".set push\n" \
".set noreorder\n" \
"ulv.q R100, 0+%0\n" \
"ulv.q R000, 0+%1\n" \
"ulv.q R101, 16+%0\n" \
"ulv.q R001, 16+%1\n" \
"vs2i.p R300, R100\n" \
"vs2i.p R301, R120\n" \
"vs2i.p R302, R101\n" \
"vs2i.p R303, R121\n" \
"vs2i.p R200, R000\n" \
"vs2i.p R201, R020\n" \
"vs2i.p R202, R001\n" \
"vs2i.p R203, R021\n" \
"vi2f.q R300, R300, 16\n" \
"vi2f.q R301, R301, 16\n" \
"vi2f.q R302, R302, 16\n" \
"vi2f.q R303, R303, 16\n" \
"vi2f.q R200, R200, 16\n" \
"vi2f.q R201, R201, 16\n" \
"vi2f.q R202, R202, 16\n" \
"vi2f.q R203, R203, 16\n" \
"vadd.q R300, R300, R200\n" \
"vadd.q R301, R301, R201\n" \
"vadd.q R302, R302, R202\n" \
"vadd.q R303, R303, R203\n" \
"vf2iz.q R300, R300, 16\n" \
"vf2iz.q R301, R301, 16\n" \
"vf2iz.q R302, R302, 16\n" \
"vf2iz.q R303, R303, 16\n" \
"vi2s.q R100, R300\n" \
"vi2s.q R120, R301\n" \
"vi2s.q R101, R302\n" \
"vi2s.q R121, R303\n" \
"usv.q R100, 0+%0\n" \
"usv.q R101, 16+%0\n" \
".set pop\n" \
: "+m" (pM), \
"+m" (pAdapt) );
|
|
|
| Back to top |
|
|
cooleyes
Joined: 18 May 2006
Posts: 125
|
| Posted: Tue Nov 14, 2006 12:34 pm Post subject: |
|
|
to Raphael:
I just want to test that can I use some vfpu code to instead of "MMX code" in PSP.
but I think it is impossible now. :( |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Tue Nov 14, 2006 5:12 pm Post subject: |
|
|
| cooleyes wrote: | to Raphael:
I just want to test that can I use some vfpu code to instead of "MMX code" in PSP.
but I think it is impossible now. :( |
Yeah, you simply cannot compare VFPU to MMX :) MMX is int based and not really a vector processing scheme.
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Tue Nov 14, 2006 5:45 pm Post subject: |
|
|
| cooleyes wrote: | to hlide:
I have made a mistake, the new code didn't work.
I found my demo app use the old code last night,
so it can work no crash.
but when I use the new code , it crashed.
|
it would be interesting to say where it crashed, precisely in the "new" code or when exploiting the result ? this is quite different. And when you say crash you are supposedly having it compile well then running it, are you ?
Normally the conversion short->int->float should at least work since I have tested it by coding it in RTPS function (GTE) with a PCSX-like emulator source for psp and test it with a psx game using RTPS. I never tested the reverse conversion (i mean vfpu int->short conversion), so I'm less confident. |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Tue Nov 14, 2006 6:19 pm Post subject: |
|
|
| hlide wrote: | | I never tested the reverse conversion (i mean vfpu int->short conversion), so I'm less confident. |
It should be ok, I used the same way for converting the short blocks to floats and vice versa for the iDCT in ffmpeg.
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
chp
Joined: 23 Jun 2004
Posts: 313
|
| Posted: Tue Nov 14, 2006 6:25 pm Post subject: |
|
|
You can also use alloca() and align that address, since it also allocates from the stack and is a bit more clean than aligning a local array (it is how I align buffers in gum/vfpu). Also, there is no point using memalign() to allocate memory since malloc() is already quad-word aligned these days.
_________________
GE Dominator |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Tue Nov 14, 2006 7:37 pm Post subject: |
|
|
| chp wrote: | | You can also use alloca() and align that address, since it also allocates from the stack and is a bit more clean than aligning a local array (it is how I align buffers in gum/vfpu). Also, there is no point using memalign() to allocate memory since malloc() is already quad-word aligned these days. |
GE dominator ? are we speaking about the Graphics Engine ? Ooooh you may interest me. |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Tue Nov 14, 2006 8:13 pm Post subject: |
|
|
| chp wrote: |
Also, there is no point using memalign() to allocate memory since malloc() is already quad-word aligned these days. |
I just mentioned memalign to make clear that I was going towards aligned memory (a lot of people still aren't aware about the malloc alignment)
| hlide wrote: |
GE dominator ? are we speaking about the Graphics Engine ? Ooooh you may interest me. |
Yes, GE as in Graphics Engine :) He's the one behind all the GU SDK samples and the most knowledged person about GE/GU in the whole scene ;)
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
