Dev meeting minutes 2011-05-09

Dev meeting minutes 2011-05-09

Minutes of the meetings between Spring developers are archived here.
Post Reply
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Dev meeting minutes 2011-05-09

Post by jK »

Date: 2011-05-09
Present: abma, hoijui, jK, Kloot, Tobi



_Agenda_____________________________________________________________________
  • MemPool
  • Release plan
  • how close to merge is Kloot's path finding branch?


_Main Conclusions___________________________________________________________
  • readd MemPool
  • disable EFX/EAX/Reverb when Pulse is used




_The meeting________________________________________________________________
>> hoijui joined!
>> Tobi joined!
>> jK joined!
>> Kloot joined!
jK: @hoij it seems you missunderstood me about mempool (not that the removal wrong, but mempool was functional as wanted)
jK: mempool didn't missed the gc, it was the gc! -> 99% of gcs just alloc a huge single block of memory and then reassign memory in that block for single objects
jK: so the job of the gc is not the free unused memory
jK: the job is to give a continuous block of memory
jK: this way the program saves much time it would else spend with alloc/dealloc small blocks
jK: e.g. alloc'ing and free'ing 1 million classes can stress the OS/mem/CPU very much
jK: the problem with mempool is that it wasn't KISS like
jK: e.g. you can use std::vectors to create such continuous memory blocks with much less trouble
jK: sure you wouldn't share it with other parts of the engine code, but that's not such a problem (our vertexarray implementation doesn't do so either)
>> abma joined!
jK: "share it" = share unused mem
abma: hey!
abma: irc-bridge doesn't work?
jK: hi
jK: others ones are still on their way through subdimensions ;)
abma: ah, ok :D
abma: did meeting already start?
jK: nope
Tobi: be sure to run a benchmark of CMemPool when trying to use it
Tobi: quick test I do now shows malloc is slightly faster
Tobi: on 100* (10000 * alloc + 10000 * free) for sizes of 10 to 100 bytes
abma: on win32, too?
Tobi: 53 ms vs 68 ms on 10 bytes up to 159 ms vs 176 ms with 100 bytes
Tobi: no clue
abma: without having an real idea whats happening, was just a hint
Tobi: ugh there is actually a bug in the mempool in HEAD^^
Tobi: with that fixed it is faster :)
Tobi: (UseExternalMemory actually returns DontUseExternalMemory ...)
Tobi: new result is MemPool wins with 17 ms vs 54 ms for 10 bytes up to 23 ms vs 155 ms for 100 bytes, so that looks more worthwhile
jK: does the LOS Handler alloc such many objects?
Tobi: nah, don't think so
jK: too bad imbazcek never fixed the malloc alternative, it may give more than micro optimization
Tobi: I think LOS handler allocs once per LOS map update for a unit
Tobi: (not counting STL allocations)
jK: that's where KISS comes into play ;)
jK: LOS Handler itself is `unclean` (=hard to maintain) code, and it is more worth to rewrite parts of it than doing micro optimization in its malloc ;)
hoijui: ahh k...
hoijui: so you will revert the remove of mempool, Tobi?
hoijui: start meeting? :D
hoijui: !ring
hoijui: ping Tobi, Kloot jK abma
abma: +1 for start :)
hoijui: why did you not start the meeting?
hoijui: nm
jK: zerver is not here and my question was pointed at him
hoijui: ok.. i though we decided to start meetings if 4 devs are around
hoijui: can skip questions that need a certain dev that is not around
jK: still the remaining ones were added by ya
Release plan
Tobi: LosHandler is actually quite ok imo since I split it in a bunch of classes (relative to many other parts of Spring at least) , just could use explanation of the algos somewhere :-)
hoijui: release plan.. i guess we can have my other question here...
hoijui: should i make a test release
hoijui: the oens i only announce in that forum thread
hoijui: plus some yellign in some channels
hoijui: for me, master is now non crashy in the usual game, instead of crashing every time
hoijui: or do we still have too many too ugly bugs?
abma: only the ba-bug is a bit anoying
hoijui: whats that?
Tobi: [ARP]hoijui_g5: k I will revert it
hoijui: widgets?
abma: yes
hoijui: thanks :-)
jK: hmm true the LosHandler is much cleaner now, still it's missing like 1000 lines of comments ;)
abma: "Red Build/Order Menu" http://springrts.com/mantis/view.php?id=2393
hoijui: mm ok
abma: [LCC]jK: in the mantis report of #2393 you wrote i should compile with DEBUG2 - it's compiled with DEBUG3?! + gdb stacktrace was already attached: http://pastebin.com/GieCGV3M (?)
jK: the stacktrace is incorrect
abma: ok, then i'll retry
abma: so... next?
hoijui: aehhh no
jK: also could you just use `bt` w/o `all`?
hoijui: i mean.. we did not decide whether therer are too many bugs still
jK: there is normally just one thread crashing in spring
abma: [LCC]jK: sure
hoijui: you want this bug fixed first?
abma: hm, you're right, doing a test-release with this bug should be ok
abma: but please make a big fat note about that :)
hoijui: ill make the post in the test thred and then tell some guys in the lobby..
Tobi: did recent STL have a hashmap already?
hoijui: cranphin reports that untis do ignore orders since the removal of AI_SELECT
jK: C++0x has
hoijui: b182bcbd686aef8e5913044abd3539489f1b2d6f is the last oen that works for him.. for me that does not happen though (he is on windows)
hoijui: but i cant see how that woudl happen
abma: [ARP]hoijui_g5: BA doesn't currently work too, because of the two lines of SetUnitLineage().. so maybe the problem is a bit smaller with the crash about many duplicate bug-reports
hoijui: mmm
abma: uh, yes true..
hoijui: yeah after the test release, i'll ask beherit if we can get a new release that works well wiht master
abma: [ARP]hoijui_g5: craphin is right
hoijui: current release is also missing game-ends script stuff
abma: this has to be fixed before release
jK: don't see any problem with AI_SELECT
abma: before test-release
hoijui: you neither cna controll units?
hoijui: aabma, all commands given to untis are ignored?
hoijui: ahh true..
hoijui: i get the same
abma: yes...
abma: only FPS mode works
abma: so we've a ego-shooter now :D
hoijui: i got a SIGSEGV too :D
hoijui: thought you can not shoot at enemies in ego mode :D
hoijui: but AI can still give commands
hoijui: AI now OWNS YOU!
abma: hm, the attack order seems to work
jK: everything works fine here
hoijui: :D
abma: i don't believe that you tested everything ;-)
hoijui: move orders to my com did not work, nad i got a SIGSEGV after trying t give like 10 in a row
hoijui: am recompiling latest, then will try to reproduce and give stacktrace
jK: move commands and everything else work fine, only with targetting there is something wrong
abma: which game do you use to test?
jK: k found the typo for the taregetting one
jK: -e
abma: here it doesn't work for BA and ZK
hoijui: KAIK alsohas a problem here, in master
hoijui: seems ot throw na exception in Update
jK: someone of you have to remove the last AI_SELECT usages in the AI interface
hoijui: ok..
hoijui: you dont compile AI stuff?
jK: no, neither got any idea where those functions get used nor how AI handle the output
abma: [LCC]jK: which game did you test?
jK: e.g. if KAIK is really crashing, it must use the result of newCommand
jK: and to me it seemed the return value shouldn't matter ...
jK: (there is another AI_SELECT usage in the AI interface, I was even less sure if it is safe to remove it w/o stubs)
jK: I always test with zk based tech demos
jK: -zk +ca
hoijui: ok.. ill have a look
hoijui: hmm.. tried wiht Comanders instead of a nAI
hoijui: and move commands still do not work
jK: broken movetypes?
hoijui: build commands do not work either
hoijui: but when you give it an attakc command, it does move until it is close enough
abma: as already said only attack command + fps mode seems to work...
hoijui: reclaim works too
jK: only thing I can say it works fine here :x
jK: (except attacks commands were randomly dropped)
jK: -s
hoijui: now i got a freeze in rts/System/Sound/AudioChannel.cpp
hoijui: got that before already
hoijui: mm k
abma: git describe
abma: 0.82.3-1847-gcf1d73b
jK: you guys have strange setups :x
hoijui: :P
hoijui: you have magic bug fixing setup
jK: lol
hoijui: ahh yeah.. sound is still choppy of course
hoijui: thats also not too nice for a test release
jK: blame pulse
hoijui: well...
hoijui: you want to say, we go that route again?
jK: the fault is 100% not in spring itself (because only <<<<1% of the sounds in spring uses streams at all)
hoijui: dont try to change that and tell everyone to disable pulse?
abma: [ARP]hoijui_g5: about the coppy sound: http://springrts.com/mantis/view.php?id=2368
hoijui: well.. maybe not, but it can be prevented inside spring
hoijui: as it works in rrelease version of spring
abma: disabling efx could help to fix that...
abma: see last note of bug report
hoijui: that is not a fix
hoijui: see secodn last note
abma: excludefx = eaxreverb in /etc/openal/alsoft.conf seems to solve it
jK: pulse instead is receiving spring's buffers and dividing them into stream packages, but with EFX it's too slow to reach them fast enough to ALSA -> lag
hoijui: if we coudl do somethign to make it work wiht pulse
hoijui: we shoud do that
hoijui: cause otherwise we get lots of the same complaints again
hoijui: mmm ok
hoijui: so the solution then is, to disable EFX by default
hoijui: at least on linux
jK: that's not a _solution_
abma: from end-user view its a solution
hoijui: it is a solution for the problem of getting a lto of annoying complains
jK: it's like disabling textures in opengl ...
hoijui: ah...
hoijui: you on ubuntu, abma?
abma: yes
hoijui: latest version?
abma: yep
hoijui: that os X one :D
hoijui: mm k
hoijui: and it sitll has that problem?
abma: yes, choppy sound with pulse
hoijui: or well.. have a better idea, jk?
hoijui: mm :/
abma: and pulse is default for openal...
hoijui: we shoudl make a bug report in the pulse issue tracker, and disable it on linux by default in spring
hoijui: for now
hoijui: k?
jK: detect pulse correctly and give bug fat warning similar to intel one?
hoijui: mmm
jK: *big
hoijui: if we can detect that...
hoijui: if we can detect it. maybe give that fat warnign, plus disable FX (but not in hte config)
hoijui: ?
abma: detection should be possible as its already logged to infolog.txt :)
hoijui: so FX gets auto enabled for them if they unuse pulse
abma: with LogSubsystems=Sound
hoijui: ah nice :-)
hoijui: didnt know
hoijui: so?
hoijui: jk?
hoijui: is that ok path for you?
jK: yup
hoijui: ook :-)
hoijui: Kloot, are oyu here? (as next topic is for you)
Kloot: ya
hoijui: k :-)

