| Time |
Nick |
Message |
| 00:12 |
|
acerspyro joined #minetest-dev |
| 00:24 |
|
shadowzone_ joined #minetest-dev |
| 00:53 |
|
jin_xi joined #minetest-dev |
| 01:18 |
|
luizrpgluiz joined #minetest-dev |
| 01:51 |
|
luizrpgluiz left #minetest-dev |
| 02:13 |
|
Player_2 joined #minetest-dev |
| 02:17 |
|
luizrpgluiz joined #minetest-dev |
| 02:19 |
luizrpgluiz |
hi |
| 02:27 |
|
Player_2 joined #minetest-dev |
| 02:28 |
|
Wayward_One joined #minetest-dev |
| 02:29 |
|
luizrpgluiz left #minetest-dev |
| 02:43 |
|
Kalabasa joined #minetest-dev |
| 02:44 |
|
proller joined #minetest-dev |
| 03:27 |
|
paramat joined #minetest-dev |
| 03:30 |
|
Miner_48er joined #minetest-dev |
| 03:32 |
paramat |
a simple mapgen PR ready for merge #2267 |
| 03:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/2267 -- Mgv7: Limit mountain height to positive only by paramat |
| 03:47 |
hmmmm |
hrmm |
| 03:47 |
hmmmm |
i'm not sure what that does in practice |
| 03:48 |
hmmmm |
VanessaE, are you around? |
| 03:57 |
paramat |
no problem it can wait until after release. its more to allow clever floatland-area usage in future with custom noiseparams |
| 03:59 |
est31 |
dunno, but hasnt c55 said that there should be a release branch now? |
| 03:59 |
est31 |
if there is, then please consider merging #2225, read the last comment. |
| 03:59 |
hmmmm |
if we can get a release out in a day or so it shouldn't matter |
| 03:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/2225 -- Fixes for minetest.get_(all_)craft_recipe(s) by gregorycu |
| 04:01 |
hmmmm |
hrmm? what do you mean by "there is no functional requirement"? |
| 04:04 |
|
FR^3 joined #minetest-dev |
| 04:04 |
|
FR^3 joined #minetest-dev |
| 04:15 |
|
FR^3 joined #minetest-dev |
| 04:25 |
|
FR^3 joined #minetest-dev |
| 04:33 |
hmmmm |
est31: I would be willing to merge that but I'm not really sure what you mean by the last comment in the PR |
| 04:34 |
est31 |
the label by shadowninja |
| 04:34 |
est31 |
so if you merge it it can be that you get a merge conflict I'm not sure |
| 04:35 |
est31 |
because two commits edited the same file |
| 05:03 |
paramat |
=D http://i.imgur.com/8NPApq4.png i emulated mudflow by only placing a biome node if supported by all 9 nodes below |
| 05:09 |
|
hmmmm joined #minetest-dev |
| 05:17 |
|
selat joined #minetest-dev |
| 05:43 |
hmmmm |
est31, but the commit it conflicts with also seems to 'fix' the get_craft_recipies api |
| 05:43 |
est31 |
#222 gets also fixed by the PR |
| 05:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/222 -- Non-ascii key crashes the game |
| 05:43 |
est31 |
hmmmm see the first message |
| 05:44 |
est31 |
comment* |
| 05:44 |
est31 |
and not 222 but 2222 |
| 05:44 |
est31 |
:) |
| 05:46 |
hmmmm |
https://github.com/minetest/minetest/issues/2222#issuecomment-71860311 ?? |
| 05:54 |
hmmmm |
eh... 2222 is fixed by the same commit that's already there |
| 05:55 |
hmmmm |
i'm looking at the actual code in 2225 and it's pretty wonky |
| 05:55 |
hmmmm |
why would i merge 2225 when all the craft recipe functions are already fixed as of HEAD? |
| 06:06 |
|
Megaf_ joined #minetest-dev |
| 06:18 |
|
paramat left #minetest-dev |
| 06:19 |
est31 |
hmmmm: ah understood you wrongly, its to fix #2210 |
| 06:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/2210 -- getCraftRecipes implementation is very slow |
| 06:19 |
est31 |
yoll find a lua example there with realistic dreambuilder conditions |
| 06:32 |
|
gregorycu joined #minetest-dev |
| 06:33 |
gregorycu |
How are we all |
| 06:33 |
gregorycu |
So, I'm looking at the render loop, and half(!) the time is spent setting up the shaders |
| 06:33 |
gregorycu |
That seems pretty crap, to be honest |
| 06:34 |
hmmmm |
setting up the shaders? |
| 06:34 |
hmmmm |
like what do you mean |
| 06:34 |
gregorycu |
setPixelShaderConstant etc/ |
| 06:34 |
gregorycu |
GameGlobalShaderConstantSetter::onSetConstants |
| 06:35 |
gregorycu |
The interesting this is that the values are cached on the GPU, and a lot of the time we send the same value that we sent last time |
| 06:36 |
hmmmm |
the gpu transfer is the thing taking most of the time?? |
| 06:36 |
gregorycu |
Well... half of the time |
| 06:36 |
gregorycu |
Half of the render loop |
| 06:36 |
hmmmm |
that's quite incredible |
| 06:37 |
gregorycu |
I've just done another perf run with latest code, I'll post a screenie somewhere |
| 06:38 |
hmmmm |
so... just cache the values and don't call setPixelShaderConstant if it's equal to the last set value? |
| 06:38 |
gregorycu |
Yes |
| 06:39 |
gregorycu |
That would be an effective way of doing it |
| 06:39 |
hmmmm |
i also see a g_settings->getBool("enable_fog") |
| 06:39 |
gregorycu |
You could probably be a little smarter, some shader settings hinge of game settings |
| 06:39 |
hmmmm |
sorry... haven't been keeping up with what's going on in minetest, what is the current state of your 'cache fog setting' patch? |
| 06:39 |
gregorycu |
Yes |
| 06:40 |
hmmmm |
has that been completely merged? |
| 06:40 |
hmmmm |
as i recall, there was a deadlock issue under pthread platforms |
| 06:41 |
|
gregorycu_ joined #minetest-dev |
| 06:41 |
gregorycu_ |
I have really shit internet at the moment |
| 06:41 |
gregorycu_ |
Yeah, that was fixed |
| 06:42 |
gregorycu_ |
I omitted a line when I rebased (by accident) |
| 06:42 |
gregorycu_ |
Basically the line that I missed was the one that changes g_settings->getBool("enable_fog") to m_enableFog |
| 06:42 |
hmmmm |
hrmm |
| 06:43 |
|
gregorycu__ joined #minetest-dev |
| 06:44 |
gregorycu |
Oh, Zeno fixed that |
| 06:44 |
est31 |
what |
| 06:44 |
hmmmm |
if I recall, you were complaining about not using C++11 for its mutex operations |
| 06:45 |
hmmmm |
specifically because of inconsistent behavior between recursive mutexes |
| 06:45 |
gregorycu |
This is a sore topic for some |
| 06:45 |
hmmmm |
i just looked at jmutex for windows and it uses critical sections, which aren't recursive... what's up with that then? |
| 06:45 |
hmmmm |
i don't get how that's possible |
| 06:45 |
gregorycu |
I believe they are recursive... |
| 06:45 |
hmmmm |
critical sections i thought not |
| 06:46 |
gregorycu |
Um... just by the way, this is not an issue anymore |
| 06:46 |
gregorycu |
I mean, it's good for an academic discussion, but it doesn't matter with regards to minetest |
| 06:46 |
hmmmm |
sure, i was just saying that it'd be weird and indicative of another problem if I'm correct about critical sections |
| 06:47 |
hmmmm |
ahh nevermind, it seems like it is |
| 06:47 |
gregorycu |
Cool |
| 06:47 |
gregorycu |
Anyway, Zeno pulled my rebase fix, which was a one-liner |
| 06:48 |
gregorycu |
I know he is doubtful, but it does give a perf improvement |
| 06:48 |
hmmmm |
what is it |
| 06:49 |
gregorycu |
Bear with me for 2 minutes, and I'll get a screenshot |
| 06:50 |
gregorycu |
It's 8% by the way, but one moment |
| 06:51 |
gregorycu |
Are you familiar with sampling profiling? |
| 06:51 |
hmmmm |
not that term... no.. do you mean looking at massif output? |
| 06:52 |
gregorycu |
I don't know what massif is |
| 06:52 |
hmmmm |
errm |
| 06:52 |
hmmmm |
i meant to say callgrind |
| 06:52 |
gregorycu |
No |
| 06:53 |
gregorycu |
There are two ways to profile, instrumentation (which is used by callgrind) and sampling |
| 06:53 |
gregorycu |
Sampling just looks at the callstack of the application every "so often" |
| 06:53 |
hmmmm |
ahhh |
| 06:53 |
hmmmm |
that sounds prone to errorneous results |
| 06:53 |
gregorycu |
"so often" is a small amount of time |
| 06:54 |
gregorycu |
So you get thousands of samples |
| 06:54 |
est31 |
third way is to edit the code |
| 06:54 |
gregorycu |
Editing the code is what instrumentation effectively does |
| 06:54 |
est31 |
aha interesting |
| 06:55 |
gregorycu |
I'm pretty sure, anyway |
| 06:56 |
gregorycu |
So, at the end of the day, with sampling, you effectively get a an analysis of where the app spends most of its time |
| 06:56 |
hmmmm |
so anyway, you used this instead of instrumentation I suppose? |
| 06:56 |
gregorycu |
Yes |
| 06:56 |
gregorycu |
Where can I upload a pic? |
| 06:56 |
hmmmm |
you need a very large number of samples in order to get effective data |
| 06:56 |
hmmmm |
imgur.com? |
| 06:56 |
hmmmm |
1000 samples isn't going to cut it |
| 06:57 |
gregorycu |
With the latest run I had 16.7k samples |
| 06:57 |
gregorycu |
More samples, the better, but I get quite consistant results |
| 06:58 |
gregorycu |
http://i.imgur.com/ULOyZdY.png |
| 06:58 |
hmmmm |
ahh this is visual studio's profiler |
| 06:58 |
gregorycu |
Yes |
| 06:59 |
gregorycu |
So, what that shows is that 2.64% of the applications time was spent inside Settings::getBool |
| 06:59 |
gregorycu |
34.85% of the time was spent inside ClientMap::renderMap |
| 07:00 |
hmmmm |
well renderMap is pretty heavyweight and it's hard to change |
| 07:00 |
gregorycu |
That's fine |
| 07:00 |
gregorycu |
The thing is, Settings::getBool makes up a portion of that time |
| 07:00 |
gregorycu |
It's a tree |
| 07:00 |
hmmmm |
it iterates through all of the sectors, culls out ones not in the view frustrum, then does some sort of broken occlusion culling, etc. |
| 07:01 |
hmmmm |
yeah am aware |
| 07:01 |
hmmmm |
i thought we discussed optimizing settings before? |
| 07:01 |
gregorycu |
We are |
| 07:01 |
gregorycu |
So yeah, doing the maths, 2.64 / 34.85 ~= 7.5% |
| 07:02 |
gregorycu |
Settings::getBool is about 7.5% of the render time |
| 07:02 |
gregorycu |
Where "render time" is how long the app spends in renderMap |
| 07:02 |
gregorycu |
Follow what I mean? |
| 07:03 |
hmmmm |
yes |
| 07:03 |
gregorycu |
Cool |
| 07:03 |
gregorycu |
Anyway, I was looking at the code that sets up the shaders |
| 07:03 |
gregorycu |
ShaderCallback::OnSetConstants |
| 07:04 |
gregorycu |
16.82% of the application time, or 48% of the time spent in renderMap |
| 07:05 |
gregorycu |
This is not good |
| 07:06 |
gregorycu |
Anyway, I'd love it if someone on linux could back up these figures |
| 07:06 |
hmmmm |
right, I thought we established this about 31 minutes ago |
| 07:06 |
hmmmm |
oh |
| 07:06 |
hmmmm |
sorry, I'm not on linux |
| 07:06 |
* est31 |
is |
| 07:06 |
est31 |
what to download/execute whatever? |
| 07:07 |
gregorycu |
I said this stuff 31 minutes ago, but I didn't have the data visible to you guys |
| 07:08 |
gregorycu |
Honestly est31, I am not sure what tools you need to run to get this data |
| 07:08 |
gregorycu |
But yeah, master would be good enough, I just need ballpark, to discount some severe problem on my system |
| 07:09 |
hmmmm |
what's *wrong* with callgrind though? |
| 07:09 |
est31 |
gonna try that |
| 07:10 |
* est31 |
builds MT without luajit |
| 07:10 |
gregorycu |
I was under the impression that callgrind does instrumentation, which is destructive |
| 07:11 |
hmmmm |
obviously it removes its own overhead out of the equation |
| 07:12 |
gregorycu |
Cool, I avoid instrumentation on windows as it seems to be somewhat innaccurate |
| 07:12 |
gregorycu |
But callgrind may be different, I just need ballpark anyway |
| 07:12 |
hmmmm |
nah, i think you're right, callgrind wouldn't work here since the values it produces are estimates based on instruction count |
| 07:13 |
hmmmm |
obviously if code spends a lot of time doing low-level memory transfers to the gpu then it won't pick that up |
| 07:13 |
hmmmm |
and what's more is that it'd be OS independent. there's no real reason why you'd need to test it in linux as well |
| 07:14 |
est31 |
even if its only an issue for win, it should be fixed, yes, but still testing is good |
| 07:15 |
gregorycu |
I suppose my only... comment |
| 07:15 |
gregorycu |
Is that this stuff seems so obvious, I mean 50% of the render time |
| 07:16 |
est31 |
dammit this callgrind hangs in the nodedef phase |
| 07:16 |
est31 |
and Im starting no dreambuilder here |
| 07:16 |
est31 |
*just* mt_game with technic |
| 07:16 |
gregorycu |
Another good thing about sampling is it doesn't slow down your app |
| 07:23 |
|
Krock joined #minetest-dev |
| 07:24 |
gregorycu |
I gotta run, but I'll be back in a few hours |
| 07:24 |
est31 |
k# |
| 07:24 |
* est31 |
s still waiting on callgrind |
| 07:25 |
|
Hunterz joined #minetest-dev |
| 07:39 |
VanessaE |
hmmmm: I am here now. |
| 07:39 |
hmmmm |
hey |
| 07:39 |
VanessaE |
(for a bit anyway) |
| 07:39 |
hmmmm |
VanessaE, about the formspec scaling issue |
| 07:39 |
hmmmm |
to clarify |
| 07:39 |
hmmmm |
does this happen with formspecs that *do* have a size element specified? |
| 07:41 |
VanessaE |
that I'm not sure of as I've never looked at the main menu code, however UI formspec does use a lot of specifically-sized elements if I recall right |
| 07:41 |
VanessaE |
s/UI/Unified Inventory/ |
| 07:41 |
VanessaE |
that's the formspec you saw in that three-part screenshot yesterday |
| 07:41 |
hmmmm |
main menu code formspecs are special though |
| 07:42 |
hmmmm |
i'm gonna be honest, I have no idea wtf i'm doing with the formspec code |
| 07:42 |
hmmmm |
that shit's such a mess |
| 07:42 |
VanessaE |
heh |
| 07:43 |
hmmmm |
it's a more complicated issue that can't be fixed quickly |
| 07:43 |
VanessaE |
when the whole mess erupted, Zeno added those if's around the code to disable it |
| 07:43 |
hmmmm |
well that has to do with the font size |
| 07:43 |
VanessaE |
maybe we just need something like that, if android { (do all that shit) } |
| 07:43 |
VanessaE |
ah |
| 07:44 |
hmmmm |
it's not that trivial at all... large chunks of code are moved around and changed |
| 07:44 |
VanessaE |
mmmh |
| 07:44 |
hmmmm |
as far as the hud size problem |
| 07:45 |
VanessaE |
I feel as others do though that to outright revert that commit (assuming it can be gracefully done)...well that's "elephant gun to kill a rat" territory... |
| 07:45 |
hmmmm |
looking at it right now, the hotbar seems fine so far, but the health and breath bars are definitely a problem |
| 07:45 |
VanessaE |
yeah |
| 07:45 |
VanessaE |
hotbar though used to scale up with window size, now it doesn't (so it has almost the opposite issue as formspecs) |
| 07:46 |
VanessaE |
those health bars are a complete confusion though - I haven't the faintest idea how their positioning works |
| 07:46 |
|
ImQ009 joined #minetest-dev |
| 07:46 |
VanessaE |
and to complicate matters: |
| 07:46 |
hmmmm |
so you WANT the hotbar to scale with the window size? |
| 07:46 |
hmmmm |
that I can easily fix |
| 07:46 |
VanessaE |
yeah |
| 07:46 |
VanessaE |
"But wait, there's more!" |
| 07:47 |
VanessaE |
damn it where is it |
| 07:47 |
VanessaE |
ah |
| 07:47 |
VanessaE |
#2262 |
| 07:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/2262 -- Subgame banner is hidden for wide windows |
| 07:47 |
hmmmm |
weird. |
| 07:47 |
VanessaE |
^^^^ because THAT one scales with one window dimension, while the formspec scales against the other window dimension |
| 07:47 |
VanessaE |
height vs width, that is |
| 07:48 |
hmmmm |
yeah i'll check it out |
| 07:48 |
hmmmm |
that's completely different from hud though |
| 07:48 |
est31 |
why should the hotbar scale with the window size |
| 07:48 |
VanessaE |
yep, I know |
| 07:48 |
est31 |
I like it the other way |
| 07:48 |
VanessaE |
I only mention it because it's affected by the scaling of the main menu |
| 07:48 |
hmmmm |
est, because it used to |
| 07:48 |
VanessaE |
which in turn is affected by window size |
| 07:49 |
VanessaE |
(I don't know when that particular issue started though) |
| 08:08 |
|
gregorycu_ joined #minetest-dev |
| 08:13 |
|
deltib joined #minetest-dev |
| 08:15 |
* est31 |
is wondering why the sum of samples % isnt 100 |
| 08:15 |
est31 |
What I've got from opreport is very weird |
| 08:28 |
|
kilbith joined #minetest-dev |
| 08:29 |
est31 |
side note: its pretty dumb to profile shaders when you havent enabled them |
| 08:30 |
est31 |
11% spent in __dubsin?? |
| 08:30 |
est31 |
10 in __cos_sse2 |
| 08:32 |
est31 |
gregorycu: what shader options to enable |
| 08:32 |
|
nrzkt joined #minetest-dev |
| 08:33 |
est31 |
hmmmm too |
| 08:34 |
nrzkt |
hello all |
| 08:35 |
VanessaE |
hi |
| 08:36 |
kilbith |
hi |
| 08:38 |
|
gregorycu_ joined #minetest-dev |
| 08:39 |
|
gregorycu__ joined #minetest-dev |
| 08:50 |
|
gregorycu_ joined #minetest-dev |
| 08:52 |
|
gregorycu__ joined #minetest-dev |
| 09:08 |
gregorycu |
I'm back |
| 09:09 |
gregorycu |
est31: I have no idea what options to turn on, I'm just running with default settings |
| 09:09 |
gregorycu |
Heck, shaders may be turned off and it still is badly performant |
| 09:09 |
est31 |
yea got some results |
| 09:09 |
est31 |
but dont back your fact |
| 09:09 |
est31 |
however only made a few draws |
| 09:10 |
est31 |
should make more... |
| 09:10 |
est31 |
s/fact/observation/ |
| 09:10 |
|
gregorycu_ joined #minetest-dev |
| 09:11 |
gregorycu_ |
hmmmm suggested that they may not match up |
| 09:11 |
gregorycu_ |
Can I see the results? |
| 09:12 |
est31 |
I'll do a second run with more than just a dozen draws |
| 09:12 |
est31 |
540 drawtime right now |
| 09:12 |
|
gregorycu__ joined #minetest-dev |
| 09:12 |
est31 |
1k |
| 09:13 |
est31 |
gregorycu_: have you opened the logs page to recieve what we are writing you? I guess shitty internet means your connection can lag out before we send you stuff |
| 09:14 |
gregorycu |
Yeah, I got the logs page open |
| 09:14 |
gregorycu |
450 and 1k |
| 09:14 |
gregorycu |
540 |
| 09:14 |
|
SopaXorzTaker joined #minetest-dev |
| 09:15 |
est31 |
ok should be enough |
| 09:15 |
gregorycu |
What are you actually measuring? What is "drawtime"? |
| 09:15 |
|
jin_xi joined #minetest-dev |
| 09:16 |
est31 |
drawtime is the value that shows up when you press f5 once |
| 09:16 |
est31 |
I guess it tells you how long the last render loop took |
| 09:17 |
est31 |
5.76% of all time in shadersource::getShader |
| 09:17 |
gregorycu |
Ok, I'll have to see what that measures |
| 09:17 |
est31 |
it just means callgrind makes mt slow :) |
| 09:17 |
est31 |
I guess it is just 1/fps |
| 09:20 |
est31 |
so how to share :) |
| 09:20 |
gregorycu |
How long is spent in ClientMap::renderMap |
| 09:20 |
est31 |
2.96 % |
| 09:20 |
gregorycu |
? |
| 09:20 |
|
decimalguy joined #minetest-dev |
| 09:20 |
est31 |
inclusive whatever that means |
| 09:20 |
gregorycu |
Oh, exclusing |
| 09:20 |
gregorycu |
2.96 inclusive? |
| 09:21 |
est31 |
exclusing 0.02% |
| 09:21 |
gregorycu |
... |
| 09:21 |
est31 |
so yes |
| 09:21 |
gregorycu |
Do you get a steady 60 fps? And is your machine a beast? |
| 09:22 |
est31 |
nono not 60 fps |
| 09:22 |
est31 |
the fps is quite slow |
| 09:22 |
est31 |
machine is no beast |
| 09:22 |
est31 |
not regarding gfx |
| 09:23 |
est31 |
it has good ram and cpu but not excellent |
| 09:23 |
est31 |
however, you rarely need more :) |
| 09:23 |
|
gregorycu_ joined #minetest-dev |
| 09:24 |
gregorycu_ |
Oh... |
| 09:25 |
gregorycu_ |
It's probably excluding time spent in kernal/GPU calls |
| 09:25 |
est31 |
settings: http://pbrd.co/1ItxYpa benchmark table: http://pbrd.co/1Ity8gp |
| 09:26 |
|
gregorycu__ joined #minetest-dev |
| 09:27 |
gregorycu |
Is there a tree view or something? |
| 09:28 |
est31 |
no :( |
| 09:28 |
est31 |
there is some map |
| 09:28 |
est31 |
that visualizes the cost |
| 09:29 |
|
ElectronLibre joined #minetest-dev |
| 09:29 |
est31 |
http://pbrd.co/1ItzDeH |
| 09:30 |
est31 |
example |
| 09:30 |
est31 |
you also have other view |
| 09:31 |
est31 |
s |
| 09:31 |
est31 |
you can get a relative overview just like in a tree view |
| 09:31 |
est31 |
so yes |
| 09:31 |
est31 |
there is some sort of a tree view |
| 09:31 |
gregorycu |
http://i.imgur.com/ULOyZdY.png |
| 09:32 |
gregorycu |
Are you able to show this subtree in the tree |
| 09:34 |
est31 |
http://pbrd.co/1ItAJXB |
| 09:37 |
gregorycu |
I don't know why your render loop is such a tiny slice of your app time |
| 09:38 |
gregorycu |
I don't know why your render loop is such a tiny slice of your app time |
| 09:38 |
gregorycu |
Oops |
| 09:38 |
gregorycu |
So, the shader stuff is about 20% for you |
| 09:38 |
gregorycu |
22% |
| 09:39 |
est31 |
22? |
| 09:40 |
gregorycu |
ClientMap::renderMap is 2.96%, ShaderSource::onSetConstants is 0.63% |
| 09:40 |
gregorycu |
0.63 / 2.96 = 22% |
| 09:41 |
gregorycu |
ShaderSource::onSetConstants is a subset of the time of renderMap |
| 09:41 |
est31 |
ah |
| 09:41 |
est31 |
yes |
| 09:42 |
|
Calinou joined #minetest-dev |
| 09:42 |
gregorycu |
For me (with latest) it's 44% |
| 09:43 |
est31 |
I'm not on very latest |
| 09:43 |
gregorycu |
I can see that, but that's fine |
| 09:43 |
est31 |
Im at d902bd31 |
| 09:43 |
gregorycu |
Latest basically removes the call to Settings::getBool |
| 09:43 |
gregorycu |
(On the left side of that tree) |
| 09:45 |
gregorycu |
I have different settings than you, I'll retry |
| 09:48 |
est31 |
Ive disabled 3d clouds to be abled to navigate in mainmenu |
| 09:49 |
gregorycu |
lol,seriously? |
| 09:49 |
est31 |
yea :) |
| 09:49 |
est31 |
while calllgrind is on of course |
| 09:49 |
est31 |
otherwise its fine |
| 09:53 |
|
Aaron1011 joined #minetest-dev |
| 09:53 |
|
Aaron1011 joined #minetest-dev |
| 09:54 |
|
cib0 joined #minetest-dev |
| 09:55 |
gregorycu |
... |
| 09:56 |
gregorycu |
I've been looking at the ground while profiling to make sure I get the worst case |
| 09:56 |
gregorycu |
(Maximum number of fps, maximum number of shader settings) |
| 09:56 |
gregorycu |
I decided to do a profile run while looking into the distance |
| 09:57 |
gregorycu |
renderMap: 59.64%, OnSetConstants 36.04% |
| 09:57 |
gregorycu |
60% |
| 09:58 |
|
MattJ joined #minetest-dev |
| 09:59 |
est31 |
not for me :\ |
| 09:59 |
gregorycu |
Are you running around in your test? |
| 10:00 |
est31 |
no |
| 10:00 |
est31 |
you |
| 10:00 |
gregorycu |
No |
| 10:13 |
|
PilzAdam joined #minetest-dev |
| 10:20 |
|
gregorycu_ joined #minetest-dev |
| 10:25 |
|
gregorycu_ joined #minetest-dev |
| 10:26 |
|
Megal_ joined #minetest-dev |
| 10:27 |
|
gregorycu__ joined #minetest-dev |
| 10:41 |
|
Aaron1011 joined #minetest-dev |
| 11:09 |
gregorycu |
What's actually interesting, is that only some shader settings are expensive to send |
| 11:09 |
gregorycu |
I don't know a lot about shaders, to be honest |
| 11:18 |
Krock |
Is zlib used by gettext? |
| 11:33 |
gregorycu |
Did you want me to find out? |
| 11:34 |
Krock |
yeah |
| 11:38 |
gregorycu |
Doesn't look like it |
| 11:52 |
gregorycu |
This is interesting |
| 12:04 |
|
blaze joined #minetest-dev |
| 12:09 |
gregorycu |
Ok, where is hmmm when you need him |
| 12:10 |
gregorycu |
Sleeping is not a good excuse |
| 12:11 |
est31 |
lol |
| 12:11 |
gregorycu |
est31 I will share my finding with you |
| 12:11 |
est31 |
which |
| 12:11 |
gregorycu |
We appear to set the shader settings WAY more frequently than once a frame |
| 12:11 |
est31 |
oh no |
| 12:12 |
gregorycu |
I ran it for about 6000 frames, and there were 1.9M shader settings updates |
| 12:12 |
Calinou |
should be once per frame? |
| 12:13 |
gregorycu |
It's cached on the GPU, so you only need to send things that are updated |
| 12:13 |
gregorycu |
But yes, once per frame would be better |
| 12:13 |
gregorycu |
Than... lots per frame |
| 12:13 |
|
jin_xi joined #minetest-dev |
| 12:14 |
gregorycu |
I can't even contemplate what sort of degradation on performance this is having |
| 12:14 |
gregorycu |
When I say 1.9M shader settings updates, I mean every global in the shader was updated |
| 12:14 |
sfan5 |
that doesn't happen with shaders disabled, does it? |
| 12:15 |
gregorycu |
that's a very good question, I'll have a look |
| 12:16 |
gregorycu |
Thanks goodness, no it doesn't |
| 12:17 |
sfan5 |
so if i disable shaders minetest should perform better? |
| 12:17 |
gregorycu |
I believe so, I'm about to test that |
| 12:21 |
gregorycu |
Yeah |
| 12:21 |
gregorycu |
Like 150fps looking around, as opposed to 70 or something |
| 12:22 |
gregorycu |
Hard to quantify |
| 12:26 |
sfan5 |
hm |
| 12:26 |
sfan5 |
my fps is capped to 60 for some reason |
| 12:26 |
Calinou |
vsync? fps_max = 60 ? |
| 12:26 |
sfan5 |
and minetest still sleeps in mainloop even when i set fps_max = 0 |
| 12:26 |
Calinou |
it should not |
| 12:26 |
sfan5 |
also there should be a divide-by-zero when fps_max is 0 |
| 12:26 |
Calinou |
fps_max = 0 is meant for benchmarking, so no sleeping should be done |
| 12:27 |
sfan5 |
nvm |
| 12:27 |
gregorycu |
I set it to 1000 |
| 12:27 |
sfan5 |
it doesn't sleep anymore |
| 12:27 |
sfan5 |
it still doesn't go above 60 though |
| 12:29 |
sfan5 |
apparently you can divide by 0 |
| 12:29 |
gregorycu |
My maths teachers were wrong all this time |
| 12:29 |
gregorycu |
Are there multiple entries in the config |
| 12:29 |
gregorycu |
(With the same key?) |
| 12:29 |
sfan5 |
no |
| 12:30 |
sfan5 |
https://github.com/minetest/minetest/blob/master/src/game.cpp#L4085-4087 |
| 12:31 |
gregorycu |
It's a float |
| 12:31 |
gregorycu |
Divide by zero is allowed |
| 12:31 |
sfan5 |
for what reason? |
| 12:32 |
gregorycu |
Don't know |
| 12:32 |
gregorycu |
But the result is infinity |
| 12:34 |
sfan5 |
i guess 4294967295 is supposed to be infinity |
| 12:35 |
sfan5 |
if (fps_timings->busy_time < frametime_min) { [...] |
| 12:35 |
sfan5 |
unless rendering the frame also takes infinity time it should try to sleep |
| 12:35 |
sfan5 |
or am i not understanding this right? |
| 12:37 |
gregorycu |
I'm sure you'd figure it out if you wanted to |
| 12:37 |
gregorycu |
But can you be bothered? |
| 12:37 |
sfan5 |
wait what |
| 12:38 |
sfan5 |
1000 / 0.0 is apparently 50 |
| 12:38 |
gregorycu |
lol |
| 12:39 |
sfan5 |
g_settings->getFloat("fps_max")=0 |
| 12:39 |
sfan5 |
frametime_min=50 fps_timings->busy_time=12 |
| 12:39 |
sfan5 |
(fps_timings->busy_time < frametime_min) == true |
| 12:39 |
gregorycu |
Um... check the bits on the float |
| 12:39 |
sfan5 |
the float does not matter |
| 12:39 |
sfan5 |
it gets converted to u32 and used |
| 12:39 |
gregorycu |
What gets converted to u32? |
| 12:39 |
sfan5 |
1000 / fps_max |
| 12:39 |
sfan5 |
https://github.com/minetest/minetest/blob/master/src/game.cpp#L4085-4087 |
| 12:39 |
gregorycu |
A floating point value, with possibly the +inf bit set and junk values elsewhere |
| 12:43 |
sfan5 |
nevermind |
| 12:43 |
sfan5 |
it was the pause fps |
| 12:44 |
sfan5 |
(u32) (1000 / 0.0) seems to be 0 |
| 13:36 |
|
MinetestForFun joined #minetest-dev |
| 13:40 |
gregorycu |
This is very much non-trivial to fix |
| 13:42 |
|
MinetestForFun joined #minetest-dev |
| 13:44 |
|
Amaz joined #minetest-dev |
| 13:45 |
|
JakubVanek joined #minetest-dev |
| 13:46 |
|
JakubVanek joined #minetest-dev |
| 13:48 |
JakubVanek |
sfan5: what OS do you have? on linux on Mesa is vsync everywhere |
| 14:08 |
Calinou |
Nouveau and Intel force v-sync by default indeed |
| 14:08 |
Calinou |
proprietary NVIDIA driver doesn't |
| 14:11 |
sfan5 |
JakubVanek: linux & intel |
| 14:16 |
JakubVanek |
found this (for glxgears, but should work): http://stackoverflow.com/questions/17196117/disable-vertical-sync-for-glxgears |
| 14:33 |
|
luizrpgluiz joined #minetest-dev |
| 14:37 |
|
DevilMayhem joined #minetest-dev |
| 14:52 |
|
kilbith joined #minetest-dev |
| 14:53 |
|
DFeniks joined #minetest-dev |
| 15:02 |
|
acerspyro joined #minetest-dev |
| 15:14 |
|
nore joined #minetest-dev |
| 15:14 |
|
luizrpgluiz left #minetest-dev |
| 15:40 |
|
ElectronLibre joined #minetest-dev |
| 15:42 |
|
kilbith joined #minetest-dev |
| 16:01 |
|
prozacgod joined #minetest-dev |
| 16:03 |
sfan5 |
i get about 7 fps more with shaders disabled |
| 16:06 |
|
SopaXorzTaker joined #minetest-dev |
| 16:14 |
|
CraigyDavi joined #minetest-dev |
| 16:28 |
|
ElectronLibre joined #minetest-dev |
| 16:40 |
|
DFeniks joined #minetest-dev |
| 16:41 |
|
Calinou joined #minetest-dev |
| 16:59 |
|
rubenwardy joined #minetest-dev |
| 17:10 |
|
hmmmm joined #minetest-dev |
| 17:11 |
hmmmm |
guys? |
| 17:11 |
hmmmm |
sfan? |
| 17:12 |
* VanessaE |
pokes hmmmm |
| 17:12 |
hmmmm |
hello |
| 17:12 |
hmmmm |
I looked at the HUD thing and the icons are all the same size as they used to be |
| 17:14 |
VanessaE |
unless something has changed in the last couple of days, they don't scale with window size anymore. it used to be that they'd be equivalent to hud_scale = 0.7 or thereabouts, at 800x600, and hud_scale=1.0 or close to it at 1600x1200, as measured with current code. |
| 17:17 |
|
SopaXorzTaker joined #minetest-dev |
| 17:19 |
hmmmm |
vanessae: the heart/bubble icons were always 24 pixels on-screen... correct? |
| 17:19 |
|
OldCoder joined #minetest-dev |
| 17:19 |
VanessaE |
yep |
| 17:19 |
VanessaE |
HUD also refers to the hotbar, btw |
| 17:20 |
hmmmm |
the only problem imaginable might be that the offset is slightly different |
| 17:20 |
VanessaE |
that explains the confusion here :) |
| 17:20 |
VanessaE |
anyway yeah they were always ~24 pixels (unless a texture pack supplied larger images, for a while there that broke it, but that was fixed). |
| 17:21 |
VanessaE |
the complaint you're probably thinking of though is that some games like carbone and dreambuilder have hotbars that are larger than 8 slots, so with the hotbar scaling issue as it currently stands, one side effect is that the hotbar no longer fits into one row |
| 17:22 |
VanessaE |
so it takes two rows now (at default window size), making the health bar overlap it |
| 17:26 |
VanessaE |
so two fixes are needed - health/breath bars (and whatever else is added above them by a mod) need to shift upward to stay clear of the hotbar, then the hotbar scaling has to be fixed |
| 17:27 |
hmmmm |
isn't there a simple solution to this? |
| 17:27 |
hmmmm |
have an option to tie hud_scaling to window resolution |
| 17:27 |
VanessaE |
at one time, it was |
| 17:28 |
hmmmm |
why is it not now. |
| 17:28 |
VanessaE |
that broke when all this stuff went awry. |
| 17:28 |
VanessaE |
I've no idea what the rationale was. |
| 17:29 |
VanessaE |
I'm sure Zefram or sapier explained it at the time, but damned it I can remember it |
| 17:29 |
hmmmm |
i don't see any problems with making hud_scaling dependent upon window res |
| 17:29 |
hmmmm |
with a certain option set of course |
| 17:29 |
hmmmm |
i don't want to force this onto everybody |
| 17:29 |
VanessaE |
me neither - with one proviso: |
| 17:29 |
VanessaE |
that the scaling be dependent on something that takes both height and width into account. |
| 17:29 |
hmmmm |
what resolution would hud_scaling = 1.0 be though |
| 17:30 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2006162014%20-%2008%3a47%3a07%20PM.png |
| 17:30 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2006192014%20-%2005%3a34%3a41%20AM.png |
| 17:30 |
VanessaE |
those two should give a fair representation of the HUD at two different sizes, before it all broke |
| 17:31 |
hmmmm |
that kind of scaling functionality isn't critical though |
| 17:31 |
hmmmm |
it's not a blocker |
| 17:32 |
hmmmm |
the health/breath statbars overlapping with the hotbar IS a blocker and it's easily fixed by modiying the offset |
| 17:33 |
VanessaE |
this is what it does now, just fyi: |
| 17:33 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2002082015%20-%2012%3a36%3a31%20PM.png |
| 17:33 |
VanessaE |
(for the sake of having a current image) |
| 17:33 |
hmmmm |
well, that is a very small screen |
| 17:33 |
VanessaE |
that's the default window size. |
| 17:33 |
hmmmm |
and an overly-large hotbar |
| 17:34 |
VanessaE |
that's the hotbar scaling being screwed up. |
| 17:34 |
VanessaE |
it used to take one row. |
| 17:34 |
VanessaE |
besides, the image here is just for reference |
| 17:35 |
acerspyro |
The fuck with this wm theme o.o |
| 17:35 |
hmmmm |
acerspyro: I am really getting pissed off with you |
| 17:35 |
VanessaE |
acerspyro: XFCE "Keramik", recolored to purple. |
| 17:35 |
acerspyro |
hmmmm: good, I talk once and you get pissed off. gg. |
| 17:35 |
|
twoelk joined #minetest-dev |
| 17:35 |
hmmmm |
acerspyro: Tihs channel is for development discussion only. Criticising people's WM themes is NOT dev talk |
| 17:35 |
acerspyro |
VanessaE: Oh, I see. |
| 17:35 |
hmmmm |
christ.. |
| 17:36 |
VanessaE |
ANYway |
| 17:36 |
hmmmm |
I don't know, some people might like the hotbar stacking thing |
| 17:36 |
hmmmm |
that part comes down to personal preference |
| 17:36 |
hmmmm |
what doesn't come down to personal preference is the fact that they overlap eachother |
| 17:36 |
VanessaE |
here's that same screen, at 1600x1200: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2002082015%20-%2012%3a39%3a49%20PM.png |
| 17:37 |
hmmmm |
yeah... gross |
| 17:37 |
hmmmm |
I am ashamed to be associated with hud.cpp at this point :( |
| 17:37 |
hmmmm |
look at that trainwreck |
| 17:38 |
hmmmm |
well :) just kidding |
| 17:38 |
VanessaE |
heh |
| 17:38 |
|
acerspyro left #minetest-dev |
| 17:38 |
hmmmm |
the root problem here is not that it doesn't scale to the window size |
| 17:38 |
hmmmm |
it's that drawing offsets are dependent upon eachother |
| 17:39 |
hmmmm |
and the dynamic hud statbar isn't designed that way |
| 17:40 |
VanessaE |
when the whole statbar thing was being revamped, I advocated for relative slot positioning for these sorts of things, because I just knew that sooner or later something like this was gonna happen |
| 17:40 |
hmmmm |
fwiw the second screenshot would probably look normal if the breath bar were present |
| 17:40 |
VanessaE |
(though I didn't expect it to happen in precisely thisd manner) |
| 17:40 |
VanessaE |
yeah, the left/right positioning of the two statbars is fine, never had a problem with that. |
| 17:41 |
VanessaE |
just didn't feel like taking a swim ;) |
| 17:42 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2002082015%20-%2012%3a45%3a18%20PM.png |
| 17:43 |
VanessaE |
versus default window size, worse case with those statbars etc: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2002082015%20-%2012%3a46%3a07%20PM.png |
| 17:43 |
VanessaE |
ouch. |
| 17:48 |
hmmmm |
:| |
| 17:48 |
hmmmm |
https://github.com/minetest/minetest/commit/15c037614f6f7193cef4bfd1da45d83ef2fef393 |
| 17:48 |
hmmmm |
it's the best i can do right now |
| 17:48 |
hmmmm |
in order to 100% fix statbars as they exist right now, we'd need to add in 'slot' functionality rather than positioning by pixels |
| 17:49 |
VanessaE |
*looks at commit* |
| 17:49 |
VanessaE |
inb4 pr*ller complains about whitespace fixes :P |
| 17:49 |
VanessaE |
nice touch of caching size_factor. |
| 17:49 |
hmmmm |
i'd hope it got optimized anyway... |
| 17:49 |
hmmmm |
but it probably didn't |
| 17:49 |
VanessaE |
kinda surprised that wasn't already done actually. |
| 17:50 |
* VanessaE |
gives it a try |
| 17:50 |
hmmmm |
did you notice I also fixed the compatibility code lol |
| 17:51 |
hmmmm |
hearts were drawn for breath |
| 17:52 |
VanessaE |
HAH! |
| 17:52 |
hmmmm |
anyway let's release |
| 17:52 |
VanessaE |
I didn't catch that before |
| 17:52 |
hmmmm |
seriously |
| 17:52 |
VanessaE |
lemme check this out |
| 17:52 |
hmmmm |
sfan5: are you there |
| 17:52 |
VanessaE |
FAIL |
| 17:53 |
VanessaE |
that had no effect on the statbars, at least in dreambuilder |
| 17:53 |
VanessaE |
or rather, no effect to get them out of the way of the two-row hotbar |
| 17:53 |
hmmmm |
right.. |
| 17:53 |
hmmmm |
all I did was modify an offset |
| 17:53 |
VanessaE |
oh ok |
| 17:54 |
hmmmm |
like I said |
| 17:54 |
VanessaE |
oh yeah I can see the difference now |
| 17:54 |
VanessaE |
derp |
| 17:54 |
hmmmm |
if I actually wanted to fix that, then I'd have to add slots to the hud |
| 17:54 |
hmmmm |
the implementation of which can get rather tricky |
| 17:54 |
VanessaE |
can you at least restore the hotbar scaling? |
| 17:54 |
VanessaE |
that'll workaround the problem for now I think |
| 18:03 |
sfan5 |
hmmmm: yes |
| 18:04 |
hmmmm |
sfan5: hi! |
| 18:04 |
hmmmm |
are you around to make official release builds? |
| 18:04 |
hmmmm |
and if so for what platforms? |
| 18:05 |
sfan5 |
when? now? |
| 18:05 |
sfan5 |
platformsdd |
| 18:05 |
sfan5 |
are win32 and win64 |
| 18:05 |
sfan5 |
(mingw ofc) |
| 18:05 |
hmmmm |
I need to bump the version |
| 18:05 |
hmmmm |
first |
| 18:06 |
hmmmm |
I can do win32 MSVC |
| 18:06 |
hmmmm |
but not win64 yet |
| 18:17 |
|
jin_xi joined #minetest-dev |
| 18:18 |
hmmmm |
i installed visual studio express on the VM i was testing MSVC-specific things with, so no 64 bit compiling |
| 18:18 |
hmmmm |
i can't download it from msdn either because that site never works, all my downloads error after like 10 minutes |
| 19:27 |
|
kilbith joined #minetest-dev |
| 19:30 |
|
kilbith joined #minetest-dev |
| 19:47 |
MattJ |
Hmm, any plans to package 0.4.11 for Ubuntu 14.10? |
| 19:47 |
Krock |
How about 0.4.12 when it's ready? |
| 19:47 |
MattJ |
or 0.4.12 when it's ready :) |
| 20:07 |
|
MichaelRpdx joined #minetest-dev |
| 20:16 |
hmmmm |
erm |
| 20:17 |
hmmmm |
so I am downloading VS 2008 professional right now, I should be able to do all 4 builds on my own |
| 20:17 |
hmmmm |
like 2 hours remaining :p |
| 20:27 |
|
MinetestForFun joined #minetest-dev |
| 20:31 |
|
MinetestForFun joined #minetest-dev |
| 20:36 |
|
Vexyl joined #minetest-dev |
| 20:41 |
|
JakubVanek joined #minetest-dev |
| 20:42 |
|
ElectronLibre joined #minetest-dev |
| 20:44 |
|
kilbith joined #minetest-dev |
| 20:44 |
|
VanessaE joined #minetest-dev |
| 20:44 |
JakubVanek |
Utopic 0.4.11 is supported (idk if it's official): https://launchpad.net/~minetestdevs/+archive/ubuntu/stable |
| 20:46 |
VanessaE |
that repo is official. |
| 20:46 |
JakubVanek |
oh only 0.4.10 :( |
| 20:46 |
VanessaE |
however 0.4.12 is about to be released |
| 20:48 |
|
shadowzone joined #minetest-dev |
| 20:55 |
|
shadowzone joined #minetest-dev |
| 21:16 |
|
kilbith joined #minetest-dev |
| 21:40 |
|
JakubVanek joined #minetest-dev |
| 21:52 |
Calinou |
who will update the changelog? |
| 21:52 |
Calinou |
no one has touched it since 0.4.11 |
| 21:55 |
|
ElectronLibre left #minetest-dev |
| 21:55 |
hmmmm |
I guess I will |
| 22:02 |
|
roniz joined #minetest-dev |
| 22:52 |
|
decimalguy left #minetest-dev |
| 22:56 |
|
Player_2 joined #minetest-dev |
| 23:18 |
|
Wayward_One joined #minetest-dev |
