OSDev.org https://forum.osdev.org/ |
|
sse2 blit and conversions https://forum.osdev.org/viewtopic.php?f=13&t=30740 |
Page 1 of 1 |
Author: | mariuszp [ Thu Aug 25, 2016 9:46 am ] |
Post subject: | sse2 blit and conversions |
i am trying to implement SSE2 blitting and encountered a problem. If I take a 32-bit RGBA value from each image, and I want to perform alpha blending and save the result in the destination image, the first thing I would have to do, to use SSE2, would be to convert this vector of 8-bit integers into four packed single-precision floating-point values, in the range 0-1. I know i can scale the values to 0-1 by just multiplying by (1/255, 1/255, 1/255, 1/255). But how can I convert the 8-bit integers into floating-points efficiently? Or am I looking at this the wrong way entirely? Thank you for help |
Author: | jnc100 [ Thu Aug 25, 2016 10:25 am ] |
Post subject: | Re: sse2 blit and conversions |
Its not easy using only sse2. If you can use sse4.1 then you can use pmovzxbd to do the load then cvtdq2ps to do the conversion. Otherwise for sse2 its a bit clunky. (untested) code: Code: zero:dq 0 Note that you should probably keep the graphics data in floating point format (within the range 0.0-1.0) for the entirety of the data path and finally only convert back to integers at the end.load_func: movq xmm1, [zero] movq xmm0, [data] punpcklbw xmm0, xmm1 punpcklwd xmm0, xmm1 cvtdq2ps xmm0, xmm0 Potentially, if you're blitting images etc, then when you load them to a device context or whatever you would do the conversion to FP there, so it only needs doing once. Regards, John. |
Author: | mariuszp [ Thu Aug 25, 2016 12:30 pm ] |
Post subject: | Re: sse2 blit and conversions |
is there also an equally straight-forward way to convert back to bytes? |
Author: | jnc100 [ Thu Aug 25, 2016 12:59 pm ] |
Post subject: | Re: sse2 blit and conversions |
Again, if not constrained by sse2 its easy. If you must use sse2, then something like the following (untested again, essentially the reverse of the above): Code: zero: dq 0 You should then have the 32-bit packed value in the low 32 bits of xmm0. How you write that to display memory is up to you: most direct stores from sse registers will store at least 64 bits, so will overwrite the top 32 bits. If you are writing direct to the framebuffer from position 0 upwards then thats fine to do (repeated movqs). Otherwise, if you know the next pixel too, then put it into xmm1 above for the first pack instruction (and then zero for the second) and you'll have two 32-bit pixels in the low half of xmm0 which you can movq to screen even quicker. You can even optimise further and get 4 packed 32 bit pixels into xmm0 if you like (packusdw xmm0, xmm1; packusdw xmm2, xmm3; packusbw xmm0, xmm2). Otherwise if you want to be conservative, reserve some stack space, store 64 bits there, pop into rax and then do a 32-bit GPR move.toint_func: movq xmm1, [zero] movq xmm0, packed_single_value cvtps2dq xmm0, xmm0 packusdw xmm0, xmm1 packuswb xmm0, xmm1 Regards, John. |
Author: | mariuszp [ Thu Aug 25, 2016 1:04 pm ] |
Post subject: | Re: sse2 blit and conversions |
Considering SSE 4 is supported (AFAIK) on all CPU since 2006, I think I can use that too. |
Page 1 of 1 | All times are UTC - 6 hours |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |