Dev meeting minutes 2010-10-10

Dev meeting minutes 2010-10-10

Minutes of the meetings between Spring developers are archived here.
abma
Spring Developer
Posts: 3560
Joined: 01 Jun 2009, 00:08

Dev meeting minutes 2010-10-10

Post by abma » 10 Oct 2010, 22:34

Date: Sunday, 10. October 2010 (2010-10-10)
Present: abma, hoijui, Tobi, zerver


_Agenda_____________________________________________________________________
* Welcome
* Release plan
* lua state split (EXPORT and Script.XXX)
* the big refactor
* Anything else? (WVTTK)

_Topics_______________________________________________________________________
Welcome
<abma>hey!
<zerver>hi
<zerver>hoi is in etherpad, but not here
<hoijui>hey
<zerver>hi
<hoijui>i guess you did not start?
<zerver>no, too few ppl
<hoijui>mm
<hoijui>enough now?
<zerver>think so



Release plan
<zerver>thanks
<hoijui>:D
<hoijui>theres some kids .. theatre like thing on audio casettes ehre
<hoijui>si eveyrone here?
<hoijui>really?
<hoijui>absolutely sure?
<hoijui>wonderfull!
<hoijui>:D
<hoijui>=== Release plan ===
<zerver>is tobi afk?
<hoijui>plan is, to have some test games (after meeting) on the release branch
<hoijui>ouh..
<hoijui>yeah lets wait for him
<hoijui>ping [RoX]Tobi, abma_irc
<Tobi>hey
<hoijui>hey :-)
<abma>hey :-)
<hoijui>:-)
<Tobi>working on something else in the mean time so I seem to be a bit half afk-ish :-)
<hoijui>ok
<hoijui>issues known so far with .6 candiadte:
<hoijui>KAIK freeze
<hoijui>bad plasma visuals (in S44)
<hoijui>though the later is in since 0.82 already
<hoijui>and KAIK freeze.. we know the guilty commit, which is not too important
<hoijui>is KAIK only
<zerver>KAIK bug or spring bug?
<hoijui>KAIK
<hoijui>or say..
<hoijui>maybe not.. but the changes are only in KAIK, and they affect only some debug drawing of paths
<hoijui>and if you undo them. it does not freeze
<zerver>k
<hoijui>though.. kloot put multiple things in one commit so i had to separate these changes out
<hoijui>anywya.. that is no big problem
<Kloot>hey
<zerver>lo
<hoijui>need to test FPS bug, rejoin and spec icons
<hoijui>hey! :D
<hoijui>[16:32:21] <[ARP]hoijui_g5> === Release plan ===
<hoijui>ghsted buildings visible by specs i mean
<hoijui>not spec icons
<hoijui>smoth seems to be ok with it, did some gundam tests
<hoijui>Kloot, have you seen the KAIK related mantis report?
<zerver>i have not seen any ghosted buildings as spec with my fixed build
<Kloot>yeah saw it this morning
<hoijui>ok
<hoijui>zerver, what is your fixed build?
<zerver>special build from 0.82 branch
<hoijui>well.. we just have to test these things in the release branch, cause there might have been merge failer or something
<hoijui>ah
<zerver>yeah, test it again
<hoijui>k
<hoijui>guess. next then?
<zerver>and the rejoin particularly needs testing
<hoijui>hmmm
<zerver>it is kind of hard to test that by yourself
<hoijui>yeah :D
<hoijui>smoth will help testing he said
<hoijui>i will..
<hoijui>maybe BD too
<zerver>i have 4 PCs in one room though, i
<hoijui>:D
<zerver>so it can be done
<zerver> :)
<hoijui>next?
<zerver>yup
<hoijui>lets skip comk enhancement with devs..
<hoijui>or shoudl we have it?
<hoijui>today i mean
<zerver>i have nothing to add
<hoijui>mm k
<hoijui>can still do it later if someone wants it

main points:
* need to test the fixes for FPS bug, rejoin and spec icons in the release branch



