| Time |
Nick |
Message |
| 00:36 |
|
diemartin joined #minetest-dev |
| 00:42 |
|
lordfingle joined #minetest-dev |
| 00:49 |
|
Niebieski joined #minetest-dev |
| 00:52 |
|
Lunatrius` joined #minetest-dev |
| 01:12 |
|
jordan4ibanez joined #minetest-dev |
| 02:00 |
|
sloantothebone joined #minetest-dev |
| 02:00 |
|
red1 joined #minetest-dev |
| 02:27 |
|
red1 joined #minetest-dev |
| 03:44 |
VanessaE |
new benchmark in case anyone is interested: |
| 03:45 |
VanessaE |
with 10 minetest client instances running, plus one that's trying to barf due to serialization errors, each signed onto a different server, I'm still pulling 18-19 fps on each one, drawtimes in the range of 25 to 30, variably. |
| 03:45 |
VanessaE |
so 18 * 10 == 180 fps effective speed |
| 03:45 |
|
sloantothebone_ joined #minetest-dev |
| 03:45 |
VanessaE |
so how Minetest communicates with the GPU is definitely the problem - gotta be a threading issue |
| 03:48 |
VanessaE |
correction |
| 03:49 |
VanessaE |
make that more like 12 to 30 fps on each. I had them all in "pause" mode (so their framerates were being capped, of course) |
| 03:52 |
VanessaE |
I'd guestimate an average of 30 fps, so 30 * 10 == 300 fps, as an optimistic figure |
| 04:06 |
VanessaE |
ok now 11 clients running, and all but one are pulling 28-30 fps (the one that isn't is on my Creative server and doing 11-12) |
| 04:15 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/11-client-screenshot---2015-07-02.png |
| 04:20 |
VanessaE |
in that screenshot, all 6 of my cores are running just a hair short of full-blast |
| 04:21 |
VanessaE |
RealBadAngel: ^^^ |
| 04:55 |
|
Hunterz joined #minetest-dev |
| 05:01 |
|
book` joined #minetest-dev |
| 05:10 |
|
sloantothebone joined #minetest-dev |
| 05:17 |
|
Robert_Zenz joined #minetest-dev |
| 05:25 |
|
Puma_rc joined #minetest-dev |
| 05:34 |
|
sloantothebone joined #minetest-dev |
| 05:43 |
|
Hunterz joined #minetest-dev |
| 06:04 |
sofar |
lots of deprecated warnings in HEAD atm... getBoneName() ... |
| 06:13 |
sofar |
minimap looks great, fps is fine too for me |
| 06:13 |
sofar |
well, this 9800gt has seen the best of days, really |
| 06:13 |
sofar |
at 2560x1600 I barely squeeze 45fps-50fps out of it |
| 06:19 |
RealBadAngel |
not that bad |
| 06:19 |
VanessaE |
RealBadAngel: look up. |
| 06:20 |
RealBadAngel |
but if vbo code will get in you will get way more |
| 06:20 |
RealBadAngel |
i can see that |
| 06:20 |
RealBadAngel |
pretty interesting |
| 06:22 |
RealBadAngel |
but seriously, we dont have much running in threads |
| 06:22 |
RealBadAngel |
mapgen, meshgen and minimap only |
| 06:22 |
RealBadAngel |
whole game runs in single thread |
| 06:23 |
VanessaE |
clearly :) |
| 06:24 |
RealBadAngel |
thats nothing new |
| 06:24 |
VanessaE |
but that screenshot is conclusive proof that my drivers are not slow :) |
| 06:24 |
RealBadAngel |
you had problems with another apps too |
| 06:24 |
RealBadAngel |
like this benchmark |
| 06:25 |
VanessaE |
indeed, but running multiple instance at once proves that my CPU has enough raw grunt to feed this GPU. |
| 06:25 |
VanessaE |
instances* |
| 06:25 |
VanessaE |
and of minetest, yet. |
| 06:26 |
RealBadAngel |
you shall work in AMD public relations ;) |
| 06:26 |
VanessaE |
... |
| 06:26 |
VanessaE |
my point is that my drivers aren't broken like you thought, |
| 06:26 |
RealBadAngel |
youre defending them all the time ;) |
| 06:27 |
RealBadAngel |
ofc they are |
| 06:27 |
RealBadAngel |
i had same issues when i had radeon |
| 06:27 |
VanessaE |
I'll bet you didn't try running 11 instances of Minetest all at once though :) |
| 06:27 |
RealBadAngel |
switched to nvidia and all the problems are gone |
| 06:28 |
RealBadAngel |
what for? |
| 06:29 |
VanessaE |
at first it was a competition between cheapie and I |
| 06:29 |
VanessaE |
then I decided to push it further and make a screenshot as a benchmark |
| 06:29 |
VanessaE |
notice the total FPS across all of them |
| 06:29 |
VanessaE |
something close to 300 |
| 06:30 |
VanessaE |
had you done the same, you'd have come to realize that MT's single-thread performance either sucks, or it's maxed out and more threads are needed :) |
| 06:30 |
cheapie |
For the record, I got about 15 FPS in each, running 10 clients, at a view range that normally gets me ~25 when I'm running one. |
| 06:31 |
VanessaE |
how many cores, cheapie ? |
| 06:31 |
cheapie |
8 integer cores sharing 4 FPU cores. |
| 06:32 |
VanessaE |
6 here, not sure of the integer vs FPU figures. |
| 06:32 |
cheapie |
What CPU model is it? |
| 06:33 |
VanessaE |
Phenom II X6 1055T |
| 06:33 |
cheapie |
I think that's a "normal" one. |
| 06:33 |
cheapie |
(meaning each integer core is paired with its own FP core) |
| 06:33 |
VanessaE |
ok. |
| 06:34 |
cheapie |
This one is an FX-9590, for the record. |
| 06:39 |
VanessaE |
RealBadAngel: in any case, needs MOAR threads! :P |
| 06:39 |
|
CraigyDavi joined #minetest-dev |
| 06:47 |
|
kaeza joined #minetest-dev |
| 07:05 |
|
kilbith joined #minetest-dev |
| 07:07 |
asl97 |
iirc, you can't have more than one thread doing the render on most library, it mess up quite badly |
| 07:07 |
|
Darcidride joined #minetest-dev |
| 07:07 |
VanessaE |
asl97: tell that to folks who run OpenArena or Counterstrike. |
| 07:08 |
|
OldCoder joined #minetest-dev |
| 07:23 |
asl97 |
they most likely use the other thread to do the prerendering stuff like texture and mesh |
| 07:26 |
|
OldCoder joined #minetest-dev |
| 08:00 |
|
Yepoleb_ joined #minetest-dev |
| 08:31 |
|
OldCoder joined #minetest-dev |
| 08:32 |
|
Calinou joined #minetest-dev |
| 08:40 |
|
nrzkt joined #minetest-dev |
| 08:40 |
|
julienrat joined #minetest-dev |
| 08:40 |
|
chchjesus_ joined #minetest-dev |
| 08:42 |
julienrat |
hi Megaf ! have you solved your problem on Rpi with this error ? " libEGL warning: DRI2: failed to authenticate" // http://irc.minetest.ru/minetest-dev/2014-10-09 |
| 08:43 |
julienrat |
coz i'm trying to run minetest with opengl-ES enabled on my raspberry pi2 ... |
| 08:43 |
julienrat |
and i have got the same problem |
| 08:44 |
julienrat |
any ideas ? |
| 08:48 |
kilbith |
julienrat, PM |
| 09:08 |
|
jin_xi joined #minetest-dev |
| 09:26 |
|
rubenwardy joined #minetest-dev |
| 09:35 |
|
red1 joined #minetest-dev |
| 09:42 |
|
selat joined #minetest-dev |
| 10:15 |
|
blaze joined #minetest-dev |
| 11:14 |
|
Kray joined #minetest-dev |
| 11:15 |
|
Lunatrius` joined #minetest-dev |
| 11:19 |
|
red1 joined #minetest-dev |
| 11:20 |
|
Robert_Zenz joined #minetest-dev |
| 11:23 |
|
asl97 joined #minetest-dev |
| 12:22 |
|
Niebieski joined #minetest-dev |
| 12:34 |
crazyR_ |
Jasper any update on your suggestions/ideas for a few days ago? |
| 12:34 |
crazyR_ |
*for/from |
| 12:41 |
|
julienrat joined #minetest-dev |
| 13:12 |
|
proller joined #minetest-dev |
| 13:50 |
|
Krock joined #minetest-dev |
| 13:54 |
crazyR_ |
hey guys is there information about how to use gettext inside mods? |
| 13:54 |
Calinou |
you can't use gettext directly, instead use kaeza's intllib |
| 13:55 |
Calinou |
which is quite a standard now |
| 13:55 |
Calinou |
but remember, the translation is server-side and affects all players |
| 13:56 |
crazyR_ |
so theres no way to allow each player to view content in there own language as defined in there own config? |
| 13:59 |
crazyR_ |
oh it ok i see. hmm how could the intlib hasnt been made core part of minetest. |
| 14:01 |
crazyR_ |
*could/come |
| 14:04 |
crazyR_ |
if the client was to send the language that is defined in the conf to the server. then intlib could be modified to be unuiqe to each player.. |
| 14:05 |
crazyR_ |
being able to retrieve the player language in mod via the player object should be good enough. opinions? |
| 14:33 |
|
proller joined #minetest-dev |
| 14:38 |
Sokomine |
hmm. anyone present who has a deeper understanding of mod_security? |
| 14:38 |
* Sokomine |
looks around and tries to catch a shadowninja |
| 14:58 |
|
Darcidride joined #minetest-dev |
| 14:59 |
|
Hunterz joined #minetest-dev |
| 14:59 |
|
CraigyDavi joined #minetest-dev |
| 15:15 |
Megaf |
Hi all, |
| 15:15 |
Megaf |
That is interesting. |
| 15:15 |
Megaf |
../games/minetest_game/mods/default/nodes.lua:1538: attempt to call a nil value |
| 15:15 |
Megaf |
../games/minetest_game/mods/default/nodes.lua:1538: in main chunk |
| 15:22 |
|
rubenwardy joined #minetest-dev |
| 15:31 |
|
red1 joined #minetest-dev |
| 15:37 |
|
zat joined #minetest-dev |
| 15:37 |
Megaf |
julienrat: just give up of minetest on the Raspbery, they don't care... |
| 15:39 |
Sokomine |
i'm pretty sure people care. but what has an error in minetest_game to do with the raspberry? |
| 15:40 |
kilbith |
nothing |
| 15:46 |
|
Player_2 joined #minetest-dev |
| 15:46 |
|
hmmmm joined #minetest-dev |
| 15:46 |
|
proller joined #minetest-dev |
| 16:05 |
|
rubenwardy joined #minetest-dev |
| 16:13 |
RealBadAngel |
hi hmmmm, and what about your modifications to the minimap? |
| 16:13 |
hmmmm |
what? |
| 16:13 |
RealBadAngel |
you said youre gonna make a pull request with some changes... |
| 16:14 |
RealBadAngel |
so im waiting for it |
| 16:14 |
hmmmm |
oh yeah i was gonna but then est started messing around with those files so it'd cause a lot of merge conflicts |
| 16:14 |
hmmmm |
i just abandoned it |
| 16:15 |
RealBadAngel |
ok. so shall i fix issues there with lines >80 etc? |
| 16:16 |
hmmmm |
nah don't bother. it doesn't even matter. |
| 16:16 |
RealBadAngel |
ok, next time i will care bout it |
| 16:16 |
hmmmm |
nah it's okay |
| 16:17 |
hmmmm |
just write the code however you like. it's all a giant mess anyway. |
| 16:17 |
RealBadAngel |
mess or not, im lovin it ;) |
| 16:18 |
RealBadAngel |
btw, what do you think about adding normal textures to the game? |
| 16:18 |
|
est31 joined #minetest-dev |
| 16:19 |
hmmmm |
i don't know, it doesn't even matter to me anymore |
| 16:19 |
Calinou |
if they're done properly, yes |
| 16:19 |
Calinou |
if they're generated poorly, nope :P |
| 16:19 |
hmmmm |
you know what |
| 16:19 |
Calinou |
they need to make sense |
| 16:19 |
hmmmm |
i don't see any point for me to work on minetest any longer |
| 16:19 |
RealBadAngel |
lemme make a screenshot with a few i already made |
| 16:19 |
RealBadAngel |
hmmmm, what? |
| 16:19 |
hmmmm |
like celeron said, why bother develop something that you don't even use |
| 16:19 |
hmmmm |
bother to develop* |
| 16:19 |
Calinou |
most developers don't play their own games |
| 16:20 |
rubenwardy |
so true |
| 16:20 |
RealBadAngel |
developing is also a game, for your mind |
| 16:20 |
rubenwardy |
exactly |
| 16:20 |
est31 |
hmmmm, if there are problems with my code, just say which |
| 16:21 |
RealBadAngel |
no matter youre creating shack out of nodes or developing mapgen |
| 16:21 |
RealBadAngel |
youre creating something that is fun for you |
| 16:21 |
est31 |
^ |
| 16:22 |
est31 |
I've tried to answer most questions you asked last time when I wasnt online |
| 16:22 |
est31 |
but you werent online too |
| 16:22 |
est31 |
so now we both are. |
| 16:24 |
est31 |
if you have an idea how to design it better, just say so |
| 16:31 |
|
blaise joined #minetest-dev |
| 16:31 |
RealBadAngel |
Calinou, hand made maps are way better than autogenerated (in most cases). autogenaration fails for example with bricks, it cannot see the patterns or shapes |
| 16:31 |
RealBadAngel |
so my idea is to supply most controversial ones, for other textures autogen will do |
| 16:38 |
RealBadAngel |
https://imgrush.com/scfikhW-pAKR |
| 16:38 |
RealBadAngel |
what do you guys think about it? |
| 16:38 |
Calinou |
wow |
| 16:38 |
Calinou |
definitely better than Minecraft 2.0 |
| 16:38 |
est31 |
nice |
| 16:39 |
est31 |
it should perhaps be an option in settings |
| 16:39 |
RealBadAngel |
already is |
| 16:39 |
RealBadAngel |
thats relief mapping + bumpmapping |
| 16:39 |
est31 |
ok |
| 16:40 |
RealBadAngel |
Calinou, so, you think theyre properly done? :) |
| 16:43 |
est31 |
gtg again have to shut computer down to keep it cool |
| 16:44 |
Calinou |
they look OK |
| 16:44 |
|
proller joined #minetest-dev |
| 16:44 |
|
selat joined #minetest-dev |
| 16:46 |
RealBadAngel |
i will push today some small bugfixes to shaders (fish eye problem when lookin at texture from small distance, AMD Opengl 2.1 fixes, etc) |
| 16:46 |
RealBadAngel |
later on i will upload to git already made normals |
| 16:47 |
RealBadAngel |
so you can test them, screenshots doesnt show how it feels in game |
| 16:47 |
RealBadAngel |
you have to walk around |
| 16:50 |
RealBadAngel |
hmmmm, i hope you dont really wanna leave. take a break, have a few beers and come back to work :) |
| 16:50 |
hmmmm |
i've been flaking out for a while |
| 16:50 |
hmmmm |
i can see why people just stop showing up |
| 16:50 |
hmmmm |
problems keep coming up |
| 16:51 |
hmmmm |
just wanted to do some development, the build was broken on my machine, then when i fixed that there's a massive rendering regression, and then there's this general push toward trendy new features rather than ensuring quality |
| 16:52 |
hmmmm |
i don't know. i feel like i have different values than the rest of the team. |
| 16:52 |
hmmmm |
it's like there's a never ending stream of problems |
| 16:52 |
hmmmm |
remember when minetest was enjoyable to work on? |
| 16:53 |
RealBadAngel |
ofc, fun is not to catch the rabbit, but to keep running after it |
| 16:53 |
RealBadAngel |
it is still fun for me |
| 16:53 |
RealBadAngel |
im coding now stuff i planned ages ago |
| 16:54 |
Calinou |
<+hmmmm> remember when minetest was enjoyable to work on? |
| 16:54 |
hmmmm |
well, those are your own values. and your value is different from my values. i find it difficult to stay motivated chasing after some semblance of stability. i want to get things done, not chase a carrot on a stick |
| 16:54 |
Calinou |
it was monolithic |
| 16:54 |
RealBadAngel |
and polishing it, so theyre not just "new trendy features" |
| 16:55 |
RealBadAngel |
to get effects you can see on the screenshot, it took months to have all needed stuff rdy |
| 16:55 |
RealBadAngel |
all those new features are based on a hard work and basis i made |
| 16:57 |
RealBadAngel |
you could compare each new effect to your biome. mapgen is here, im just adding new biomes ;) |
| 16:59 |
Jasper |
crazyR_, haven't gotten time at work yet |
| 16:59 |
|
selat joined #minetest-dev |
| 17:01 |
|
proller joined #minetest-dev |
| 17:02 |
|
julienrat joined #minetest-dev |
| 17:05 |
|
selat_ joined #minetest-dev |
| 17:06 |
|
est31 joined #minetest-dev |
| 17:06 |
est31 |
adding iconv is no "trendy new feature" |
| 17:07 |
est31 |
its a neccessary addition for reliability |
| 17:07 |
est31 |
you can't communicate in your own wchar variant |
| 17:07 |
|
MinetestForFun joined #minetest-dev |
| 17:07 |
est31 |
the world isn't the US, we have to support other languages than english too. |
| 17:09 |
RealBadAngel |
anyway, project with no new features is a dead project |
| 17:10 |
RealBadAngel |
also, with new features come also solutions to old problems. minimap case - we have fixed mesh update lags |
| 17:10 |
hmmmm |
bullshit |
| 17:10 |
est31 |
have we? |
| 17:10 |
RealBadAngel |
est31, you have coded it |
| 17:11 |
est31 |
you mean the updatethread commit? |
| 17:11 |
RealBadAngel |
yes |
| 17:11 |
est31 |
that removed lag? cool |
| 17:11 |
est31 |
I had wanted something else originally |
| 17:11 |
est31 |
but nice side effect |
| 17:12 |
hmmmm |
mesh update lags are caused by the gpu driver - not by forcing a context switch |
| 17:12 |
hmmmm |
snake oil for you, a regression for everybody else |
| 17:13 |
RealBadAngel |
hmmmm, mesh update thread have no contact with GPU, its pure CPU dependent code |
| 17:13 |
hmmmm |
the main render/input thread now has to contend with an additional thread sucking up all cpu |
| 17:13 |
est31 |
hmmmm, so you say using a semaphore instead of while (no update) sleep_ms(3); is a bad thing? |
| 17:13 |
est31 |
nonono |
| 17:13 |
est31 |
I'm using a semaphore |
| 17:14 |
est31 |
https://github.com/minetest/minetest/commit/29dda9f356042c403b3b7da1d717d32b45c9b6de#diff-7f3a3ff3a2c9b903da668a4598f5f8bbR257 |
| 17:14 |
est31 |
thats where the thread waitsd |
| 17:14 |
est31 |
-d |
| 17:14 |
hmmmm |
RealBadAngel, new meshes must be uploaded to the GPU |
| 17:15 |
hmmmm |
est31: I can see that it blocks, but this has nothing to do with what I'm talking about |
| 17:15 |
RealBadAngel |
hmmmm, only if you want to use VBO |
| 17:15 |
RealBadAngel |
otherwise theyre stored in memory |
| 17:15 |
hmmmm |
and transferred to the GPU anyway on render |
| 17:15 |
RealBadAngel |
and when you do that, it raises performance dramatically |
| 17:15 |
est31 |
so whats the problem then hmmmm? |
| 17:16 |
hmmmm |
I have two separate people talking to me about two separate issues |
| 17:16 |
hmmmm |
at the same exact time |
| 17:16 |
RealBadAngel |
ok, im off for a couple of minutes ;) |
| 17:16 |
est31 |
lol |
| 17:17 |
RealBadAngel |
seriously, going shoppin, brb |
| 17:17 |
hmmmm |
est31: the problem is that the mesh generation queue is can remain oversaturated and never take a break |
| 17:17 |
hmmmm |
it would eat up all of its cpu time allocated to that quantum |
| 17:17 |
hmmmm |
and that thread has the same priority as does the rendering and input thread, which is latency sensitive |
| 17:17 |
est31 |
I see |
| 17:18 |
est31 |
so if its not run on a separate core |
| 17:18 |
hmmmm |
placing that sleep call there makes it so that it forces the scheduler to perform a context switch after each mesh generation |
| 17:18 |
est31 |
(eg with singlecore machines) |
| 17:18 |
hmmmm |
no, even if it is |
| 17:18 |
est31 |
then it clogs up |
| 17:18 |
hmmmm |
there are also many other processes running on that machine |
| 17:18 |
hmmmm |
it all has to do with scheduling latency |
| 17:19 |
hmmmm |
this wouldn't be as much of a problem if we were able to set the mesh generation thread to a background priority |
| 17:19 |
hmmmm |
but we can't, because linux's scheduler doesn't allow thread priority to be set without changing the scheduling policy to round robin |
| 17:20 |
hmmmm |
so inserting a sleep() has the same effect |
| 17:20 |
est31 |
but whats bad about a thread running at 100% CPU? |
| 17:20 |
est31 |
I mean if its on another core |
| 17:21 |
hmmmm |
because you don't understand the way SMP schedulers work :) |
| 17:21 |
est31 |
so what do you propose |
| 17:21 |
hmmmm |
maybe it's different on Windows, where 100% cpu-usage threads get automatically backgrounded |
| 17:22 |
hmmmm |
also UI tasks get a priority boost |
| 17:22 |
hmmmm |
I propose adding back the sleep() call |
| 17:23 |
hmmmm |
even sleep(0) works fine |
| 17:23 |
hmmmm |
maybe even pthread_yield() |
| 17:23 |
est31 |
only to the mesh thread, or to the minimap thread too? |
| 17:23 |
hmmmm |
both |
| 17:23 |
est31 |
ok |
| 17:23 |
hmmmm |
you don't have to bother |
| 17:23 |
hmmmm |
I am not telling you "this must be done" |
| 17:24 |
hmmmm |
when I added multithreaded emerge threads, it worked like crap |
| 17:24 |
hmmmm |
even with 2 threads instead of 1 |
| 17:24 |
hmmmm |
I wondered, why on earth does it add so much lag even though I have 8 cores? |
| 17:25 |
hmmmm |
the actual reason is honestly an OS-dependent answer |
| 17:27 |
hmmmm |
generally, what happens is that the rendering thread (always running) gets a chance to execute more often and at a guaranteed time when the number of running threads is minimal |
| 17:27 |
hmmmm |
there's no guarantee whatsoever that the rendering thread stays on a single core |
| 17:28 |
est31 |
is this a linux problem, or a freebsd problem? |
| 17:28 |
hmmmm |
both |
| 17:29 |
hmmmm |
this is a soft-real-time process, but in order to set the priority as such, you must be root |
| 17:29 |
est31 |
how does even scheduling influence tasks running on different CPUs? |
| 17:29 |
hmmmm |
there are plenty of other threads running at the same time from background tasks |
| 17:29 |
est31 |
I mean the scheduler sees "hey one thread with alot of things to do, and another with less to do" |
| 17:30 |
hmmmm |
those, plus your own applications' tasks, cause the latency |
| 17:30 |
est31 |
so it says "lets give the one with lot things to do their own CPU" |
| 17:30 |
hmmmm |
the scheduler does not see that at all |
| 17:30 |
hmmmm |
the scheduler can't predict what's happening in a thread |
| 17:31 |
est31 |
of course |
| 17:31 |
est31 |
its judging based on what happens |
| 17:31 |
hmmmm |
some specific implementations of schedulers can penalize certain threads for their past cpu usage |
| 17:31 |
|
Miner_48er joined #minetest-dev |
| 17:32 |
est31 |
hmmmm, I agree to you adding a sleep call, but I want to understand why, thats why I ask |
| 17:34 |
hmmmm |
you're attributing human reasoning to a completely opaque algorithm |
| 17:34 |
hmmmm |
maybe that is exactly the behavior that happens on your own OS |
| 17:35 |
est31 |
heh |
| 17:35 |
est31 |
so you want to address a problem that can occur when the thread is always busy? |
| 17:35 |
hmmmm |
maybe it's just my specific OS being poorly designed |
| 17:36 |
hmmmm |
right, yes |
| 17:36 |
hmmmm |
and the problem becomes more pronounced if you have more threads |
| 17:36 |
hmmmm |
even if the amount of threads is much less than the number of cores your system has |
| 17:36 |
hmmmm |
the problem here is a general choppiness |
| 17:37 |
est31 |
so when should the sleep be called? |
| 17:37 |
est31 |
on every iteration? |
| 17:37 |
hmmmm |
maybe like once every 10 iterations or something |
| 17:38 |
est31 |
you realize it wasnt there before? |
| 17:38 |
est31 |
before, the sleep (3) was only called if the queue was empty |
| 17:38 |
est31 |
https://github.com/minetest/minetest/commit/29dda9f356042c403b3b7da1d717d32b45c9b6de#diff-34f48ad91ac6c202ac60b0348ae90e30L182 |
| 17:40 |
hmmmm |
ahh okay that's good then |
| 17:44 |
est31 |
fine. |
| 17:45 |
est31 |
we can add a sleep call if you want though |
| 17:45 |
est31 |
e.g. sleep(0) on every 10 iterations. |
| 17:46 |
hmmmm |
maybe not |
| 17:46 |
hmmmm |
leave it the way it is |
| 17:46 |
hmmmm |
wonder how well it works on systems with a low number of ocres |
| 17:46 |
hmmmm |
so why did you decide to use semaphores? |
| 17:47 |
est31 |
instead of? |
| 17:47 |
hmmmm |
JEvent |
| 17:47 |
hmmmm |
actually |
| 17:47 |
est31 |
JEvent is basically a semaphore too |
| 17:48 |
est31 |
just it doesn't count down |
| 17:48 |
hmmmm |
JEvent shouldn't be using semaphores |
| 17:48 |
hmmmm |
sysv semaphores are too slow |
| 17:48 |
hmmmm |
yeah so why do you wait until all writers are done? |
| 17:49 |
hmmmm |
don't you realize this could starve the reader? |
| 17:50 |
est31 |
how do you mean that |
| 17:52 |
hmmmm |
what says that the semaphore will ever reach 0? |
| 17:52 |
hmmmm |
while one thread is writing another could start writing and then the first stops writing, and then a third starts writing, and so on |
| 17:53 |
hmmmm |
the writes could overlap in such a way where the condition that the value is 0 will never become true, and then the data will never get consumed |
| 17:53 |
est31 |
hrmm makes sense |
| 17:54 |
est31 |
the original meaning of that loop was to have the semaphore like a binary semaphore |
| 17:54 |
est31 |
only 1 and 0 |
| 17:54 |
hmmmm |
you should use the Event abstraction |
| 17:54 |
est31 |
so that people don't make mistakes implementing |
| 17:55 |
est31 |
the event abstraction is just a wrapper around the semaphore methods |
| 17:55 |
hmmmm |
yes, but it's an abstraction... |
| 17:55 |
|
troller joined #minetest-dev |
| 17:55 |
hmmmm |
i want to change Event to use futexes |
| 17:55 |
est31 |
and in fact its no binary abstraction |
| 17:55 |
hmmmm |
this way it'd be faster |
| 17:55 |
hmmmm |
right now it's quite slow |
| 17:56 |
est31 |
futex is just another mutex |
| 17:56 |
est31 |
and mutex isnt ready for this task at all |
| 17:56 |
hmmmm |
why not |
| 17:56 |
est31 |
what does it have: lock, unlock and wait for lock |
| 17:56 |
est31 |
err wait for unlock |
| 17:57 |
est31 |
also you have to do it all from the same thread |
| 17:57 |
hmmmm |
a binary semaphore is equivalent to a mutex |
| 17:57 |
est31 |
so you cant let thread A lock and thread b unlock |
| 17:57 |
hmmmm |
who says so |
| 17:57 |
est31 |
http://stackoverflow.com/a/86021 |
| 17:58 |
est31 |
ok that answer isnt helpful |
| 17:58 |
est31 |
http://stackoverflow.com/a/86021 |
| 17:58 |
|
err404 joined #minetest-dev |
| 18:00 |
hmmmm |
that answer talks about intentions |
| 18:00 |
hmmmm |
you're able to use a mutex just fine |
| 18:00 |
hmmmm |
i.e. in windows, using critical sections for event synchronization is well defined |
| 18:00 |
hmmmm |
the only problem is when using an api where the results of unlocking in a thread that doesn't own it is undefined |
| 18:01 |
est31 |
yes |
| 18:01 |
hmmmm |
there are lots of futex-based apis where the behavior is defined |
| 18:01 |
hmmmm |
i'm not necessarily saying that it needs to use pthread_mutex_lock |
| 18:02 |
est31 |
the event implementation has to become less shit, then I can use it |
| 18:03 |
est31 |
right now its wait() call is just a wrapper around a semaphore -- |
| 18:03 |
est31 |
so if you have two raise() calls then one wait call, it doesnt wait until the next raise() |
| 18:04 |
hmmmm |
how is that a bad thing |
| 18:04 |
hmmmm |
it works exactly like events do on windows |
| 18:05 |
est31 |
sorry |
| 18:05 |
est31 |
the problem is if you have two raise calls then two wait calls, the second one doesnt wait |
| 18:06 |
hmmmm |
how do you know the calls weren't staggered like: wait raise wait raise |
| 18:06 |
est31 |
here the behaviour is different |
| 18:06 |
est31 |
but thats not the point |
| 18:07 |
est31 |
but either way, feel free to use an event instead |
| 18:08 |
est31 |
and to remove the loop that empties the semaphore |
| 18:08 |
|
err404 left #minetest-dev |
| 18:08 |
est31 |
I gotta reboot |
| 18:11 |
hmmmm |
my point is that behavior doesn't really matter because you can't predict the timing, so no behavior should depend on the way it works |
| 18:23 |
RealBadAngel |
anything against #2864 ? |
| 18:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/2864 -- Shaders tweaks by RealBadAngel |
| 18:29 |
|
selat joined #minetest-dev |
| 18:39 |
|
selat joined #minetest-dev |
| 18:44 |
|
selat_ joined #minetest-dev |
| 18:50 |
|
proller joined #minetest-dev |
| 18:57 |
RealBadAngel |
anybody? |
| 18:58 |
|
est31 joined #minetest-dev |
| 18:59 |
|
proller joined #minetest-dev |
| 19:01 |
|
est31 joined #minetest-dev |
| 19:05 |
RealBadAngel |
est31, decide, in or out ;) |
| 19:05 |
est31 |
lol |
| 19:05 |
est31 |
had to switch computers |
| 19:05 |
est31 |
my main computer has fsck failure |
| 19:05 |
est31 |
damn ssd |
| 19:05 |
RealBadAngel |
please take a look at 2864 |
| 19:05 |
est31 |
(and heat) |
| 19:06 |
est31 |
I cant even merge PRs anymore |
| 19:06 |
RealBadAngel |
simple fixes and tweaks |
| 19:06 |
est31 |
will have to copy my ssh key |
| 19:06 |
est31 |
but at least my mail password is copied over, so can recover everything |
| 19:06 |
est31 |
lets hope my hdd survives this |
| 19:06 |
est31 |
strategy now: dont boot until it gets cold again |
| 19:07 |
est31 |
but I dont know could be mainboard problem too |
| 19:07 |
RealBadAngel |
put it into fridge ;) |
| 19:07 |
est31 |
this ssd is < 6 months old |
| 19:08 |
RealBadAngel |
when it gets hot outside i remove cover from my box |
| 19:08 |
RealBadAngel |
it helps a lot |
| 19:08 |
RealBadAngel |
im doing that since once i got fried gpu ;) |
| 19:09 |
est31 |
heh |
| 19:09 |
RealBadAngel |
so, anything against my pr? i would like to merge it now |
| 19:10 |
est31 |
im reading |
| 19:11 |
est31 |
looks good |
| 19:11 |
RealBadAngel |
im not expecting anybody understandin what it actually does, so just the look counts ;) |
| 19:12 |
RealBadAngel |
im creating now repo with normals for minetest_game default textures, would you like to try them? |
| 19:13 |
est31 |
yes I only saw shader |
| 19:13 |
est31 |
then I saw its mostly cleanp |
| 19:13 |
kilbith |
normalize(v) instead of normalize (v) |
| 19:13 |
RealBadAngel |
not rly, theyre a quite visible changes |
| 19:14 |
RealBadAngel |
i mean in-game, you should really try new textures |
| 19:14 |
est31 |
so normalmaps are also generated 12 blocks away?? |
| 19:14 |
RealBadAngel |
effect is imho amazing |
| 19:14 |
RealBadAngel |
heightmaps are generated in radius of 12 nodes |
| 19:14 |
RealBadAngel |
normalmap is generated everywhere |
| 19:15 |
RealBadAngel |
it changes the look of the texture thx to shadows, so it cannot be limited |
| 19:16 |
RealBadAngel |
tried to limit that too, but when flying around you can clearly see radius affected by bumpmapping |
| 19:17 |
|
selat joined #minetest-dev |
| 19:37 |
|
blaaaaargh joined #minetest-dev |
| 19:37 |
RealBadAngel |
ok, est31 build now with the patch and use this as texture pack: https://github.com/RealBadAngel/default_normals |
| 19:38 |
RealBadAngel |
Calinou, here? |
| 19:38 |
Calinou |
yes |
| 19:38 |
RealBadAngel |
will you try it? |
| 19:39 |
Calinou |
yes |
| 19:41 |
RealBadAngel |
ive made maps for just a few textures, i would like to know if general direction is ok so i can continue |
| 19:43 |
Calinou |
why is your default_normals a directory? |
| 19:44 |
Calinou |
you should commit your texture pack directly |
| 19:44 |
Calinou |
not in a subdirectory |
| 19:44 |
est31 |
^ |
| 19:45 |
RealBadAngel |
Calinou, good point, will fix it |
| 20:04 |
RealBadAngel |
so, how do you find them? |
| 20:07 |
Calinou |
they are OK |
| 20:07 |
Calinou |
isn't sand a bit intense? |
| 20:08 |
Calinou |
also why are they larger than 16x16? |
| 20:08 |
Calinou |
this makes them hard to maintain |
| 20:13 |
|
selat joined #minetest-dev |
| 20:16 |
RealBadAngel |
they have to be larger, 16x16 doesnt carry enough data for bumpmapping |
| 20:16 |
RealBadAngel |
autogenerating works on 512x512 |
| 20:17 |
RealBadAngel |
effectively |
| 20:17 |
RealBadAngel |
but anyway, what is the problem with them being larger? |
| 20:18 |
RealBadAngel |
about sand, would you like to make shadows softer? |
| 20:19 |
Calinou |
the shadows need to be less intense |
| 20:19 |
RealBadAngel |
ok, will try |
| 20:21 |
RealBadAngel |
btw, why meselamp have drawtype glasslike?? |
| 20:22 |
|
blaze joined #minetest-dev |
| 20:24 |
Calinou |
some texture packs might make it transparent? |
| 20:25 |
RealBadAngel |
it is not transparent, neither should be |
| 20:29 |
|
blaze joined #minetest-dev |
| 20:40 |
RealBadAngel |
Calinou, please try sand now |
| 20:40 |
RealBadAngel |
i kinda like it softer |
| 20:43 |
Calinou |
good now |
| 20:44 |
RealBadAngel |
huge areas of sand are lookin cool |
| 20:55 |
|
julienrat joined #minetest-dev |
| 21:47 |
|
Wayward_Tab joined #minetest-dev |
| 21:55 |
|
Wayward_Tab joined #minetest-dev |
| 22:02 |
|
Wayward__One joined #minetest-dev |
| 22:10 |
|
kaeza joined #minetest-dev |
| 22:12 |
|
zat joined #minetest-dev |
| 22:16 |
|
Wayward__One joined #minetest-dev |
| 22:37 |
|
troller joined #minetest-dev |
| 22:38 |
|
ShadowNinja joined #minetest-dev |
| 22:40 |
|
AnotherBrick joined #minetest-dev |
| 22:43 |
|
ShadowNinja joined #minetest-dev |
| 22:46 |
|
troller joined #minetest-dev |
| 22:57 |
est31 |
pushing in 5 minutes https://github.com/minetest/minetest/pull/2863 |
| 22:58 |
hmmmm |
who is the other +1? |
| 22:58 |
kilbith |
small patch |
| 23:06 |
|
troller joined #minetest-dev |
| 23:11 |
|
CraigyDavi joined #minetest-dev |
| 23:14 |
|
Wayward_One joined #minetest-dev |
| 23:16 |
hmmmm |
really? |
| 23:17 |
hmmmm |
it's honestly as if everybody but me is trying to skirt around the rules |
| 23:17 |
kilbith |
est31 is compliant with the rules here |
| 23:17 |
hmmmm |
if so many are doing this, i'm getting the feeling none like the rules |
| 23:17 |
hmmmm |
kilbith, he's compliant with the rules because it benefits you |
| 23:17 |
kilbith |
no, because it's the rules |
| 23:18 |
hmmmm |
anywhere there's a bit of a gray area you (plural) take the benefit of the doubt to push |
| 23:18 |
hmmmm |
push-trigger happy |
| 23:18 |
kilbith |
also don't put malice on my intentions please |
| 23:18 |
hmmmm |
kilbith, i'm not saying you have malicious intentions |
| 23:18 |
hmmmm |
what i am saying is that you're all too push happy |
| 23:18 |
hmmmm |
do you not like the rules as they're made? |
| 23:18 |
|
est31 joined #minetest-dev |
| 23:18 |
hmmmm |
because we can change them |
| 23:19 |
hmmmm |
i want people to be honest about their feelings here |
| 23:19 |
kilbith |
small correction : it don't benefits me, but the engine |
| 23:19 |
hmmmm |
.. |
| 23:19 |
kilbith |
i don't care at all of the fame |
| 23:19 |
hmmmm |
look |
| 23:19 |
kilbith |
and it's Lua trivial fix so |
| 23:19 |
hmmmm |
it's getting more and more obvious that the rest of you do not share the same values and philosophies as i do about development |
| 23:20 |
hmmmm |
maybe this could be a reason why most good devs tend to stop contributing |
| 23:21 |
kilbith |
i follow silently the devel for 2 years now, never saw you or very rarely trying to grab another +1 |
| 23:21 |
kilbith |
even when those commits contained nasty bugs |
| 23:21 |
RealBadAngel |
hmmmm, for small fixes we dont need strict 2 votes rules |
| 23:21 |
RealBadAngel |
and you know that |
| 23:22 |
hmmmm |
the word "small" is totally subjective |
| 23:22 |
hmmmm |
and you know that |
| 23:22 |
hmmmm |
you're touting it around as if it were fact |
| 23:22 |
hmmmm |
kilbith, like what? |
| 23:22 |
kilbith |
noise params for example |
| 23:22 |
hmmmm |
noise params were never flawed |
| 23:22 |
kilbith |
(for the bugs) |
| 23:23 |
kilbith |
they were reset at each world's joining |
| 23:23 |
kilbith |
but i said nothing since you fixes quickly your bugs |
| 23:23 |
hmmmm |
and they are never trivial to begin with |
| 23:23 |
hmmmm |
when i look for a review, i want an actual review too |
| 23:24 |
hmmmm |
not some cursory, superficial scan |
| 23:24 |
hmmmm |
the majority of you will say "looks good to me" when something contains blatant memory leaks |
| 23:25 |
hmmmm |
maybe i'd be more happy about all this if people had committments to fixing their bugs |
| 23:25 |
est31 |
the PR I merged was actually a bugfix after kilbiths commit |
| 23:26 |
est31 |
https://github.com/minetest/minetest/commit/85f3d575ec3d99ef2ce680d4a2546e4d31327d83 |
| 23:26 |
est31 |
and that hang around for months |
| 23:26 |
est31 |
literally |
| 23:26 |
kilbith |
fz72's shit and never came back for fixing it |
| 23:27 |
est31 |
#2586 |
| 23:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/2586 -- Fix some bugs in mainmenu tab_singleplayer and tab_server by fz72 |
| 23:27 |
hmmmm |
how about some testing before commits |
| 23:27 |
hmmmm |
why don't people ever do that? |
| 23:29 |
est31 |
isnt it the same way in professional world too? the devs break the tree (and test for the big issues), and the software testers run the newest tree and report back regressions |
| 23:29 |
RealBadAngel |
hmmmm, how many times asked you to test something? "nah, screenshot is enough" |
| 23:30 |
hmmmm |
no, the person committing it should be the one to test |
| 23:30 |
hmmmm |
you just want me to look at your neato graphical effects |
| 23:31 |
RealBadAngel |
not always, sometimes i do need to test pr on various platforms |
| 23:31 |
hmmmm |
est31: QA is supposed to be the last stop |
| 23:32 |
hmmmm |
like for example, how did the rendering regression happen? |
| 23:32 |
hmmmm |
how did nobody notice that |
| 23:32 |
hmmmm |
it blows my mind |
| 23:32 |
est31 |
which "rendering regression" |
| 23:32 |
hmmmm |
the one that's afflicting master right now |
| 23:32 |
est31 |
calm down and talk about the issue |
| 23:32 |
hmmmm |
i have a freaking GTX660 and I get 15 FPS staring into a wall |
| 23:33 |
hmmmm |
i'm almost embarassed to have my name associated with minetest to be frank |
| 23:34 |
hmmmm |
people see that i contribute to it, download it and try it out, and it's a buggy, laggy piece of crap |
| 23:34 |
est31 |
building right now and trying to download |
| 23:34 |
hmmmm |
and how does that reflect on me |
| 23:34 |
RealBadAngel |
i have also an nvidia and i do get 60fps at distance 245, all special effects enabled, so hmmm i suggest checkin your drivers |
| 23:35 |
hmmmm |
in fact it's been like this all the time |
| 23:35 |
hmmmm |
every time I take a break from minetest for a couple months then come back, there are major bugs or regressions that were just left go |
| 23:35 |
hmmmm |
wtf? |
| 23:36 |
RealBadAngel |
when i remove cap and enable vbo i could get way more |
| 23:36 |
RealBadAngel |
what drivers do you actually use? |
| 23:37 |
est31 |
I get 40-60 FPS |
| 23:38 |
est31 |
hmmmm, you commited commits which broke builds on non freebsd too. |
| 23:38 |
hmmmm |
and they get fixed 5 minutes after |
| 23:38 |
est31 |
perhaps the issue is as you said a scheduling problem |
| 23:38 |
RealBadAngel |
hmmmm, so? what drivers? |
| 23:38 |
hmmmm |
RealBadAngel, it's obviously not a driver problem. |
| 23:39 |
hmmmm |
i am using the same exact drivers with the same exact settings as before the regression |
| 23:39 |
hmmmm |
in any case, i'm gonna have to fix this one too |
| 23:39 |
RealBadAngel |
open source or propertiary?? |
| 23:39 |
est31 |
so, bisect it |
| 23:39 |
est31 |
RealBadAngel, not everything is a driver problem |
| 23:39 |
RealBadAngel |
indeed, but that also can be a reason |
| 23:40 |
RealBadAngel |
on my box open propertiary are like 4 times faster |
| 23:45 |
RealBadAngel |
but seriously, if we want to find a reson for your regression, you really should bisect it. |
| 23:45 |
RealBadAngel |
idk why youre experiencing slowdowns while others enjoy faster and smoother game |
| 23:47 |
hmmmm |
it seems as though toggling between full viewing range has no effect |
| 23:47 |
hmmmm |
are blocks still being drawn outside of the view radius? |
| 23:48 |
RealBadAngel |
rather not, theres even a glitch i noticed lately |
| 23:48 |
est31 |
I've seen bugs about occlusion culling so it seems to be enabled |
| 23:48 |
est31 |
and implemented |
| 23:48 |
RealBadAngel |
when flying and rotating, some blocks in the corners dissapear |
| 23:48 |
RealBadAngel |
very rare to spot but means above |
| 23:55 |
hmmmm |
yup there's definitely a regression |
| 23:55 |
hmmmm |
FPS dropped in the same scene from 25 to 13 |
| 23:55 |
est31 |
ok |
| 23:56 |
est31 |
I usually do a bisect in these cases |
| 23:56 |
hmmmm |
began bisecting at 502e40a649137461947c36ea52205f058f81296f - which is good |
| 23:57 |
hmmmm |
really, this happens to nobody else? |
| 23:58 |
RealBadAngel |
whats that commit? |
