VFPU - vt4444.q, vt5551.q, vt5650.q - color conversion

[hlide]

hi

well, i was puzzled by those instructions; there is no doubt they deal with color conversions but how to use them ?

binutils describes them as an instruction reading a 4-element register and writing a 2-element register.

well, the only logic i can see is that they probably take 4 rgba8888 pixels (fitting four 32-bit words) to transform them into 4 rgba4444 or 4 rgba5551 or 4 rgba5650 pixels (fitting two 32-bit words). So I guess they are to be used for converting large buffer of rgba8888 into one of the three colors representations.

I didn't check them but I don't see any purpose else.

Could you confirm it if it is already known ? those instruction are not decribed in the "unofficial" document of groepaz.

[hlide]

i did this test :

Code: Select all

vfpu_rgba8888to4444:
 	lvl.q C000.q,12(a0)
 	lvr.q C000.q,0(a0)
 	vt4444.q C010.p,C000.q
 	svl.q C010.q,12(a1)
 	jr ra
 	svr.q C010.q,0(a1)

with a0 containing 4 ints { 0x000000FF, 0xFF000000, 0x01020304, 0x10203040 } and i get { 000F, F000, 0000, 1234 } which confirms the usage of those instructions :

convert 4 rgba8888 into 4 rgba4444 or 4 rgba5650 or rgba5551.

It doesn't seem there are the reverse instruction though.

I think a rgb888 to rgba8888 would have been more interesting :/




[/code]

[Raphael]

i did this test :

Code: Select all

vfpu_rgba8888to4444:
 	lvl.q C000.q,12(a0)
 	lvr.q C000.q,0(a0)
 	vt4444.q C010.p,C000.q
 	svl.q C010.q,12(a1)
 	jr ra
 	svr.q C010.q,0(a1)

with a0 containing 4 ints { 0x000000FF, 0xFF000000, 0x01020304, 0x10203040 } and i get { 000F, F000, 0000, 1234 } which confirms the usage of those instructions :

convert 4 rgba8888 into 4 rgba4444 or 4 rgba5650 or rgba5551.

It doesn't seem there are the reverse instruction though.

I think a rgb888 to rgba8888 would have been more interesting :/

Thanks for the confirmation. I don't get the point with rgb888 to rgba8888 though. You just need to append a 0xff byte for every pixel, that's not very time consuming (little more than a straight mem copy). Apart from that, real 24bit shouldn't be used anywhere after all. It only creates overhead and has no real advantages.
On another note, reverse conversion functions would have been nice indeed, especially for image loading functions.

[hlide]

I don't get the point with rgb888 to rgba8888 though. You just need to append a 0xff byte for every pixel, that's not very time consuming (little more than a straight mem copy). Apart from that, real 24bit shouldn't be used anywhere after all. It only creates overhead and has no real advantages.

well for PSX emulation (i'm working on a PSX dynarec right now) we could have treat 4 rgb into 4 rgba in one instruction. But well, I know that you're right.

On another note, reverse conversion functions would have been nice indeed, especially for image loading functions.

yes strangely enough i don't see any in binutils (all the allegrex instructions are dicovered ?).

[Raphael]

I suppose they are complete. I could imagine sony stripped those functions because they saw not enough need versus transistor cost. After all, I don't see that much need for upscaling low-quality color codes into higher ones anyway, since there is no quality-gain whatsoever. It would only be useful if you were limited to 8888 format on PSP, but that's not the case. Still it would have been nice ;P