lua state split (EXPORT and Script.XXX)
<hoijui>ah well..
<zerver>would be nice to have jK here
<hoijui>without jk, and Tobi half afk, i guess.. this makes no sense to discuss either :/
<hoijui>mmm
<zerver>sorry to hear about his tragic loss
<hoijui>mmm
<Kloot>oh wow, I just read etherpad
<zerver>we had a long 15min silence at meeting start out of respect of the dead
<hoijui>so.. we are at end of meeitng laready :D
<zerver>maybe I can say something about EXPORT
<hoijui>yeah sure..
<hoijui>we can also discuss the big refactor stuff
<hoijui>after that
<zerver>don't know I you read my posts, but I tested converting CA to use EXPORT table
<hoijui>i owuld have soem thigns to day htere
<hoijui>i read something.. it is too expensive?
<zerver>yeah, unplayable
<zerver>but I think this table is good to have anyway, it just needs some tweaking of the mod
<Kloot>some?
<zerver>yeah, don't store too much stuff in the table, delete if after SendToUnsynced, etc
<Kloot>CA has 1000 gadgets that need synced->unsyced comms
<zerver>not exacly, i think i touched 10 gadgets with my search and replace
<zerver>in BA 2 gadgets were affected, and it was very playable
<Kloot>hmm, sounds like it does not scale well then
<zerver>well, the whole table is sent on every SendToUnsynced, and also every GameFrame
<zerver>so not very surprising
<hoijui>use git
<zerver>:)
<zerver>put the table on github and only pull the changes
<Kloot>gl with that -_-
<zerver>the way I see it, EXPORT may simpify to send large objects
<zerver>but you cannot permanently store big stuff there
<Kloot>nor lots of small stuff
<zerver>SendToUnsynced does not support tables atm
<zerver>so you can put the table in EXPORT, SendToUnsynced, and then EXPORT.table = nil
<Kloot>right
<Tobi>wouldn't it be possible to make the synced side record the changes, so the copying is only O(number of changed values) instead of O(total number of values)?
<Kloot>tables are the main reason for using the GG route
<Tobi>might be hard to do though
<Tobi>I don't completely recall how versatile things like __newindex are
<zerver>I thought about ways of sending only changes, but my LUA s
<zerver>skill is limited
<zerver>looping through the table to see what has changed wont work, it takes too much time
<Tobi>yeah that is moot
<Tobi>the point is to keep track of the changes while they are being made of course, so the algorithmic complexity of the copying can be reduced :)
<zerver>yup
<zerver>anyway, maybe jK has some suggestion
<Tobi>but it might be pretty hard if e.g. _G.table.X is first changed and then later _G.table is bound to a different value
<hoijui>mmm
<Tobi>then _G.table.X doesn't need to be copied anymore
<Kloot>also depends on whether the changes are of the sort t[k] = t[k + 1] or t[k] = {some huge table}
<Tobi>yeah that too
<zerver>anyway, im happy that CA actually worked with the EXPORT, even though it was unplayable framerate
<Tobi>how often do you copy data?
<Tobi>you changed the Lua to use EXPORT instead of _G already there?
<zerver>[16:43:29] <zerver> well, the whole table is sent on every SendToUnsynced, and also every GameFrame
<Tobi>ah
<Tobi>what about trying to buffer SendToUnsynced too?
<Tobi>so you only need to copy the stuff once per GameFrame?
<Tobi>hmm
<zerver>yeah, maybe
<Kloot>won't that just cause one big blocking operation instead of multiple small ones?
<zerver>problem is, on sendtounsynced you need to record the EXPORT table at that very instant
<zerver>because a moment later, the data may be nil
<Tobi>Kloot: it also reduces the amount of copying
<Tobi>zerver: yeah true
<Tobi>or actually, I thought to copy only the latest EXPORT
<Tobi>but indeed that would change the semantics
<zerver> _G.EXPORT.burningUnits = burningUnits
<zerver> SendToUnsynced("onFire")
<zerver> _G.EXPORT.burningUnits = nil
<zerver>excerpt from CA
<Tobi>for excerpts like that it would actually be cleaner to be able to do SendToUnsynced("onFire", burningUnits)
<Tobi>although that would have the same performance impact (at least for the copying)
<zerver>yeah
<zerver>Regarding Script.LuaUI.XXX, I just need to extablish where the call should be directed in each case, where there is a synced and unsynced part
<zerver>If LuaUI has split states also, the "synced" part of it may invoke Script.LuaRules.XXX
<zerver>the question here if this call should end up on the synced or unsynced side of LuaRules
<zerver>any ideas? otherwise next point...
<Tobi>personally I still think LuaUI should preferably not be split, just the events queued in a buffer so a non-sim thread can process them at its own speed
<zerver>yeah, i did that also
<zerver>but I don't think we shall close the possibility that luaui may be threaded for real
<zerver>and some events have a return value and are a bit tricky to queue
<Tobi>even if luaui-draw won't have access to any sim things (i.e. no LuaSyncedRead), then I still don't like that in each widget one needs to implement a transfer mechanism for the desired data
<Tobi>that is something that should be handled by the engine IMO
<Tobi>zerver: aren't that only non-sim events?
<Tobi>zerver: since sim definitely can not use any value returned by LuaUI, as that would desync
<zerver>WorldToolTip...
<Tobi>sim doesn't need to know what it returns
<zerver>kk, well i did not attempt to queue that event
<Tobi>it is fired somewhere from the gui, I don't know in which thread that runs
<zerver>actually sim invokes it too
<Tobi>I would assume render thread
<Tobi>but then it can not use its return value
<Tobi>or it would desync
<zerver>but im not sure if it uses the return value...
<zerver> :)
<Tobi>by definition sim can not use anything returned by LuaUI for that reason
<Kloot>WTT is a pretty strange "event" anyway
<zerver>well, i have the queue, and optional split of LuaUI as well
<zerver>so everyone is happy, or I hope so


main points:
* zerver tested converting CA to use EXPORT table and had some performance problems



