Steve Checkoway
7671e73bb6
Use sysctlbyname.
2007-07-23 05:23:30 +00:00
Steve Checkoway
58715e319f
It seems that gcc decided that even though _mm_load_ps and _mm_loadu_ps are static inline functions calling a gcc builtin, it should emit a call to them because they were used as template parameters. Oh well, the code is short enough to just copy.
2007-01-28 23:12:06 +00:00
Steve Checkoway
1bb3190d62
Year.
2007-01-28 22:27:52 +00:00
Steve Checkoway
f4d616e7a2
Update for floating point. No need to bother with the integer read because OS X doesn't use it.
2007-01-27 17:09:15 +00:00
Steve Checkoway
02282d4a14
Loosen sse read restrictions. Tested.
2006-12-11 13:26:12 +00:00
Steve Checkoway
0c539b83ce
Loosen altivec read restrictions. The src buffer still needs to be 16 byte aligned but the dest buffer only needs to be aligned for the type (2 bytes for int16_t and 4 for float).
2006-12-11 13:02:57 +00:00
Steve Checkoway
d5e67ae508
The data is not unaligned, it will be aligned at the boundary natural for its size or larger. (Typically at a sizeof(void*) boundary.) It is misaligned in the sense that it isn't at the 16 byte boundary we require.
2006-12-11 10:33:35 +00:00
Steve Checkoway
5e87581379
No need to assert, these are only used in once place and the preconditions are checked. Remove dependence on RageUtil (and global.h). Makes this easier to test.
2006-12-10 13:24:06 +00:00
Steve Checkoway
c850d0d86c
Remove bogus assert. As long as dest is on a 4 byte boundary and src is on a 2 byte boundary (which gcc will ensure unless you're casting into to those types), this works correct. (Retested.)
2006-12-10 11:08:17 +00:00
Steve Checkoway
e9651a568f
Undef.
2006-09-08 05:40:39 +00:00
Steve Checkoway
c06c8470a3
Fix prototype.
2006-09-08 05:36:29 +00:00
Steve Checkoway
bd7422ef6e
Specialize on aligned loads for sse since misaligned loads are much slower.
2006-07-17 00:42:46 +00:00
Steve Checkoway
7dce2e2825
Fix the (unused) float version for sse.
2006-06-19 05:21:10 +00:00
Steve Checkoway
b8e1db595a
Fix the (unused) float version for altivec.
2006-06-19 04:04:10 +00:00
Steve Checkoway
7ba8eefebf
Apparently we want data1 before data2. (Tested.)
2006-06-19 03:21:25 +00:00
Steve Checkoway
7dbdc89b8c
Fix misaligned load/store. Also, these are little endian so merge the low order bytes first. Since this code _is_ portable, I can test it on x86 linux.
2006-06-19 02:53:14 +00:00
Steve Checkoway
36f6042ef0
Cleanup.
2006-06-18 18:49:23 +00:00
Steve Checkoway
de4a22d9e0
Reuse variables. (I'm hope gcc was smart enough to reuse the registers on its own, but I didn't actually check. This way we should be using fewer than 32.)
2006-06-18 18:41:22 +00:00
Steve Checkoway
66dfad63b0
Be careful not to read past the end of the data. With aligned loads (which are every load in altivec), it is always okay to load a vector if you can access any element of that vector. It is not always okay to load the next vector.
2006-06-18 18:30:28 +00:00
Steve Checkoway
acf04db9f9
Implement with SSE but don't enable since I can't test it. It should be portable since I used Intel's intrinsics.
2006-06-18 18:10:14 +00:00
Steve Checkoway
af5f6f4edb
Cleanup.
2006-06-13 12:41:40 +00:00
Steve Checkoway
b7c1412a70
Re-enable vector code. FastSoundWrite can now handle a dest that is not 16 byte aligned although it will be fastest if dest is 16 byte aligned and size is a multiple of 8.
2006-06-13 12:30:51 +00:00
Steve Checkoway
2754fd0f18
Perform the same loop unrolling for Read. This eliminate all stalls in the loop for all processors with altivec (well, at least both G4s (IBM 7400 and 7450) and the G5 (IBM 970) processors. I didn't bother for the other read function since it isn't actually used and is included more for completeness than anything else (plus, these were a lot of fun to write).
2006-05-17 09:59:34 +00:00
Steve Checkoway
177e65a34c
Do gcc's job for it and do sane loop unrolling. The (now second) while loop was stalling the pipeline almost as often as it was doing useful work. When gcc tried to do loop unrolling (i.e. when I changed the condition to size >= 8), it produced 4 _identical_ copies of the loop, each of which had the same number of stalls (this is all with the G5, the G4 had one stall in the loop). By unrolling and doing the most basic of instruction scheduling, this produces the same amount of code as gcc does but with 1 stall in the big loop (0 for the G4) but the same number in the second loop which is executed at most 3 times.
...
To keep gcc from unrolling the second loop, I'm using the bit masking condition which confuses the optimizer.
Note that this behavior won't change unless we stop targeting any OS below 10.3.9 and move to a more recent version of gcc (whose behavior I haven't bothered to test).
2006-05-17 09:27:54 +00:00
Steve Checkoway
b912d61546
Following Wolfman's example, some comments so that maybe next time I look at this I won't see vec_ctf and think "capture the flag?"
2006-05-14 08:13:16 +00:00
Steve Checkoway
f39e79efed
The last of the changes, I hope.
2006-05-14 07:04:28 +00:00
Steve Checkoway