Spring is running in SMP

[Auswaschbar]

Just wanted to add some info from another thread:

MT can give you very high FPS in big games, but if you use some heavyweight widgets that for instance do lots of drawing on screen (healthbars, special effects...) the required synchronization will interfere with the Sim, so that your CPU load will be higher than with regular Spring.

So, for the best MT experience be very careful when choosing widgets ...

Possibly the above is also the reason why some people reported MT to be slower than regular Spring.

Nope, its also slower when I disable all widgets. I guess its somehow related that another person with the same problem is also running gentoo 64bit.

[Manoa]

"Does not work with all mods and widgets" doesn't sound very descriptive, but that much is already known since the SMP was first made exists, I had expected that http://springrts.com/wiki/OtherDownloads would be alot more specific, to specify exactly which mods and which widgets the version does/doesn't work with, or maybe add a few more information such as testing practices, and whatever else that can be added about it, the page is very short and could use filling up

WHOA !, doubled my framerate, 100% cpu scaling ! and no stutter !

[zerver]

I get your point, but anyone can edit that page so please add the information yourself. There are many mods/widgets and also different versions and I don't have time to test them all...

[DuGi]

after some system updates i can't build spring smp anymore. what is wrong?

Code: Select all

[ 10%] Building CXX object rts/lib/CMakeFiles/gml.dir/gml/gml.cpp.o
In file included from /home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gml.cpp:698:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlTexImage2D(GLenum, GLint, GLint, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1111: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlColor4fv(const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1112: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlDeleteTextures(GLsizei, const GLuint*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1116: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlLightfv(GLenum, GLenum, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1127: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmluBuild2DMipmaps(GLenum, GLint, GLsizei, GLsizei, GLenum, GLenum, const GLvoid*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1128: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlMultMatrixf(const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1136: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlMaterialfv(GLenum, GLenum, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1139: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlVertex3fv(const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1144: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlTexGenfv(GLenum, GLenum, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1145: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlFogfv(GLenum, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1149: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlTexSubImage2D(GLenum, GLint, GLint, GLint, GLsizei, GLsizei, GLenum, GLenum, const GLvoid*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1152: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlClipPlane(GLenum, const GLdouble*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1153: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlDeleteFramebuffersEXT(GLsizei, const GLuint*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1159: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlLoadMatrixf(const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1160: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlDeleteRenderbuffersEXT(GLsizei, const GLuint*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1164: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlCompressedTexImage2DARB(GLenum, GLint, GLenum, GLsizei, GLsizei, GLint, GLsizei, const GLvoid*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1168: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlMultMatrixd(const GLdouble*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1171: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlColor3fv(const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1177: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlTexEnvfv(GLenum, GLenum, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1182: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlUniformMatrix4fv(GLint, GLsizei, GLboolean, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1183: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlColor3ubv(const GLubyte*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1187: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlLoadMatrixd(const GLdouble*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1191: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlTexImage3D(GLenum, GLint, GLenum, GLsizei, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1194: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlProgramEnvParameter4fvARB(GLenum, GLuint, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1203: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlBufferDataARB(GLenum, GLsizei, const GLvoid*, GLenum)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1211: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlCompressedTexImage1DARB(GLenum, GLint, GLenum, GLsizei, GLint, GLsizei, const GLvoid*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1214: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlCompressedTexImage3DARB(GLenum, GLint, GLenum, GLsizei, GLsizei, GLsizei, GLint, GLsizei, const GLvoid*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1215: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlPointParameterfv(GLenum, GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1224: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlProgramStringARB(GLenum, GLenum, GLsizei, const GLvoid*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1226: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlTexImage1D(GLenum, GLint, GLint, GLsizei, GLint, GLenum, GLenum, const GLvoid*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1232: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlUniformMatrix2fv(GLint, GLsizei, GLboolean, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1241: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlUniformMatrix3fv(GLint, GLsizei, GLboolean, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1242: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlColor4ubv(const GLubyte*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1249: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlDeleteBuffersARB(GLsizei, const GLuint*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1253: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlDeleteFencesNV(GLsizei, const GLuint*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1254: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlDeleteProgramsARB(GLsizei, const GLuint*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1256: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlDrawBuffersARB(GLsizei, const GLenum*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1259: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlNormal3fv(const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1267: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlShaderSource(GLuint, GLsizei, const GLchar**, GLint*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1271: error: ÔÇÿstrlenÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1271: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlShaderSourceARB(GLhandleARB, GLsizei, const GLcharARB**, GLint*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1272: error: ÔÇÿstrlenÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1272: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlTexCoord2fv(const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1273: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlTexParameterfv(GLenum, GLenum, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1274: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlUniform1fv(GLint, GLsizei, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1276: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlUniformMatrix4fvARB(GLint, GLsizei, GLboolean, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1278: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlLightModelfv(GLenum, const GLfloat*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1281: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlDeleteQueries(GLsizei, const GLuint*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1282: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlDeleteBuffers(GLsizei, const GLuint*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1293: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlBufferData(GLenum, GLsizeiptr, const GLvoid*, GLenum)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1295: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h: In function ÔÇÿvoid gmlCompressedTexImage2D(GLenum, GLint, GLenum, GLsizei, GLsizei, GLint, GLsizei, const GLvoid*)ÔÇÖ:
/home/dugi/test3/src/spring_0.80.5.2/rts/lib/gml/gmlfun.h:1298: error: ÔÇÿmemcpyÔÇÖ was not declared in this scope

[hoijui]

fix for that is now on 0.80.5-branch branch of the spring main GIT repo on github.

[Caydr]

Dumb questions from a dumb person who likes asking dumb questions. Please don't waste your time replying if these are just too simple-minded for you to give proper answers:

Do you think this will be integrated into Spring's main branch in the near future? Say, 6 months? A year? I've followed this thread occasionally, it seems like you're clearing hurdles and making progress, but obviously it is a troublesome process.

If/when it becomes part of the main package, how do you foresee processor scaling working? Many games benefit tremendously by just offloading functions to a second core if possible, but when you go to 3-4+ cores, the difference is only seen in background applications, benchmarks, and heavy-duty stuff. Within 2-3 years, 12-core processors will not be an unusual thing to find at a geek-oriented computer store.

From what I understand, a big problem is keeping things in sync. Hypothetically, if you could guarantee that, say, four identical cores would remain completely dedicated to Spring and unused by anything else, would this quickly help you a lot, or is it like the way that if you do the same thing twice, if you use enough precision, no matter what the result will be slightly different? What I'm imagining is some kind of future paradigm where entire cores could be dedicated to a single task, operating in a protected mode without any interference.

What about hyperthreading? With i7, Intel's brought this back to the light of day. Photoshop and Max, this kind of professional program tends to benefit from parallelization a lot, even if it means the absolute overall number and speed of available processor cycles may be reduced. Would this be the same case with Spring, or is the one big simulation thread too important to break up?

One last question if you don't mind, is Spring by its complex nature extremely difficult/impossible to effectively break up into small chunks, or is it a matter of this just being such a new concept after so many years of everything being developed the old way? Since you're obviously a smart person if you're even capable of comprehending these complex things, do you think games, RTS games and other large complex simulations in particular, in the future can be designed ground-up to be highly multi-threaded? Or are games, especially fast multiplayer games or complex simulations, simply not capable of being developed this way because of the synchronized environment that they require?

[zerver]

It is integrated in the Spring main branch since more than a year. You only have to compile with different flags to get a multithreaded executable.

I don't see that the single threaded build could be replaced by MT anytime soon, mainly because it has issues related to LUA. Solving the LUA issues would require that the synchronization interface be exposed to LUA. I.e. all LUA programmers would suddenly have to be multithreading aware, to lock and unlock resources and so on.

Processor scaling is bad and it would require a new way of thinking to speed this up. Right now you get a big boost with two cores, and some additional FPS with 3-4 cores. After that, even though it indeed uses all cores, the benefit is minimal or it may even run slower with too many cores.

The main issue to get better scaling is the sync. Sync requires that all calculations occur in the same order. Typical ways of doing multithreading do not satisfy this criterion. A + B does not equal B + A. If Sim somehow could be broken down into completely independent work packages so that e.g. the unit order could be changed without any ill effects, then we might see some interesting progress on the MT side.

Hyperthreading is usually good for any multithreading application although there is a risk that the OS would schedule two threads to run on the same physical core. I guess the Sim thread is the most important one and you don't want it to compete with the rendering too much. The main reason why hyperthreading is better than you would expect is that another thread is immediately ready to run when some thread has to wait for data from the main computer memory.

To require exact reproducibility is highly unusual in the computing world. Games generally speaking do not require it. Most simulations are run with very high precision and a slight round off error or so does not matter. Therefore most games will soon be heavily threaded if they are not already. The question is how we can get Spring on the same track. One possibility would be to run two identical simulations in parallel, with one running one Sim frame behind the other. This opens up new interesting ways of creating independent work packages, but it also gives rise to shitloads of new problems.

[Argh]

I don't see that the single threaded build could be replaced by MT anytime soon, mainly because it has issues related to LUA. Solving the LUA issues would require that the synchronization interface be exposed to LUA. I.e. all LUA programmers would suddenly have to be multithreading aware, to lock and unlock resources and so on.

Why? Can't all unsynced Lua just run on processor 2, all synced on processor 1?

[zerver]

Why? Can't all unsynced Lua just run on processor 2, all synced on processor 1?

No, synced or unsynced does not matter here. This is about avoiding a crash

If unsynced LUA wants to read e.g. unit data, this must be synchronized so that the Sim does not delete the unit while the data is being read.

[Argh]

So... you can't put synced-->unsynced communications into a memory space reserved for either synced or unsynced to read from, and only allow access to it on alternate cycles, where synced can read the memory, then unsynced, and so forth?

Oh, wait, you're saying that unsynced doesn't know the state of the sim, so it can't use that.

So why not just store sim states twice, so there's a safe place for unsync to reference everything?

[zerver]

Sorry, but I'm not exactly sure what you mean by alternate cycles here. All communication between threads must be properly synchronized and alternating who has access isn't going to help anything.

Edit: double sim state, yeah I mentioned that above, but then unsynced may be one frame behind.

[Argh]

Well, I thought the problem was that sim and unsync, running on different cores, will crash if they're both reading / writing that data?

So I was thinking that it could behave like a framebuffer, where unsync is reading the data of the last sim cycle while sim updates the alternate memory location. Anyhow, sorry if that's a useless idea.

And "one frame behind" may be mitigated in various ways. Perhaps positions of certain things could be interpolated forwards a bit to minimize visual errors.

[Auswaschbar]

Well, I thought the problem was that sim and unsync, running on different cores, will crash if they're both reading / writing that data?

So I was thinking that it could behave like a framebuffer, where unsync is reading the data of the last sim cycle while sim updates the alternate memory location. Anyhow, sorry if that's a useless idea.

And "one frame behind" may be mitigated in various ways. Perhaps positions of certain things could be interpolated forwards a bit to minimize visual errors.

Also, if you run the simulation once on every core, you get the most out of your CPU time

[Argh]

Well... the parts of sim that are visual aren't the biggest CPU-suckers. You certainly wouldn't want to bother with pathfinding, etc., just the visuals- COB states, projectile states, unsynced Lua and CEG.

So yeah, you'll lose overall efficiency, but it's probably an acceptable tradeoff.

Anyhow, sorry if all of this was unwelcome, was just trying to be helpful and understand the current issues.

[Caydr]

Thanks for the answers.

Sorry about the "branch" misunderstanding, I was just using words that seemed to make sense to show off my developer cred. I meant, "when will this be the thing I download by default, since the verb 'compile' frightens me?"

[SpliFF]

Just read 24 pages of posts. My eyes hurt.

Hey zerver. great work on this! It's clear there are many hurdles involved in separating drawing code out from the sim.

Letting you know that I'm about to throw my hat into this arena too. I'm working on a branch to significantly refactor the drawing code. Priority one is to move any remaining sim-side drawing and model code into rendering and loading threads and only synchronising piece transforms.

I'll also be attacking the issue from the other end, using my Lua knowledge to push rendering code out of any remaining synced gadgets. You've already achieved a lot in this direction just by making authors aware of the issues. I can see that many gadgets that were previously broken now work either due to GML or the authors updating them.

My plan is to only have 1 rendering thread, I don't want to have to deal with GL synchronisation and I don't believe from anything I've just read that there's much to gain in having parallel renderers. The same amount of effort put into adding new shaders and migrating displaylist and texture code to VBO's and PBO's (on supported hardware) will have a bigger impact on framerates and CPU load.

I've posted a PDF Outline of the proposed class structure (30KB) showing the proposed synced/unsynced boundary. Unsynced classes will be moved to the rendering thread. Model loader will get a thread per import, allowing assets to load in parallel (4 CPUs = 3-4 models loading simultaneously). The model loader threads use mutexes to tell the sim when an asset is ready for use (EDIT: and all players "sign-off" on the loaded pieces letting the sim know it can initiate the build/fire order on the following frame. Auswaschbar says not required)

I'll be building closely on what you've done so far and hope to merge our efforts into a cleaner, faster and more reliable system.

I guess now would be a good time to ask whether there are any specific parts of your system that require attention.

[zerver]

My plan is to only have 1 rendering thread, I don't want to have to deal with GL synchronisation and I don't believe from anything I've just read that there's much to gain in having parallel renderers.

If the rendering code can be purified so it is doing nothing else than feeding the GFX card with OpenGL commands, then your assumption is correct. Right now, since the code is mixed with some matrix calculations and other CPU heavy stuff, parallel rendering may give a small gain - it depends on your hardware (relationship between how fast your CPU and GFX card is). My previous computer gained ~10% from parallel rendering while this one does not seem to benefit at all.

Anyway, good that you want to join MT development.

[Das Bruce]

Aww

[Manoa]

Code: Select all

LuaRules::RunCallIn: error = 2, RecvFromSynced, [string "lups/ParticleClasses/simpleparticles2.lua"]:365: Invalid call

it's strange I get this error because Lups/Manager are disabled, is this because of Lua shaders enabled ?

[ginekolog]

How does MT build work now? super stable or still freezes or crashes?

I really miss MT builds in FFA games as it makes game supersmooth :) Stoped useing em after nasty freezes in 20% of games.