Time |
Nick |
Message |
00:27 |
|
us`0gb joined #minetest-dev |
00:28 |
|
sapier1 joined #minetest-dev |
00:50 |
|
domtron joined #minetest-dev |
00:52 |
|
sapier1 left #minetest-dev |
00:57 |
|
smoke_fumus joined #minetest-dev |
01:39 |
|
domtron joined #minetest-dev |
03:27 |
|
Weedy joined #minetest-dev |
03:27 |
|
Weedy joined #minetest-dev |
05:24 |
|
werwerwer_ joined #minetest-dev |
05:35 |
|
kaeza joined #minetest-dev |
06:43 |
|
darkrose joined #minetest-dev |
07:09 |
|
PenguinDad joined #minetest-dev |
07:57 |
|
sapier joined #minetest-dev |
07:58 |
sapier |
I'm trying to find the reason(s) for lag, if someone could have a look at the profiling results I'd be very glad https://gist.github.com/sapier/9850401 |
08:01 |
VanessaE |
~lag |
08:01 |
VanessaE |
aw man, it doesn't answer here :) |
08:02 |
VanessaE |
(on inchra, shadowbot would give her spiel about how lag is not slow fps, etc) |
08:03 |
VanessaE |
hm.. view raw --> "Error: blob is too big" |
08:03 |
sapier |
I don't see a single point to fix it in there ;-/ |
08:03 |
sapier |
download and view offline to see all |
08:04 |
VanessaE |
meh, just wanted to see it without github cropping it to width |
08:04 |
sapier |
it's 15M text ;-) |
08:06 |
VanessaE |
you trying to investigate the mesh gen lag or something? |
08:06 |
sapier |
no idea if it's mesh gen or something else |
08:07 |
VanessaE |
well render lag as new blocks are loaded anyway |
08:07 |
VanessaE |
if it helps, it gets worse as the texture resolution increases. that's the only pattern I've ever seen with it |
08:08 |
sapier |
meshgen seems to be involved but I'm not sure my interpretation is correct ... top operations are basic ones we can't really do much about |
08:09 |
VanessaE |
you're doing this with default textures right? |
08:10 |
VanessaE |
try it with some huge texture pack, doesn't matter which one. it might help you spot the bottleneck then. |
08:10 |
sapier |
I don't wanna find a huge texture bottleneck (which could be completely different) I want the bottleneck in basic operation |
08:10 |
VanessaE |
I know, but if you find one, you might find a path to the other |
08:11 |
VanessaE |
but ok |
08:11 |
sapier |
I don't think so ... it's as much lag it should be visible there too ... but I seem to be blind |
08:11 |
VanessaE |
wait a minute...OGLES1Driver? so this is still for the android client? |
08:12 |
sapier |
yes |
08:12 |
VanessaE |
that changes things a bit |
08:12 |
VanessaE |
I thought you'd switched gears back to PC or something |
08:12 |
sapier |
of course pc client will benefit too but it's not the main target |
08:12 |
VanessaE |
right |
08:14 |
VanessaE |
as a rough guess, I'd think that irrlicht vector3d call (third entry in your list) |
08:14 |
VanessaE |
just based on the number of calls made and the cumulative time it took |
08:15 |
sapier |
yes all those vector3d calls are done quite often I don't think we can make them much more fast so at best we can reduce them |
08:15 |
sapier |
but where is it done? |
08:15 |
VanessaE |
damned if I know |
08:16 |
VanessaE |
I wonder.. |
08:16 |
|
kahrl joined #minetest-dev |
08:16 |
VanessaE |
wasn't RBA working on optimizing some mesh gen stuff? |
08:17 |
sapier |
at line 12.5k cummulative calculation starts ... mesh functions are quit often in there but not sure if it's related |
08:17 |
VanessaE |
he'd said something about a bunch of mesh-related stuff being done in realtime that should have been done at start, and was doing a rewrite of part of the core accordingly. Might have just been shaders-related, but I think he had said something about mesh generation too |
08:19 |
VanessaE |
[03-20 21:40] <RealBadAngel> and what im doing is moving generation of shaders, assigning normal maps from runtime (mesh updates) to startup only |
08:19 |
|
PenguinDad joined #minetest-dev |
08:19 |
VanessaE |
so not exactly. |
08:20 |
kahrl |
does vector3d use SIMD instructions? |
08:20 |
sapier |
no idea ... are they available on arm? ;-) |
08:20 |
|
grrk-bzzt joined #minetest-dev |
08:20 |
kahrl |
no clue |
08:20 |
|
CheapSeth joined #minetest-dev |
08:21 |
sapier |
I'm not sure if my interpretation is correct but as of line 12.5k mesh generation seems to be one of the main cpu hogs |
08:23 |
kahrl |
I think SIMD is called NEON on ARM |
08:23 |
sapier |
even if it isn't I can't optimize very much there |
08:25 |
|
ImQ009 joined #minetest-dev |
08:25 |
kahrl |
http://www.kandroid.org/ndk/docs/CPU-ARM-NEON.html |
08:26 |
sapier |
ok so we could use it ... now how to use it? |
08:27 |
sapier |
adding that if around will cause even more cpu instructions then doing a 3 parameter addition manually ;-) |
08:28 |
kahrl |
well I'd first check if it is already used |
08:28 |
sapier |
no it isn't |
08:28 |
kahrl |
how do you know? |
08:29 |
sapier |
because I created the android makefile and know that lib isn't linked |
08:30 |
kahrl |
hmm ok |
08:30 |
kahrl |
I thought gcc might optimize stuff like this by itself |
08:30 |
sapier |
and to be sure I just checked again irrlicht doesn't link it either |
08:31 |
sapier |
well that's perfectly possible too but why would there be a lib if gcc already did this? |
08:32 |
kahrl |
wait what lib needs to be linked? aren't those routines compiler intrinsics? |
08:32 |
sapier |
hmmm |
08:33 |
sapier |
ok I'm doing an additional grep for NEON on full code to be absolutely sure |
08:33 |
kahrl |
I'd disassemble vector3d::operator+ instead |
08:34 |
sapier |
openal and libpng may use neon nothing else |
08:34 |
kahrl |
(or if that isn't possible because of inline, a simple program that adds two vectors instead) |
08:35 |
sapier |
as I can attach a debugger it's possible even with inlining as long as I find a location in source ;-) |
08:38 |
sapier |
great the only location where minetest uses it is anaglyph ... ok I'm just gonna add a dummy |
08:43 |
sapier |
well ... no need to do it "return vector3d<T>(X + other.X, Y + other.Y, Z + other.Z);" this is how addition is done in irrlicht |
08:45 |
sapier |
and I don't thing thre parameters are enough to gain benefit from SIMD operations |
08:46 |
sapier |
at least if they're member variables |
09:02 |
|
PenguinDad joined #minetest-dev |
10:00 |
|
PenguinDad joined #minetest-dev |
10:42 |
|
Jordach joined #minetest-dev |
10:42 |
|
Jordach joined #minetest-dev |
11:13 |
|
rsiska joined #minetest-dev |
11:18 |
|
kaeza joined #minetest-dev |
11:58 |
|
sapier1 joined #minetest-dev |
12:01 |
|
grrk-bzzt joined #minetest-dev |
12:03 |
sapier1 |
https://gist.github.com/sapier/9853279 is it possible a single mesh uptate does require more then 835k node accesses per block? |
12:03 |
sapier1 |
hope I did some calculation misstake in there |
12:04 |
proller |
its one of worst places |
12:05 |
sapier1 |
most of it is ligth calculation ... a thing any modern gpu is capable of doing in almost no time :-( |
12:08 |
sapier1 |
well the quick n dirty solution is disabling smooth lighting for android devices ... this will save a lot of iterations |
12:09 |
|
PilzAdam joined #minetest-dev |
12:09 |
|
grrk-bzzt joined #minetest-dev |
12:11 |
proller |
also for making 1 mesh - copied 27 around blocks via vm |
12:13 |
sapier1 |
people are discussing about forspecs qt and lots of other (optional) things and then you find huge blockers in code like this one ... this is quite frustrating |
12:30 |
proller |
and you can find lot of wtf code like this |
12:40 |
|
spillz joined #minetest-dev |
12:40 |
spillz |
sapier: http://m.imgur.com/zm3fJFX |
12:42 |
|
spillz joined #minetest-dev |
12:45 |
|
spillz joined #minetest-dev |
12:58 |
sapier1 |
spillz guess I should fix the inverted items next |
12:58 |
|
spillz joined #minetest-dev |
12:59 |
|
NakedFury joined #minetest-dev |
13:32 |
|
nore joined #minetest-dev |
14:04 |
|
_BrandonReese joined #minetest-dev |
14:13 |
|
Megaf joined #minetest-dev |
14:31 |
|
rsiska joined #minetest-dev |
14:44 |
|
EvergreenTree joined #minetest-dev |
14:52 |
|
tomreyn joined #minetest-dev |
15:08 |
|
_BrandonReese joined #minetest-dev |
15:14 |
grrk-bzzt |
Hello |
15:15 |
grrk-bzzt |
I've made a minetest server on an old PC |
15:15 |
grrk-bzzt |
On what depends the speed of the generation of the map? CPU or disk I/O? |
15:25 |
Megaf |
Hm, it still has this bug "01:20:34: ACTION[main]: Server for gameid="minetest" listening on 67.215.65.132:30000." |
15:25 |
Megaf |
if you dont use anything as bind adress |
15:26 |
Megaf |
I'd like to know where it gets that IP from |
15:26 |
Megaf |
sapier: |
15:27 |
sapier1 |
megaf can you try the pull fixing it |
15:28 |
PenguinDad |
why do chat messages double send when I press on proceed? |
15:30 |
PilzAdam |
PenguinDad, do you use latest master? |
15:30 |
PenguinDad |
yes |
15:31 |
PilzAdam |
this was supposed to fix it: https://github.com/minetest/minetest/commit/5bd9c236d563f3c5a6e268abb13f291a915cde1c |
15:32 |
sapier1 |
at least it did fix it for me ... do you have anything special? |
15:38 |
Megaf |
It would be really cool if I could select what the mese sand/sand pneumatic tube would vacumm |
15:39 |
PenguinDad |
it seems like my local git clone was broken but now it works |
16:08 |
|
Zeitgeist_ joined #minetest-dev |
16:12 |
|
crazyR joined #minetest-dev |
16:16 |
|
en_uk joined #minetest-dev |
16:18 |
|
OldCoder joined #minetest-dev |
16:22 |
|
sapier1 left #minetest-dev |
16:26 |
|
iqualfragile joined #minetest-dev |
16:29 |
|
Selat joined #minetest-dev |
16:33 |
|
PenguinDad joined #minetest-dev |
16:36 |
|
hmmmm joined #minetest-dev |
16:45 |
|
EvergreenTree joined #minetest-dev |
16:58 |
|
rubenwardy joined #minetest-dev |
17:01 |
|
en_uk left #minetest-dev |
17:03 |
|
AndChat-93396 joined #minetest-dev |
17:03 |
|
Calinou joined #minetest-dev |
17:06 |
|
_BrandonReese joined #minetest-dev |
17:14 |
|
AndChat-93396 joined #minetest-dev |
17:21 |
|
e1z0 joined #minetest-dev |
17:28 |
|
e1z0 joined #minetest-dev |
17:32 |
|
e1z0 joined #minetest-dev |
18:02 |
|
Zeitgeist_ joined #minetest-dev |
18:25 |
|
EvergreenTree joined #minetest-dev |
18:27 |
|
cheapie joined #minetest-dev |
19:26 |
|
e1z0 joined #minetest-dev |
19:56 |
|
tomasbrod joined #minetest-dev |
20:01 |
tomasbrod |
The android program can not be started on Samsung Ace. android.view.InflateException: ... android.widget.Space |
20:05 |
|
tomasbrod left #minetest-dev |
20:24 |
|
domtron joined #minetest-dev |
20:42 |
|
john_minetest joined #minetest-dev |
20:44 |
iqualfragile |
john_minetest: yes, the one that fixes transparency |
20:44 |
iqualfragile |
but its not yet written |
21:02 |
|
Selat left #minetest-dev |
21:24 |
|
domtron joined #minetest-dev |
21:26 |
|
tomasbrod joined #minetest-dev |
21:26 |
|
tomasbrod left #minetest-dev |
21:54 |
|
domtron joined #minetest-dev |
22:03 |
|
spillz joined #minetest-dev |
22:04 |
spillz |
ubuntu packaging again... |
22:05 |
spillz |
So for the minetest PPA I can the packaging repo https://code.launchpad.net/~minetestdevs/minetest-c55/packaging |
22:06 |
spillz |
to enable LevelDB, luajit, freetype, whatever else... |
22:07 |
spillz |
but that won't work for older versions of ubuntu, so I can make a packaging-legacy that switches some of the options off for those older versions. then there will be a recipe for newer ubuntu's and a recipe for older ubuntu's but both will drop files in the same PPA (I think that should work without issues) |
22:08 |
spillz |
Sound good? |
22:08 |
spillz |
6:05:39 line should have been "I can *update* the packaging repo" |
22:10 |
spillz |
Also, version number used in the recipe can't be {time}blahblah otherwise apt-get won't install it over the official minetest in Ubuntu repo. it has to be something like 0.4.9dailies-{time}blahblah |
22:10 |
spillz |
See the version line here: https://code.launchpad.net/~damien-moore/+recipe/minetest-daily |
22:12 |
* spillz |
hopes relevant people read logs |
22:13 |
|
spillz left #minetest-dev |
22:14 |
|
GhostDoge joined #minetest-dev |
22:32 |
|
hmmmmm joined #minetest-dev |
22:59 |
|
OldCoder joined #minetest-dev |
23:42 |
|
john_minetest left #minetest-dev |