the big refactor
<hoijui>so the big refactor?
<zerver>ya
<hoijui>:-)
<hoijui>i would like to start wokring on it..
<hoijui>eg.. splitting the drawing out of the sim classes
<hoijui>or .. shoudl we do more plannign first?
<Kloot>getting the remaining draw code out of sim classes needs some planning too
<Kloot>projectiles especially
<hoijui>hmm.. becuase there coudl be more cshared code then is?
<Kloot>yeah, the simple way would be to create a RenderProjectile class hierachy
<Kloot>with duplicated data
<hoijui>hmmm
<hoijui>woudl it not be better to first separate
<hoijui>and later do this hirarchy
<hoijui>would make easier tracking if bugs
<Kloot>I meant that would be the simple way to separate things, not the best though
<hoijui>it woudl mean, creating some new files to be removed agian soon after, but.. well.. not really bad
<hoijui>you would do the two steps at once?
<zerver>more at once is probably mode bugs yeah, but also faster
<zerver>more
<hoijui>i would do eg an IProjectileDrawer, and one impl. for each projectile type, with directly copying the code out of the sim classes
<hoijui>then start mergign together what possible, creating new classes, eg: CAbstractProjectileDrawer
<hoijui>or woudl you want a single Projectile drawer class?
<Kloot>I'd prefer to build one the existing one eyh
<hoijui>...
<hoijui>dont get what you mean with that
<Tobi>in the end, a single projectile drawer class may be better I think, as that way rendering of projectiles could be completely orthogonal to their behaviour
<Tobi>well, not necessarily a single drawer class
<hoijui>ahh that is hte approach of alls stuff beeing made wiht properties, instead of classes?
<hoijui>classes/types
<Tobi>not sure what you mean, but I think the answer is no :)
<hoijui>ok :D
<Tobi>what I mean is the projectile classes in sim determine how the projectiles behave
<hoijui>i meant: instead of a cannon projectile type, have a property gravity-following
<Tobi>e.g. starburst / ballistic / torpede / bomb / whatever
<hoijui>mmm
<hoijui>yeah ballistic :D
<hoijui>so we coudl do it like:
<Tobi>and a `renderprojectile' can source any of the sim projectiles
<Tobi>(for it's position, speed, etc.)
<Kloot>I mean extending ProjectileDrawer as it exists now with a std::container<RenderProjectile*> where each RenderProjectile* points to a Projectile*
<hoijui>create a new class ProjectileDrawer, and in the draw(Projectile*) function, have a switch with one case per pprojectile
<Tobi>but render projectile hierarchy can contain things like like `bitmap', `animated bitmap', '3d model', etc.
<hoijui>mm
<hoijui>ok
<Tobi>maybe it's the same as what you meant Kloot?
<Kloot>seems pretty close yeah
<zerver>to get good performance with MT, render projectiles should be deleted by rendering thread, and not depend on sim projectiles
<Tobi>that way you could have any combo of behaviour and rendering, i.e. a torpedo rendered as lightning, a ballistic shell rendered as ICBM missile, etc.
<hoijui>how can htey not depend on sim projectiles?
<hoijui>you mean.. not directly depend on the smae instance of a projectile the sim uses?
<hoijui>that is what we woudl like to solve wiht the multi states
<hoijui>but i think these two changes can be made relatively independend from each other
<hoijui>eg.. first separate all rendering from sim classes, then do the multi states
<hoijui>if you keep that in mind
<zerver>sim must either keep the sim projectile alive until the render thread does not want it anymore, or the render projectile must have data duplication
<hoijui>it must have data duplication anyway
<hoijui>as sim might already set the position for the next frame, while render thread still draws old frame
<zerver>problem with current spring version is that a performance penalty occurs when objects are deleted
<zerver>sim must wait until draw thread is no longer rendering any projectiles, then delete
<Tobi>seems easy to solve
<zerver>with some data duplication, yeah
<hoijui>i though we agreed that data duplication is requried anyway
<hoijui>for having better MT support
<hoijui>question is just, if there will be 2 3 or 4 states
<Tobi>for just the deletion sim could just stuff the to-be-deleted projectiles in an array that is cleaned up a while later (or maybe by the render thread)
<Tobi>but yeah I guess data duplication will be necessary anyway
<Tobi>and that's a little harder to solve :)
<hoijui>mm
<hoijui>but.. it is a separate thing
<hoijui>qutie
<hoijui>quite*
<zerver>yeah, that we spoke about earlier, requires the actual deletion to be unsynced
<hoijui>btw.. oen important thing i wanted to say
<hoijui>we should take track of our branches in some way
<hoijui>as in..
<zerver>you mean a list that describes what branch does?
<hoijui>so we know who has big branches of what part
<zerver>ya
<zerver>probably best if one guy works on projectiles, someone else on units
<hoijui>mmm
<zerver>but we must also conside the suggestion that all object types are merged into one
<Tobi>pseudo code: sim: goes through each projectile for simulation. as side effect, put position/orientation/velocity in a `projectile buffer'
<Tobi>at end of game frame, projectile buffer is marked as ready and a new one is created (reused) for next frame
<zerver>yeah, triple buffered
<Tobi>next draw frame, renderer picks up the last projectile buffer and uses that for rendering
<Tobi>yup
<Tobi>with rendering actually keeping no state about projectiles
<Tobi>but I wonder if that works out properly
<zerver>there are probably plenty of gotchas
<Tobi>i.e. can all types of projectile rendering be implemented without state?
<zerver>units even worse
<hoijui>would be bad if this was a requriement, yeah..
<Tobi>units are a completely different beast, better solve one thing at a time imo :)
<hoijui>why can there not be RenderProjectivles with this approach?
<Tobi>there would be no way for the renderer to know which projectile in the buffer is which projectile in the previous buffer
<hoijui>if not relying on a pointer
<hoijui>and using a separate ID
<zerver>this discussion about merging units, features, ... into a common object type, that did not include projectiles I assume?
<Tobi>(though at the cost of some performance that could be solved by putting a ID in the buffer indeed)
<Kloot>it did
<zerver>Ok, important to have a small base class there
<Kloot>since at the bottom of the pool all those objects have the same requirements for rendering
<Kloot>ie pos/speed/model/some other data
<zerver>so question is, should we merge that first?
<zerver>because then we dont have to invent the wheel 5 times
<Tobi>projectiles already are CWorldObjects, right?
<Kloot>yes
<hoijui>we need better documentation commens describing these classes maybe
<Kloot>actually there is one class in between CProjectile and CWorldObject
<hoijui>do you want to eliminate the feature/unit class?or just move more stuff into base classes?
<zerver>good question
<zerver>another annoyance is the trees, they should be features
<Kloot>they are?
<Tobi>they are, right? (only with a different renderer)
<zerver>oh?
<Kloot>every tree is a cfeature already
<Kloot>but they are renderer by the treedrawer* family
<Kloot>rendered*
<zerver>good then
<Tobi>does sim always know beforehand what kind of data the renderer will need? (or could it be made like that?)
<hoijui>should it not simply copy all the sim state for the renderer?
<hoijui>eg, all mempers of class Unit
<hoijui>members*
<Tobi>I think that is an important question to answer, because it could affect the design a lot
<Tobi>I don't think so, that would probably be way too expensive
<zerver>copy all might be too slow
<Kloot>yeah, eg a huge subset of cunit is never touched by unitdrawer
<zerver>problem arises when Lua drawing wants to access member variable X
<Tobi>exactly
<zerver>I guess we don't want to limit what Lua is allowed to read...
<Tobi>correct
<hoijui>yeah
<Kloot>back to the what-to-copy problem again -_-
<Tobi>yeah
<hoijui>though.. isnt big part of cunit to be moved to unitdrawer anyway?
<zerver>the Lua problem, lol
<Tobi>I see at least two solutions
<zerver>spring is so powerful that redesign is difficult
<hoijui>copying all of CUnit coudl be done with memcpy
<hoijui>if taking care of pointer stuff somehow
<Tobi>one is having Lua specify beforehand what data it needs -> big con: needs Lua changes...
<Tobi>but imo it would be way better already than each widget having to implement the transfer themselves
<Tobi>the other is learning what data is needed and accessing it the slow way the first time it's accessed
<Tobi>e.g. GetUnitHealth is called in draw -> all next sim frames health will be put in buffer, that first call takes a lock and accesses sim directly (or alternatively: rendering blocks until the data is available :))
<zerver>is there a solution other than data duplication
<zerver>could be keep the sim object alive until draw no longer needs it?
<zerver>*we
<hoijui>.. we had that before already
<hoijui>forgot?
<Tobi>data duplication would still be needed to prevent inconsistent read
<zerver>we didnt conclude definitely...
<hoijui>yeah we did
<zerver>if we didnt reuse IDs for objects, it coudl work
<hoijui>no
<hoijui>casue sim might be in frame X+1 and draw in frame X
<hoijui>and hte object is/was in different positions in these two frames
<Kloot>how could the renderer decide that it no longer needs a simobject?
<Kloot>except if sim sets an isDead state variable or sth
<zerver>if it removes it from all rendering structures itself, after receiving a RenderXXXDeleted event
<zerver>we could have like this: never reuse any IDs
<zerver>put all object pointers in buffers that never need reallocation
<hoijui>are yo ustill trying to not have multiple sync states?
<hoijui>memory leack concept? :D
<zerver>:D
<zerver>so, 1000 units per buffer etc
<zerver>when buffer is full, make a new one
<zerver>unit ID etc grows forever
<hoijui>what do you want to solve wiht that?
<zerver>this way renderer can access old deleted units also
<zerver>MT performance
<Kloot>that's not possible since each cunit needs to be stored somewhere and accessed in O(1) time by id
<zerver>unit 50000 --> buffer 50, unit 0
<hoijui>look zerver, the accessing unit from render thread after dead is not the reason why we need multiple states
<zerver>i know, you want to separate for other reasons
<hoijui>ok
<hoijui>best thing would probably be, to check how much memry the sync state of a big game uses
<Tobi>some way I think the copying will be way too expensive too
<hoijui>but if it can be done wiht memcpy
<hoijui>there are not a lot of pointers
<hoijui>still?
<zerver>MT performance and sim/render separation are different things, still linked together in a way
<hoijui>i mean... it is more expensive memory wise, but everythign else will be more expensive CPU wise
<Kloot>zerver: so you want to keep 50 buffers of 1000 units around?
<Tobi>slightly mismatched positions doesn't really matter I think (just minor visual artifacts), most importantly you don't want to get inconsistent reads that really brick things
<zerver>no, create buffers on demand
<hoijui>mm
<zerver>garbage collect old buffers
<hoijui>so how big is the synced state in total?
<hoijui>for a big game
<Tobi>random idea: would it work if we make something like a global volatile int currentSimUnitID and make renderer idle for a bit when it hits that unit in rendering
<hoijui>map with lots of features
<hoijui>.. and haivng only one synced state?
<Tobi>or more on a higher level: data dup isn't needed if we can somehow guarantee that rendering never access an object X while sim is messing with it
<hoijui>there could be multiple such untis
<hoijui>units
<Tobi>yes
<hoijui>maybe units will be processed in paralell, or at least by multiple threads
<Tobi>is that statement correct or .. ?
<hoijui>no...
<hoijui>it means we are only accurately rendering in a 2 frames range
<zerver>volatile will not work, needs mutex
<hoijui>would give ugly stuff with fast moving projectiles eg
<zerver>problem is also that the sim updating of one unit may mess with another units data
<hoijui>and there might be values which are less forgiving then position
<Tobi>is mutex the only solution? aren't there solutions with semaphores or so? or would they by definition be as expensive as a mutex?
<hoijui>but if the synced state is.. say 100MB or 200MB
<hoijui>tripplebuffering woudl still be ok, no?
<hoijui>as much as i know, these are all the same
<Tobi>requires 6-12 GB/s memory bandwidth
<hoijui>ahhh
<zerver>it would need currentSimUnitID and currentDrawUnitID
<Tobi>assuming read and write can not overlap
<zerver>mutex takes up to 1000 cpu cycles
<Tobi>and semaphore?
<zerver>semaphore is more expensive IIRC
<Tobi>and what about lockless threadsafe data structures?
<zerver>they need some locked object, but not mutex
<zerver>in my gmlVector, i use an atomic count, because that is faster than mutex
<Tobi>seems in academics that kind of thing isn't considered a lock, just a synchronization primitive
<zerver>yeah, it has major disadvantages if you try to use it as a mutex
<Tobi>since I just found a paper about a lock-free linked list, that uses only an atomic compare&swap instruction as synchronization primitive
<zerver>that's why it is faster...
<zerver>that list probably suffers from the same drawbacks as my vector
<zerver>this is OT :)
<Tobi>not really, I'm just thinking out of the box for a bit / zooming out of the way we were thinking all the time
<Tobi>to see if maybe there is a completely different way that we missed till now
<zerver>if we could avoid the duplication, it would surely help
<hoijui>possible problems without duplication:
<Tobi>though this _is_ slightly OT, what are those drawbacks?
<hoijui>not accurate to the frame reads
<hoijui>inconsistent read or management costs for nto accessing one object with two threads at the same time
<hoijui>right?
<zerver>yeah, MT reads lot of partially updated data
<hoijui>the first one is negliable you think?
<zerver>if you watch the rendering closely, there is graphics corruption here and there, lines drawn across the screen...
<hoijui>mm :/
<hoijui>wel i seldomly used MT so far
<hoijui>sounds like it could cause GFX driver crashes too
<hoijui>more easily, no?
<hoijui>giving inconsistent values
<zerver>yeah, if the driver cannot handle NaNs and such
<Tobi>so that is why for some arbitrarily fine/coarse grained object we need to be able to guarantee that sim doesn't mess with it while rendering wants to use it
<Tobi>worst case could be taking a lock on complete sim (silly ofc), better already would be if we could guarantee this per sim object
<hoijui>or some widget or gadget wants to use it
<hoijui>not gadget
<zerver>widgets again
<zerver>thats unsolvable as i see it
<zerver>if Lua rendering wants to draw object X, how can we know about it in the first place?
<hoijui>so there are multiple unsinged parties interested in sycn state (renderer, widgets, AIs) and possibly multiple sim parts updated at the same time (with MT sim)
<hoijui>unsinged=unsynced :D
<zerver>so Lua is maybe the main reason data duplication is the only way
<Tobi>you don't know about it in the first place, but possibly you can learn and assume it will be needed in the next frame too
<Tobi>and just do it the slow way for a few frames in the mean time
<zerver>sounds a bit shaky i must say :P
<hoijui>and keep statistics of usage of each member of each sim object?
<Tobi>hasn't this been solved many times already or are we really the only engine facing this problem?
<hoijui>is that feasible?
<hoijui>hehe :D yeha Tobi..
<hoijui>good question
<hoijui>i once made a short search
<hoijui>did not find much but
<zerver>a regular game probably would not use data duplication
<zerver>but this is an engine, with lua being the chief complicating matter
<Kloot>side point: aren't all writes atomic for 32-bit datatypes?
<Tobi>Lua is being used in other engines too, e.g. supreme commander
<zerver>yes
<zerver>32 bit aligned writes are atomic
<Kloot>if so, how could one thread read a NaN while another modifies something like unit.pos.x?
<zerver>IIRC
<zerver>it cant
<hoijui>but you can read two values, and divide them
<zerver>but it could read bad floats and make a singular matrix or div by zero or something and...
<hoijui>to get NaN
<hoijui>which may only happen if they are from different states
<hoijui>mm
<zerver>anyway, need to eat
<zerver>we should probably no begin this big refactor yet
<zerver>too many loose ends
<Kloot>div0's should always be guarded against, matrices cannot be singular except in code that inverts them
<Tobi>"If you think you can be clever and avoid locks, don't. You aren't. That's the general "you" which includes me and everybody else." (random quote from stackoverflow.com ;-))
<hoijui>:D
<Tobi>SC uses render split design too
<Tobi>"Rendering and game simulation are synchronized via a minimal-locking queue mechanism; these locks are minor and introduce almost no performance hit."
<hoijui>hmm ok
<hoijui>and lua?
<hoijui>:D
<Tobi>nothing about that
<hoijui>mmm :/
<hoijui>maybe spliff can tell us somethign about lua
<Kloot>probably in SC only game logic can be manipulated through lua
<hoijui>he used to mod SC before commign here
<Tobi>hmm that maybe true yeah
<Tobi>this is where I found that btw: http://www.gamedev.net/columns/events/g ... sp?id=1345
<Kloot>at least I highly doubt it exposes direct3d access to modders
<hoijui>i remember reading that page
<hoijui>ouh await...
<Tobi>hard to find more info
<hoijui>when we want to be able to make sim itsself MT
<hoijui>as in.. multiple Sim threads
<hoijui>we need duplication anyway, right?
<hoijui>as we need a fixed old state to base calculations on
<Tobi>yeah that is true I think
<hoijui>as the order in which the new state is calculated woudl not be determinisitc
<Kloot>question is if we _should_ ever want that :)
<hoijui>yeah
<hoijui>what is a common memory bandwidth these days?
<Tobi>question is then whether complete copy of the sim state costs less then what multithreading gives
<Kloot>personally I've debugged enough sync errors in ST code to know I don't want to ever have to deal with MT too
<Tobi>yeah I have to agree with that
<hoijui>:D :P
<Tobi>its not that I have had much time now either way, but I think I definitely won't ever look into MT-sync bugs
<hoijui>it shoudl not give more or more complex sync erors..
<hoijui>shoudl even simplify some stuff, as we have a clear old state
<Tobi>I think it will only be simplification if the design is improved; just adding old state won't simplify much
<hoijui>and if we coudl disable data duplication for old machines (single core) casue tey likely have slow memory also..
<hoijui>mm... but i can't see hwo it would make it more complex either
<hoijui>hey jk!
<Tobi>DDR2 has theoretical memory bandwidth of 12.8 GB/s according to wikipedia
<Tobi>*dual channel DDR2
<hoijui>mmm
<Tobi>I would say, if the sim state we want to copy becomes bigger than, say, 25 MB, we're doing it wrong :-)
<hoijui>that shoudl work then...so it is basically moving the performance bottleeck from the CPU to the memory bandwidth, when using multiple states
<hoijui>mm ok
<Tobi>welcome jk
<hoijui>for MT sim, coudl we still not copy everything?
<hoijui>i mean... somewhen, we sure want to have sim MT capable
<hoijui>with eg 32 3GHz cores in 3 years or so
<hoijui>maybe "tag" each member as one of: never copy, copy for unsynced, copy for MT Sim
<Tobi>personally I would rather have better designed sim that's more easily modded first :)
<hoijui>mm ok
<hoijui>sounds good
<hoijui>thats,, moving stuff to superclasses, adding new superclasses if needed and such?
<hoijui>moving rendering code out...
<Tobi>but I don't know if I will have time for any significant contributions anytime soon...
<hoijui>ok

main points:
* todays computers are too slow for some of our ideas :-)


Anything else? (WVTTK)
<hoijui>maybe we shoudl try now to solve the addr2line problem?
<hoijui>maybe try to make a python script wiht only the bare translation line, callign addr2line and a print() of the result
<hoijui>i coudl do that too i guess
<hoijui>are there other ways then using popen?
<Tobi>subprocess module
<Tobi>but if that was an issue you would probably have gotten no output at all
<hoijui>mmm
<Tobi>I'll take a look, indeed something must be wrong
<hoijui>:-)
<Tobi>[ARP]hoijui_g5: did you mean to change stacktrace translator in 7f082dbc36507a313d987f5e2ec0e9f3bf94d8a2 ?
<Tobi>"fix some CppCheck warnings, doxygen comments and some formatting"
<hoijui>ouh sh.. :D sorry
<hoijui>no of course not
<hoijui>should i revert it?
<hoijui>or you
<Tobi>you can do it
<hoijui>quite a stupid way to keep track of temporary stuff :D
<hoijui>ok
<Tobi>:)
<Tobi>I see why it is wrong, it takes the debug symbols for the wrong AI indeed
<Tobi>kinda sucks they are all called SkirmishAI.dll :-)
<hoijui>ahhh
<hoijui>:D
<hoijui>bibim said hte same :D
<hoijui>can this be fixed?
<hoijui>though... i reemmber it also failing for spring.exe since this change (-j .text)
<hoijui>maybe that was only due to the old addr2line?
<hoijui>though you said it worked with all of them, manually
<hoijui>will see
<Tobi>yeah but that manual check was only with the RAI SkirmishAI.dll
<Tobi>not with spring.exe
<Tobi>but I'm gonna eat too now :)
<hoijui>ok.. bon appetit!
0 x

zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-10-10

Post by zerver » 11 Oct 2010, 00:22

<hoijui>when we want to be able to make sim itsself MT
<hoijui>as in.. multiple Sim threads
<hoijui>we need duplication anyway, right?
<hoijui>as we need a fixed old state to base calculations on
First natural step to thread the Sim would be to disallow any object to directly manipulate another object. Instead it should post the requested changes as events into a set that is sorted so the events are later guaranteed to be executed in the same order regardless of in which order they were inserted. In other words, something like the current "waitingDamages" but sorted somehow.

If object is allowed to manipulate itself directly, (it probably has to) duplication will be needed.
Last edited by zerver on 11 Oct 2010, 00:28, edited 3 times in total.
0 x

SirMaverick
Posts: 834
Joined: 19 May 2009, 21:10

Re: Dev meeting minutes 2010-10-10

Post by SirMaverick » 11 Oct 2010, 00:23

On multithreading sim:
Get rid of mutex/locks (they don't scale with threads), use atomic updates.
2 or more sync states are needed, so that they can unsync can operate independently. No need to for locks, e.g. like it's done now.
<hoijui>as we need a fixed old state to base calculations on
Yes. Currently sim is updating instantly. That makes it hard/impossible to paralyze. Less dependencies -> more parallelism. Calculate based on old state, buffer changes and update everything in one step (after all calculations are done). Like networking is done, never send whole state, just updates.

This way it should be less costly to have several sim states. E.g. calculate the changes once and apply them to all states. So you don't have to copy whole sim state every time (e.g. my wind farm doesn't change positions quite often).

unsync part uses own sync state. After drawing a frame it applys all buffered changes of all completely calculated game frames (should be max 1 if game frame rate < draw frame rate) and continues drawing next frame.
0 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6109
Joined: 29 Apr 2005, 01:14

Re: Dev meeting minutes 2010-10-10

Post by FLOZi » 11 Oct 2010, 01:30

Minor request:

Can the fix for Mantis #2126 be pushed to 82 branch?

http://springrts.com/mantis/view.php?id=2126

http://github.com/spring/spring/commit/ ... 57e8612d76
0 x

User avatar
Johannes
Posts: 1265
Joined: 17 Sep 2010, 15:49

Re: Dev meeting minutes 2010-10-10

Post by Johannes » 11 Oct 2010, 01:38

Will pathing be decent again after next patch?
0 x

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14606
Joined: 17 Nov 2005, 02:43

Re: Dev meeting minutes 2010-10-10

Post by Forboding Angel » 11 Oct 2010, 03:05

About JK's loss, I gather that someone close to him died. Assuming I have the gist of it correctly, my condolences. :(
0 x

User avatar
manolo_
Posts: 1370
Joined: 01 Jul 2008, 00:08

Re: Dev meeting minutes 2010-10-10

Post by manolo_ » 11 Oct 2010, 11:24

these colors make my eyes bleeding
0 x

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Dev meeting minutes 2010-10-10

Post by hoijui » 11 Oct 2010, 22:18

zerver, if you have a lot of events that have to be processed in order... where would you see space for MT-ability?

edit: colors adjusted in the script, will be less extreme in next minutes.
0 x

zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-10-10

Post by zerver » 12 Oct 2010, 00:22

The actual execution of the events must be single thread. Thing is, there will be relatively few of these events...

So unit1 fires his laser on unit2. Instead of directly reducing health of unit 2, put in queue. But then there is unit3... unit9999 that were only chargin their lazor, but didnt fire their lazor. So MT performance went thru the roof.
0 x

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Dev meeting minutes 2010-10-10

Post by hoijui » 12 Oct 2010, 11:32

... hae? :D

in your scenario, what parts of sim are done in parallel?
to me it sounds like doing everything in one thread, as is now, but add some extra management work before that, which can be done in parallel, but is practically useless.
0 x

zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-10-10

Post by zerver » 12 Oct 2010, 11:46

UnitHandler::Update would be processing the units in parallel for instance. This ordered event queue is necessary mainly because A+B != B+A
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-10-10

Post by AF » 12 Oct 2010, 13:36

We already have a long standing bug in that function regarding nondeterministic economics that can result in being given small amounts of free resources (e.g. HLT uses up all your energy as unit ID 1, then unit ID 2 has a 5k static energy consumption, resulting in 5k of free energy)

Parallelising all of these could lead to allsorts of problems with free resources here, accidental resources lost, all based on the order of what was running when, how long it took, and in what order. Aside from desync, we could see a lot of nondeterministic logic bugs creep in that still 'syncs';
0 x

User avatar
Niobium
Posts: 456
Joined: 07 Dec 2008, 02:35

Re: Dev meeting minutes 2010-10-10

Post by Niobium » 12 Oct 2010, 13:48

Would it not be possible to 'collect' the events in parallel, then process them in a single thread, possibly after sorting? i.e. checking projectiles for collisions: can collect all the colliding projectiles in parallel, then process the collisions in series, possibly after having sorted by projectile ID or some such. This would save a lot of time due to expensive collision checking being done in parallel.

I think this is what zerver was saying with his laser example, where there are very few units actually requiring proper processing due to firing (the part to be done synced in series), while for all the units that aren't actually doing anything we get a big speedup from the parallel side.
0 x

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Dev meeting minutes 2010-10-10

Post by hoijui » 12 Oct 2010, 14:22

so the speedup would be for units that do nothing, say code that does nothing or simpler said... nothing?
which is just a different way of describing what i said in my last post.

with this method, you can not do anything in parallel that relies on any data of other units/sim-objects. and even if you could do some parts in parallel, this method would loose badly vs the data-duplication method, as its only pitfall is higher memory bandwidth (and that is not guaranteed), while it has these definitive pros: simper design (code wise, to understand, to bug-fix), much more parallelism (basically all vs nothing), less overall CPU usage.
0 x

zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-10-10

Post by zerver » 12 Oct 2010, 22:57

hoijui wrote:so the speedup would be for units that do nothing, say code that does nothing or simpler said... nothing?
Absolutely not. The execution of these events would be super fast, since they just change some unit properties here and there.

Data duplication does not work by itself. You also need the sorted events. If two units fire on the same enemy unit, you would get different (floating point) results depending on in which order you reduce that unit's health. Data duplication does nothing to address this ordering problem.

Like AF said, this is an extremely difficult engine change. It will also make the game slightly slower for those who have a single core processor, because it is impossible to make it backwards compatible sync wise.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-10-10

Post by AF » 12 Oct 2010, 23:01

Of note is that some of those bugs are existent in singlethreaded simulation too, its just that it does not desync. Possible solutions have been put forward in other threads. So a lot of them can be fixed before going multithreaded, with very real improvements in single threaded gameplay, albeit ones that dont make for an interesting changelog.
0 x

User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Dev meeting minutes 2010-10-10

Post by Pxtl » 12 Oct 2010, 23:22

Not a stakeholder, but curious to understand what's going on here - so the proposed logic is that if a unit-script writes to a shared resource, then said script gets halted and dumped into a collection of frozen scripts... then once all the unit scripts have been processed, we go to the collection of frozen scripts and then burn through them in a deterministic manner.

Is that the idea?
0 x

zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-10-10

Post by zerver » 12 Oct 2010, 23:29

No, when the unit script tries to modify a shared resource, no actual modification occurs. Instead an event is created to perform the actual changes later.
0 x

User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Dev meeting minutes 2010-10-10

Post by Pxtl » 12 Oct 2010, 23:47

zerver wrote:No, when the unit script tries to modify a shared resource, no actual modification occurs. Instead an event is created to perform the actual changes later.
Ah. That seems more sensible... but doesn't it also mean that any existing code that depends on the results of an action being visible is invalidated?

That is, if a unit depletes N energy, they won't actually register the N is depleted until the next cycle, instead of the next line?
0 x

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Dev meeting minutes 2010-10-10

Post by hoijui » 13 Oct 2010, 00:39

i see :/
yeah right... so instead of two states, old and new, you only have the old state, plus a set of diffs (=> events). when all the diffs are ready (calculating them can be done in parallel), all the diffs are applied to form the new state. this may be done partly in parallel, though it should take relatively few cycles, so management work may not be worth it, and it will likely be done non-parallel. when done, the new state is marked as old state again, and new diffs are calculated...

hmm pxtl has a point there :/
though there could be an alternative GetX_new() way of fetching values, which applies the diffs on the fly (just for returning, not in the object).

otherwise it looks nice, as we would never have an intermediate state. if the diff applying could be done really fast, we could block read access of the state during this time, or allow checking for the state diffs being applied, being notified if that process is done, or block that process until x is done.
0 x

Post Reply

Return to “Meeting Minutes”