how close to merge is Kloot's path finding branch?
Kloot: not close enough
hoijui: ok
Kloot: also after seeing community responses to pathfinding changes I am not going to finish it anytime soon
hoijui: mm.. ok
hoijui: well... pathing is not too good in master as it is now.. i mena.. it has some problems that amke it not good enough for a release
hoijui: and ... we kind of agreed on that you are the only oen wokrign on path finder stuff as long as you have that branch
hoijui: (also in master)
Kloot: what problems?
jK: esp. performance ones
hoijui: i remember something like.. untis running into builindg forever
hoijui: buildings*
hoijui: features*
hoijui: i mean.. htere are untested changes.. na we know how delicate that stuff is so.. its no wonder.. just mean... i am pretty sure that changes have to be done before a release
Kloot: mkay, better document as many cases as you can w/ steps how to reproduce and compile them into a mantis report
hoijui: so if you do not plan to merge your stuff before release, it will result in merge comflicts again... totally your decission .. i mena..
hoijui: ok
hoijui: yeah.. hopefully we can get godde to test some too again
hoijui: he made very good reports
hoijui: next topic is for zerver so..
hoijui: we are kind of at the end now
jK: k will do the minutes
hoijui: thanks :-)
hoijui: so we wait with the test release until sound & command stuff is fixed, and hten try to get BA fit for that test release
hoijui: and likely have lots of test releases again
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Dev meeting minutes 2011-05-09

