Modding, Mission Design, and Coding > Cross-Platform Development

Using SSE based data structures

(1/3) > >>

PeterMitsis:
Platform - Ubuntu 16.04
Target - x86-64

Although the current x86 builds for Linux and Windows utilize the SSE instructions, the math is done on a single element basis instead of on the vector as a whole.  I am currently playing around on an Ubuntu 16.04 (64-bit) machine to see if I can upgrade the vector/matrix  code to use the SSE vector instructions (where applicable).

To that end, I have first updated (no SSE math yet) ...

1. 'vec3d' to use four elements for easy mapping to the SSE xmm registers (although the fourth element is currently unused).
2. 'matrix' to use the new four-element 'vec3d' structures
3. Various places that use the 'a1d' interface to 'vec3d' or 'matrix' variables
4. Various places that use the 'a2d' inteface to the 'matrix' variables
5. Checked for hard coded sizes of 'vec3d' and 'matrix'.
6. Checked for use of 'sizeof(vec3d)' and 'sizeof(matrix)'.

The good news is that everything builds, and the game appears to run (using an original installation of FS2). The bad news is that the ships are misshapen. Obviously I have missed something.  But what?  My guess is that something, somewhere (rendering code? ship models?) is expecting a 'vec3d' to be 12 bytes (3 floats) and/or a 'matrix' to be 36 bytes (9 floats) but I do not know what/where. If anyone has any suggestions, they would be greatly appreciated.

The E:
A few suggestions here: One, don't try to roll your own vector math library. I think it would be preferable if a library like glm is used, because it already has a lot of the SSE/AVX stuff built in. Two, if you change the vector format, then every point where vector data is fed to opengl needs to be checked and adjusted too.

General Battuta:
Holy **** I want screenshots of these ****ed up ships.

Phantom Hoover:
Seconded. Get that **** on github!

(Probably this is something that could be controllably faked with shaders if you want crazy ****ed up Nagari ships.)

Kobrar44:
This may differ, but I think I know what happens. I tried that, so I'll share my experience and conclusions.

My result was caused by some a2d matrix reference, once I fixed that, it went away.
There is, however, still one more thing to do. Al least one.
The models are loaded into a buffer. Straightup. Byte after byte, pof model files are copied over. This is really bad actually. Why?
Well, to have models we need vertices and to have vertices we need vectors. in POF the vectors are I believe setup like this: xyzxyzxyzxyz etc. FSO knows where in the file is the first vector because it knows the file structure, and knows how many vectors there are, so it just saves all the pointers to the vectors from the buffer in an array. So this would be the first place where things **** up.  Right now it saves pointer to xyz then increments the pointer so it points at next xyz etc etc etc. With 16 byte vector, you save pointer to xyzx and then yzxy. I figure I'd need to either rewrite the thing to store vectors neatly, which would be slower, or somewhat reparse the file adding w component to all vectors for compatibility with the rest of the code in place, but that would also be slower. Not slower solution would be new model format[that topic has been around for a while too][also requires a solution for backward compatibility]. I also realised that since the major bottleneck is collision code, then probably it is also caused by memory reads rather than actual math[because traversing trees], but any gain is welcome. I didn't get anywhere, because I didn't feel it would be worth it.

EDIT: OR I am totally wrong on everything. That's an option too.
Also, I'm surprised you got no errors for referencing random memory after the buffers.
EDIT2: Also keep in mind, in order to actually utilize SSE properly, vectors need to be memory aligned to 16 bytes.

Navigation

[0] Message Index

[#] Next page