00:32tuxillo: just tried kubuntu with nouveau
00:32tuxillo: KDE works beautifully
00:43gnarface: good to know
00:44gnarface: make sure fan speed AND power are in lowest threshold
00:44gnarface: most the cards should be stuck that way
00:44gnarface: i don't know off the top of my head which ones are not
00:45gnarface: there are rare cases (i think mostly just with older cards but again, not sure) where they can be stuck in highest power mode instead, but the fan still be stuck in powersaving mode (which will cook the card eventually)
00:45gnarface: so, unlikely afaik but something worth double-checking since that seems like it was not a cheap card
00:46gnarface: (there are people in this channel who know off the top of their heads whether that particular card is at risk or not, but i am not one)
00:47gnarface: i think the settings are exposed in /sys/ somewhere
00:58HdkR: gnarface: It's Pascal, it'll be locked at lowest
00:58HdkR: It isn't a fermi
00:59gnarface: noted HdkR, thanks.
08:13tuxillo: besides fan/temp
08:13tuxillo: is it really possible to fry your gpu with nouveau?
08:16gnarface: tuxillo: afaik, other than that, no
08:20tuxillo: the thing is that I don't even run linux, I run a BSD. but this BSD has imported a lot of linux code for the graphics
08:20tuxillo: currently i915/radeon kind of works
08:21tuxillo: and I was thinking if it would be possible to port nouveau
08:21tuxillo: you can already see the mess :P
08:35mupuf: tuxillo: even without fan/temp, it should still not be possible to fry the GPU because there is automatic downclocking on overheating
08:35mupuf: this is assuming the driver does not mess this thing up
08:36tuxillo: hmm ok
08:37tuxillo: i guess the first part would be making sure the clock is at minimal
08:41tuxillo: seems Volta was upstreamed in 4.19
08:49mupuf: tuxillo: I would not worry about the boot clocks
10:57tuxillo: mupuf: i would like to not fry the card in the porting process
11:17kherbst: you can't change the voltage/clocks anyway
11:18kherbst: and what "porting process" are you refering to?
11:18tuxillo: linux -> bsd
11:37mupuf: tuxillo: Seriously, I'll pay you a new GPU if you fry it unintentionally. It requires skills to break a gpu!
11:37mupuf: nowadays, you can't get rid of the safety features even as root
11:38kherbst: mupuf: although nobody actually verified that, right?
11:38kherbst: but it would make sense if it would be that way
11:39mupuf: kherbst: IIRC, we did verify it
11:39tuxillo: mupuf: i'll take your word for it!
11:39mupuf:once overclocked from 450MHz to 3 GHz his nv86
11:39mupuf: glxgears was still happy :D
11:40mupuf: of course, anything more just crashed
12:52doobz: Hi. I'm trying to build the latest mesa for nouveau on debian buster. It's asking for a later version of libdrm_intel and I wonder whether this is necessary for my nvidia gpu? I gather the "meson build/" command can be issued with certain parameters such that I don't need to meet any unrequired dependencies.
12:53orbea: doobz: if you are not using intel at all you can build mesa without intel support or just upgrade libdrm
12:57doobz: cpu is intel, not sure if that makes a difference here. Package does appear to be on system (though could have arrived after install).
13:04orbea: i cant say how much the gpu component of your intel cpu is being used or not, but if nouveau is driving everything the mesa part is not needed for intel. That said depending on your CPU/GPU intel could be a better supported choice than nouveau.
13:16doobz: CPU is T7200 - no graphical stuff inside AFAIK.
13:17kherbst: doobz: you can disable drivers you don't need
13:19doobz: Found this but not sure if it's exactly suited to my situation
13:19doobz: meson --prefix=$XORG_PREFIX \
13:19doobz: -Dbuildtype=release \
13:19doobz: -Ddri-drivers=$DRI_DRIVERS \
13:19doobz: -Dgallium-drivers=$GALLIUM_DRV \
13:19doobz: -Dgallium-nine=false \
13:19doobz: -Dglx=dri \
13:19doobz: -Dosmesa=gallium \
13:19doobz: -Dvalgrind=false \
13:20orbea: please use a paste site for anythingmore than 2 lines
13:20orbea: see meson_options.txt inside the source tree for support options
13:21imirkin: tuxillo: which bsd?
13:21orbea: also 'meson configure' might show all the options depending on the meson version
13:25orbea:sighs at how slow 'meson configure' is to './configure --help'
13:26orbea: at least it still works
13:28doobz: I did look at meson_options.txt before. And I don't think I'm allowed to see the options with meson until it's sucessfully run once.
13:28imirkin: yeah it's really annoying
13:28imirkin: you need to add -Dvulkan-drivers=
13:29orbea: with meson it was broken and fixed several times with mesa
13:29orbea: still works here with the mesa master and a recent meson git version
13:31doobz: I guess updating the lib should be easier, but not had much luck in that respect either. Updating packages into debian is a bit hit&miss. Spose I could see about getting it compiled from source. Only worry is that there are many more dependecies like this I'm unaware of at this moment in time.
13:32orbea: 'meson configure' uses about 5x the system calls as './configure --help' *sigh*
13:34doobz: I'd never heard of it before today.. ;)
13:34orbea: 15x the system calls with dash instead of bash lol
13:35kherbst: orbea: more aggressive caching
13:35kherbst: there is a reason ninja is way faster than make
13:35orbea:uses samurai :)
13:35orbea: but this has nothing to do with ninja/make, it only prints configure options
13:36kherbst: configure --help just calls a bash function
13:36kherbst: meson configure actually reads the state
13:36kherbst: but yeah.. it's also python
13:36kherbst: it's just how it is
13:42doobz: :imirkin Was the Dvulkan-drivers aimed at me?
14:09imirkin_: doobz: yes
14:09imirkin_: kherbst: it's how it was made to be.
14:09imirkin_: it was perfectly fine with autoconf.
14:14imirkin_: doobz: also it's -Dvulkan-drivers=
14:14kherbst: autoconf has/had to go. There isn't anything "good" about autoconf itself, if looking at what's actually important. It was just used as every distribution supported it and hadn't a questionable development process.
14:14imirkin_: kherbst: what's good is that it works, handles cross-compile, and everyone knows how to use it
14:15kherbst: meson also handles cross-compile, just in a different way
14:15imirkin_: right, just in a way that requires 100x more work
14:15kherbst: "everyone knows it" is a silly argument, as this can always change. Meson seems to make new promises, people like it. At some point meson will be better known than autoconf
14:15imirkin_: hopefully not.
14:15kherbst: hopefully yes
14:15kherbst: autoconf is annoying
14:15kherbst: the syntax
14:16imirkin_: you're thinking as the developer
14:16kherbst: I'd agree to something like autoconf, if the syntax wouldn't be that terrible
14:16imirkin_: i'm thinking as the user.
14:16imirkin_: for the user, meson is horrid
14:16kherbst: as the user it doesn't matter. The command line interfaces are comparable
14:16imirkin_: except for the most important things
14:16imirkin_: like getting --help to be reasonable
14:16kherbst: and why isn't it in meson?
14:17imirkin_: don't know
14:17kherbst: I mean, what's bad about "meson configure"?
14:17imirkin_: and frankly, i've given up asking. everyone hated on me pretty good about it, so i've basically unsubscribed.
14:17imirkin_: kherbst: it doesn't work
14:17imirkin_: other than that, it's fantastic
14:17kherbst: why doesn't it work?
14:17imirkin_: try it.
14:17kherbst: ohh, you mean prior configureing
14:18imirkin_: there is no single reliable thing you can provide
14:18imirkin_: nothing Just Works (tm)
14:18imirkin_: autoconf Just Works (tm)
14:18orbea: i liked autoconf when written well
14:18kherbst: I guess there could be parser added to meson to parse the meson_options.txt file before a build directory is created
14:18imirkin_: sure, the developer can always screw things up pretty good
14:19orbea: yep, there are some pretty glaring examples of that out there, mesa was not one of them
14:19imirkin_: kherbst: that'll add yet-another way of doing things
14:19imirkin_: meson needs fewer things, not more things
14:19imirkin_: i never know when i need to run configure vs not
14:20kherbst: right... but that's stuff that can change.. and I think the configure point was addressed already
14:20imirkin_: anything can change
14:20imirkin_: i'm talking about things as they are.
14:20kherbst: ohh actually
14:20kherbst: meson configure . works
14:20orbea: heh,w as about to say
14:20orbea: just its much slower than ./configure --help as I noticed earilier
14:20kherbst: ohh, sure
14:20kherbst: because it's not just bash
14:21imirkin_: why "."?
14:21kherbst: orbea: but configure has to be generated as well
14:21kherbst: imirkin_: path to project.. but I guess you can omit it if it's already .
14:21kherbst: can be omited
14:21imirkin_: what if i want to set up a build
14:21imirkin_: can i just use configure always?
14:21imirkin_: instead of worrying about whether it's been configured before or not?
14:22kherbst: meson/ninja is faster for a reason
14:22kherbst: and having a bigger state is one of them
14:22imirkin_: same speed for me =/
14:22imirkin_: (or at least, not noticeably faster)
14:22kherbst: I saw 2x speedups
14:22imirkin_: most of my compilation time is in gcc/ld, not in ... whatever else
14:23imirkin_: and those obviously don't go faster
14:23kherbst: it looks like it
14:23kherbst: but make has a quite big overhead
14:23kherbst: especially if you do partial recompiles
14:23kherbst: if only 5 files changed
14:23kherbst: ninja is significantly faster
14:23imirkin_: i can say from personal experience -- it's about the same.
14:23orbea: i think most of the improvements in meson are actually ninja/samu in comparrison to gmake
14:24kherbst: orbea: probably yes
14:24imirkin_: i did partial recompiles a lot.
14:24orbea: the python part of meson is kind of a regression imo
14:24kherbst: imirkin_: I argue your system is weird then
14:24kherbst: ninja without changed files is < 0.1s here
14:25kherbst: make... needs >1s
14:25kherbst: make was always slow
14:25kherbst: and is the reason ninja existed in the first place
14:25imirkin_: it takes about 15-30s either way.
14:26kherbst: it was slow enough, so that it made a significant difference for building chromium
14:26kherbst: imirkin_: then your system is broken, sorry
14:26imirkin_: i like these explanations
14:26kherbst: no idea _why_ it needs 15 second
14:26kherbst: but that sounds horribly wrong
14:26kherbst: for me it's 0.1s
14:26imirkin_: coz linking is slow
14:26kherbst: ohh, if a file changed
14:26imirkin_: no matter how much you partially recompile
14:26imirkin_: you'll have to relink
14:27kherbst: I get 5s
14:27kherbst: with ninja
14:27imirkin_:has a i7-920
14:27imirkin_: with 6, count them -- 6 -- gigs of ram
14:27kherbst: uff :D
14:27imirkin_: wave of the future, right?
14:27kherbst: i7-7700HQ with 32GB ....
14:28kherbst: so yeah.. maybe your cpu is just slow
14:28kherbst: ssd or hdd?
14:28imirkin_: i try to ensure my builds are on ssd
14:28imirkin_: it's fairly aged though
14:28kherbst: yeah.. I have a mq attached ssd here
14:28kherbst: aka nvme
14:28imirkin_: i got this system in ... 2010?
14:28kherbst: and that also makes a huge difference
14:29kherbst: imirkin_: anyway, when I was doing tests, I saw that ninja is still significantly faster, but maybe on your system it's indeed not
14:29imirkin_: for all i know it's faster. just not noticeable.
14:29kherbst: ohh, right
14:30kherbst: if you need 4 or 6 minutes to compile it doesn't matter as much
14:30imirkin_: instead of 30s it's maybe 29s. who cares.
14:30imirkin_: and my complaint isn't about ninja
14:30imirkin_: it's about meson
14:31kherbst: the main reasons is still that autoconfs syntax is kind of annoying
14:31kherbst: and it doesn't had this higher level features cmake always had
14:32imirkin_: i'm talking as the user.
14:32imirkin_: not as the developer who has to make the build system work
14:33kherbst: actually, as a user I found autoconf to be more annoying in the end
14:33kherbst: most projects had this autogen.sh file which always did something else
14:33kherbst: do I have to specify NONCONFIGURE=1 or not?
14:33imirkin_: it should ship with the configure file
14:33kherbst: only for realses, on many cases
14:33kherbst: but what if I checkout from git
14:33imirkin_: then you're a developer and can check the first few lines of autogen.sh
14:34kherbst: not necesarily
14:34kherbst: what if I am a user git bisecting?
14:34kherbst: or tried out master for whatever reason?
14:34imirkin_: then you get instructions from a developer
14:35kherbst: (there are enough repositories out there just shipping whatever git commit)
14:35orbea: as a user my first instinct is 'autoreconf -fi'
14:35imirkin_: well that's crap too
14:35orbea: that worked with mesa fwiw
14:35kherbst: but people do this
14:35kherbst: and people use it
14:35imirkin_: can't stop people from doing stuff
14:35imirkin_: but you can have a The Supported Way (tm)
14:36kherbst: what I just try to say is, that autoconf also has weird issues, and in the past I had more issues with autoconf projects and weird autoconf issues then I had with meson.. but that's maybe just because meson is quite new
14:36kherbst: and I dealt with projects like wine
14:36orbea: i've never seen ./configure --help fail, there are been several cases where it just broke in mesa with 'meson configure'
14:36kherbst: meson is mainly just different. And some decisions might be significantly different, so it feels "wrong", but in the end, it's just different
14:37kherbst: orbea: sounds like something happend in the early days probably
14:37orbea: last one was the previous release
14:37kherbst: but yeah, meson is still relatilvy new
14:37kherbst: orbea: ohh, weird
14:37kherbst: I know that meson configure can get confused if you jump too many commits at once
14:38orbea: it was some bad backport iirc, or maybe that was for another project?
14:38kherbst: but that's mianly because some config options changed
14:38kherbst: I know there is a weird issue with the shader-cache
14:38kherbst: and at some point meson fails to detect the correct value or something
14:40orbea: i dont really dislike meson, i just feel like everyone took their working and well tested build systems and jumped ship to something that is not really finished yet with lots of room for regressions and bugs
14:40orbea: and ofc the projects that are using autotools so badly its a problem are still doing that
14:40kherbst: yeah, I think that's true
14:41kherbst: on the other hand, you don't know if your ideas work if nobody uses it