Post by Beherith »

Standing by for any changes that need to be done to BA to maintain compatibility.
Thanks for your work!
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2011-05-09

Post by zerver »

Sorry for missing the meeting, my plan was to attend.

further explain:
new (realCam) CCamera(*camera); // anti-crash workaround for multithreading ?


Sure, the "camera" object is not allowed to be deleted, nor can the pointer be reassigned because it is accessed by multiple threads. This hack meets these requirements. The alternative would be a mutex, but that is a really bad idea, since camera is accessed in many places.
luckywaldo7
Posts: 1398
Joined: 17 Sep 2008, 04:36

Re: Dev meeting minutes 2011-05-09

Post by luckywaldo7 »

For pathing testing (or any kind of testing), it would really help if there was a test release for both linux and windows users that we could do some multiplayer games with. Even if is buggy, there will surely be some kind of helpful feedback from it.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Dev meeting minutes 2011-05-09

Post by Forboding Angel »

luckywaldo7 wrote:For pathing testing (or any kind of testing), it would really help if there was a test release for both linux and windows users that we could do some multiplayer games with. Even if is buggy, there will surely be some kind of helpful feedback from it.
This + (HUGE PLUS!) unitsync that has "True Portable" mode.
SirMaverick
Posts: 834
Joined: 19 May 2009, 21:10

Re: Dev meeting minutes 2011-05-09

Post by SirMaverick »

https://github.com/spring/spring/commit ... f28665b0b9
"(as discussed in meeting)"
The commit message is imo useless. Not everyone will/does read minutes or know link to it when reading git log.
Better way would have been to give short reason (or nothing at all).
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: Dev meeting minutes 2011-05-09

Post by hoijui »

it is now called isolation mode, not true portable mode anymore.
as was said in the meeting, there are bugs to be fixes first, but then there will be a test release. was that unclear?
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Dev meeting minutes 2011-05-09

Post by jK »

zerver wrote:Sorry for missing the meeting, my plan was to attend.

further explain:
new (realCam) CCamera(*camera); // anti-crash workaround for multithreading ?


Sure, the "camera" object is not allowed to be deleted, nor can the pointer be reassigned because it is accessed by multiple threads. This hack meets these requirements. The alternative would be a mutex, but that is a really bad idea, since camera is accessed in many places.
If so why not just do

Code: Select all

CCamera old = camera;
...
camera = old;
and why not use cam2?

PS: If other threads use the camera object and other change it. Doesn't this cause very strange behaviors (as showing ghost units etc.) which avoided for all costs?
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Dev meeting minutes 2011-05-09

Post by Forboding Angel »

hoijui wrote:as was said in the meeting, there are bugs to be fixes first, but then there will be a test release. was that unclear?
Nope not at all
hoijui wrote:it is now called isolation mode, not true portable mode anymore.
Awesome :-) I shall use "correct" terminology in the future. Thanks for the tip ;p
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2011-05-09

Post by zerver »

jK wrote: If so why not just do

Code: Select all

CCamera old = camera;
...
camera = old;
and why not use cam2?

PS: If other threads use the camera object and other change it. Doesn't this cause very strange behaviors (as showing ghost units etc.) which avoided for all costs?
Yes, it is possible there are some artifacts, but I have not seen any so no motivation to fix it :)

The reason for this rather hackish setup was IIRC to control when the realCam is deleted (or rather when the destructor is called). I guess the same could be achieved with some brackets to control the scope, but I guess I did not want to do it at the time, but just wanted a copy-and-pastable fix for all the occurrences. My suggestion right now is "Don't fix it if it ain't broken".

I didn't study the inner workings of cam2 so I'm not exactly sure what you are allowed to use it for.
Post Reply

Return to “Meeting Minutes”