02:08 snkcld: nyef`: ahh, ok, that makes sense. but the initial bootstrapping of the pci devices occurs via IO ports right? im kinda confused... feels kinda chicken-and-the-egg type of thing. how does the kernel know the memory ranges for each device?
02:12 nyef`: snkcld: According to the mmiotrace documentation, it hooks the operation that maps the mmio space into the cpu address space.
02:14 nyef`: Initial bootstrapping is defined by the PCI spec in terms of bus transactions, which are implemented by the host bus interface. The host bus adaptor may *also* end up using mmio rather than the I/O address space.
02:14 nyef`: And don't forget that not all CPU types even *have* a separate I/O address space.
02:15 nyef`: (In fact, a separate I/O address space at the CPU level seems to be a familial quirk of the descendants of the 8080, possibly going as far back as the 4004.)
03:59 imirkin: w00t. int64 works, on SM35 at least - [1154/1154] pass: 1154
04:13 nyef`: imirkin: Congratulations.
04:17 nyef`: Compiler hacking can be intellectually rewarding, but *wow* can it be a stressful mess.
04:17 imirkin: hacking SM50 now, and SM20/30 will come last.
04:17 imirkin: [since i don't have one plugged in]
04:18 imirkin: meh. at this point i have a very good view of the compiler, so it's pretty straightforward to do things
04:19 nyef`: I'm hacking on a compiler that's more than 20 years old now, and has had some... interesting maintenance decisions made over the years.
04:19 nyef`: Plus I'm fairly sure that *nobody* knows how and why parts of it really work.
04:19 mooch: tbh i have no idea how compilers work lmao
04:20 mooch: except emulator dynarecs
04:22 imirkin: nyef`: well, the nouveau compiler is pretty straightforward
04:23 imirkin: there are, of course parts, which are incomprehensible. but overall it's quite reasonable.
04:23 nyef`: Mmm. Emulator dynarecs can get pretty gnarly, but they're usually straightforward translators without crazy optimizers.
04:24 nyef`: imirkin: I got lost about the first time I saw a virtual method in that compiler. Is there an overview document somewhere?
04:25 imirkin: nyef`: sadly no.
04:25 imirkin: there are almost no virtual methods there
04:26 nyef`: Maybe it was a template, then?
04:26 nyef`: Some C++ism.
04:26 imirkin: well, it *is* written in C++
04:26 imirkin: but nothing crazy
04:26 nyef`: As far as I'm concerned, writing in C++ *is* crazy. d-:
04:29 imirkin: hehe fair enough
04:30 nyef`: mooch: A typical emulator dynarec corresponds with the code generator portion of a compiler, so you have a starting point there if you're interested.
04:32 nyef`: Actually, what's the input format to the nouveau compiler like? Is it already pre-cooked to some degree?
04:35 imirkin: TGSI
04:36 imirkin: which is basically a fake-o ISA that was originally modeled around DX10
04:36 imirkin: all the glsl/etc stuff happens in mesa core
04:36 nyef`: So... an emulator dynarec!
04:36 imirkin: well, it's a full optimizing compiler...
04:37 nyef`: Sure, but you don't really have to deal with two full syntax-directed parsing passes to get to a linear list of instructions, do you?
04:42 imirkin: no parsing.
04:49 nyef`: I guess that also means that your optimization opportunities are limited by the TGSI format and the glsl and whatnot in mesa core?
04:52 imirkin: not really? not entirely sure what you mean
04:52 imirkin: there's not a ton of information loss from the original glsl to the tgsi
04:52 imirkin: a bit here and there, but nothing worth worrying about
04:52 nyef`: Okay, I guess that's fair, then.
04:53 imirkin: gpu programs tend to be a bit different than cpu too, so there are different challenges.
04:54 nyef`: That I can believe.
04:54 nyef`: Less stack allocated data on the GPU, for one. (-:
04:55 imirkin: right, so stack is kind of a big no-no
04:56 imirkin: it's basically non-existent
04:56 imirkin: hakzsam: i'm having to add NV50_PROG_SCHED=0 for int64 things to pass =/
04:56 imirkin: hakzsam: i think that your condition code handling logic might be off
04:56 imirkin: int64 adds a bunch of those.
04:59 nyef`: I'm currently trying to sort out some problems with stack-allocated data in the compiler I've been hacking on. The last person to maintain this part of the compiler did a decent job with respect to the observable semantics, for the most part, but he really didn't understand how the compiler dealt with on-stack values.
04:59 imirkin: "poorly"? :)
05:00 nyef`: (Full props to him for evolving the functionality as far as he did, and nailing the semantics, though.)
05:01 nyef`: Yes, "poorly", at least at the time, but that was because he didn't understand it and thus couldn't fix it.
05:05 imirkin: gr. we don't have shf.r/shf.l documented for nvc0 :(
05:05 imirkin: time to go hunting.
05:11 imirkin: GAH! the ops just plain don't exist!
05:11 nyef`: Shift right / shift left?
05:12 imirkin: 64-bit shift
05:12 nyef`: The left shift should be easy enough, at least.
05:12 nyef`: For a bit at a time.
05:12 imirkin: this is how they end up doing it: https://hastebin.com/ojazarijex.css
05:12 imirkin: gr.
05:13 imirkin: [for a shl]
05:14 nyef`: Not familiar enough with the ISA to be able to interpret that. /-:
05:14 imirkin: pretty self-explanatory ISA...
05:14 imirkin: SHL = SHL. SHR = SHR :)
05:15 imirkin: ISETP = set a predicate based on an integer compare
05:15 nyef`: Ooh. Predication registers?
05:15 nyef`: Predicated code was fun to work with on ARM.
05:15 imirkin: yeah. and then you see the @!P0 thing means that the execution is predicated on P0 being false
05:16 nyef`: That much I caught once you mentioned predication.
05:17 imirkin: [that's output from nvdisasm from a simple thing compiled with ptxas that has the 64-bit shift]
05:19 nyef`: I'm getting something from that, but not enough to be able to understand precisely what it's doing.
05:19 imirkin: input is in R2:R3 (64-bit value), shift is R0
05:20 nyef`: Then again, it's also late, and I have a completely different compiler on my brain.
05:20 imirkin: result is in R6:R7
05:20 nyef`: Ah, paired 32-bit registers?
05:20 imirkin: well, each reg is 32-bit
05:20 imirkin: the 64-bit value is logically stored into 2 regs. for this code, no fundamental reason they have to be adjacent.
05:21 imirkin: for ops that consumer 64-bit args directly, they have to be adjacent
05:21 nyef`: So, it's like the MIPS III era FPU?
05:21 imirkin: not familiar with that. but sounds like it.
05:22 nyef`: (As opposed to MIPS IV, where they had a compatibility mode, but there was another mode that gave you full-width registers instead of having them paired.)
05:22 imirkin: anyways, i'm off. i'll work this stuff out tomorrow. int64 is getting pretty close though.
05:22 nyef`: Have a good evening. (-:
05:26 nyef`: ... Okay, now I get the gist of that code fragment. Clever predication, pipeline consideration, and so on.
06:29 mystified: Can anyone help with gpu issues on alpine linux (openrc) Nvidia G210 ( nouveau) driver config
06:30 nyef`: If you're asking for distro-specific help, you might have better luck asking a distro-specific channel.
06:32 mystified: Ive been there no ones around
06:32 mystified: just in principle not distro specific
06:33 nyef`: I don't think that anyone's around here, either.
06:33 mystified: If I provide a pastebin link & look at my xorglog & give me your thoughts.
06:33 mystified: I'm not a techie
06:34 mystified: http://pastebin.com/4GGG3Hx3
06:37 nyef`: ... "nomodeset"? The old NV driver? And something about "wfbScreenInit: symbol not found" while trying to load nouveau_drv.so?
06:39 mystified: so i need to remove nv
06:39 nyef`: Modern nouveau, AIUI, requires KMS. You're unlikely to get much help here for a non-KMS config. The wfbScreenInit bit suggests that you have something missing or something out-of-date in terms of shared libraries.
06:40 mystified: thx
06:40 mystified: so purge Nv first & maybe reinstall nouveau
06:41 mystified: I do have herecopy of my rc.conf of Manjaro
06:41 nyef`: Probably, yeah. Or install the nvidia binary driver.
06:41 nyef`: ... except that that probably doesn't work for a GeForce 210.
06:42 mystified: It's not provided in the pkgs provided by alpine
06:42 mystified: I was thinking of usin arch or pkgs
06:42 nyef`: And at this point I can't really do much more than wish you luck.
06:42 mystified: But son't know how to build arch pkgs
06:50 mystified: Thx :)
11:43 beep-eep: Hi there, after compiling my kernel (drm-next), I am occasionally getting unrecoverable hangs. My card is a GTX 760 (NVE4). I don't actually know if it is a problem with nouveau since I get no useful output (dmesg/journalctl). The hang is not a crash since I don't get any vmcores with kdump. I've tried pinging the computer when this happens and I get no response. Can anyone give me some idea of how I can go
11:43 beep-eep: about debugging this problem? Note: this often seems to happen while playing video content.
11:44 beep-eep: I also tried netconsole, however I don't think it works due to different interface names wlp3s0 > wlan0. Should I try picking up a serial cable and debugging with that?
11:47 beep-eep: I also forgot to mention that the Magic SysRq key does not work either so I cannot initiate a crash.
13:19 hakzsam: imirkin_: not surprising
13:20 hakzsam: 64-bit operations are fairly untested and most of them require dep bars
13:20 hakzsam: probably a missing barrier somewhere
13:20 hakzsam: I could have a look if you want
14:56 OUTBURST: how's the state of vulkan support?
14:56 OUTBURST: something tells me that radeon is ahead.
14:58 RSpliet: OUTBURST: as far as OSS goes radeon is ahead indeed, on account of actually having an implementation
14:58 RSpliet: NVIDIA does a fine closed source Vulkan implementation though
14:59 OUTBURST: nooo!!
14:59 OUTBURST: close source vulkan??
14:59 OUTBURST: I thought vulkan was open sauce!!
15:05 imirkin: hakzsam: i just pushed a "int64" branch. a sample test that fails on maxwell with your sched logic is generated_tests/spec/arb_gpu_shader_int64/execution/built-in-functions/fs-max-int64_t-int64_t.shader_test
15:16 hakzsam: imirkin: only one fail?
16:14 RSpliet: OUTBURST: the specification is open, closed source drivers are free to implement
16:14 RSpliet: like OpenGL
16:15 RSpliet: (well, a few patented faffy texture formats excempt)
16:23 enyc: hrrm been a while since tried to sort nouveau on this box vith Quadro NVS 450
16:24 enyc: I think I'm only seeing one of the 2 GPUs on this card, and only seeing one of the 3 monitors therefore
16:33 enyc:wonders if update to kernel 4.9 was a good move =)
16:36 headless: hello all!
16:36 headless: how do I read the X server log?
16:36 RSpliet: headless: you should ask your distribution for that
16:37 enyc: headless: /var/log/Xorg.0.log on debian likes but depends
16:37 imirkin: hakzsam: no, a ton i think. i just picked a fairly simple one to debug.
16:38 imirkin: enyc: should work... what's the issue?
16:38 imirkin: enyc: to rephrase, please pastebin dmesg and xorg log
16:38 headless: enyc: TY!
16:44 OUTBURST: oh I see, so each driver has to implement vulkan idependently just like opengl?
16:44 enyc: imirkin: cant get nouveau seeing both gpus in xrandr or xorg log etc.... tried 3.16 kernel and 4.9
16:44 enyc: imirkin: will boot new 4.9 and past logs
16:44 enyc: imirkin: with no xorg.conf
16:45 imirkin: enyc: depending on your desktop environment, that's expected
16:45 enyc: imirkin: how do you normally enable the extra gpu?
16:45 imirkin: enyc: but i'd like to see dmesg and xorg log first
16:49 enyc: imirkin: one of the sets of configs is in (IPv6) https://complexity.enyc.org.uk/enyc/
16:49 enyc: imirkin: using an xorg.conf that may be outdated nouveau config maybe worked one time maybe not can't remember =)
16:50 enyc: imirkin: going to boot to 4.9 and a no-xorg.conf- default and log that too
16:53 imirkin: enyc: can't seem to access it (i do have ipv6)
16:53 imirkin: getting "no route to host"
16:53 imirkin: ping6 -n www.google.com works though, so it's unlikely to be an issue on my end
16:55 enyc: imirkin: try again
16:55 enyc: imirkin: was rebooting ;p
16:56 imirkin: ok, looks like both gpu's are detected by the nouveau kernel driver
16:56 imirkin: and both gpu's are detected by Xorg -- if you run "xrandr --list-providers" you should see 2 or 3 items
16:56 headless: imirkin: dmesg you were asking me (just a week ago :-): https://bugzilla.redhat.com/attachment.cgi?id=1247824
16:57 headless: nothing stands out
16:57 imirkin: headless: assuming i remember *anything* about your issue would be a mistake
16:57 headless: imirkin: oh. https://bugzilla.redhat.com/attachment.cgi?id=1247824
16:57 headless: grr
16:57 enyc: imirkin: --listproviders
16:58 headless: https://bugzilla.redhat.com/show_bug.cgi?id=1417484
16:58 imirkin: enyc: take a look at https://nouveau.freedesktop.org/wiki/Optimus/ - especially the part about "Using outputs on discrete GPU"
16:58 imirkin: enyc: basically run 'xrandr --setprovideroutputsource 1 0' and that should cause the other outputs to show up
16:59 imirkin: headless: yeah doesn't look like there's anything untoward there. presumably the box hangs not long after 195s of uptime in that dmesg's example?
17:00 headless: imirkin: in short, MATE panel hangs continously redrawing the last couple rows of the display
17:00 imirkin: headless: have you configured things so that the nvidia device is used for regular rendering?
17:00 enyc: imirkin: hrrm sort of ;p yes they appear but can't seem to be set to work
17:00 headless: imirkin: it doesn't hang completely
17:01 imirkin: headless: because if you haven't, i'm not sure that this is a nouveau issue.
17:01 imirkin: enyc: pastebin xrandr output
17:01 headless: I can reboot, and the pseudo-consoles 2-6 work too
17:01 enyc: oooh i discovered an old xrandr-fix.sh script
17:02 imirkin: enyc: there's also a separate approach, which involves disabling xrandr entirely and using Xinerama instead
17:02 imirkin: (which was the pre-xrandr multi-monitor thingie)
17:02 imirkin: enyc: that setup looks something like this: https://nouveau.freedesktop.org/wiki/MultiMonitorDesktop/
17:02 headless: imirkin: the thing I noticed just today: CPU fans start to be very noisy
17:02 imirkin: i'd only use that as a last resort though
17:03 enyc: imirkin: see webpage again 2- files
17:03 headless: and that lasts despite of even a power cycle
17:03 imirkin: headless: check backtraces ... echo w > /proc/sysrq-trigger or something
17:03 enyc: imirkin: i'd like acceleration etc to still work
17:03 enyc: imirkin: i (thought) xinerama prevented that
17:03 imirkin: enyc: yeah it does
17:03 imirkin: well, it doesn't prevent acceleration. it prevents direct rendering.
17:04 imirkin: which is an important aspect of acceleration :)
17:04 imirkin: enyc: xrandr --output DP-1-1 --right-of DP-4 --auto
17:04 enyc: imirkin: kk i'd like to get some semblance of no-xinerama multi hmonitor going again to see if its usable at all with updates to now
17:05 enyc: imirkin: aha big monitor working but needs rotating (not sure if i ever got nouveau rotation behaving)
17:05 imirkin: enyc: xrandr --output DP-1-1 --right-of DP-4 --rotate left --auto
17:05 imirkin: or something
17:05 imirkin: man xrandr :p
17:05 imirkin: all that junk should work
17:05 enyc: imirkin: xserver crash
17:06 imirkin: enyc: X.Org X Server 1.16.4
17:06 imirkin: s/16/18/g :p
17:06 imirkin: (a ton of reverse prime + weird shit got fixed between those releases)
17:07 imirkin: and update to xf86-video-nouveau 1.0.13 while you're at it
17:07 imirkin: might be required for 1.18. i forget.
17:07 enyc: hrrrrrrrm
17:08 enyc: sounds like debian stretch may improve all these things etc
17:08 enyc: xorg 1.19 and nouveau 1.0.13
17:08 imirkin: perhaps. i don't know much about distros.
17:08 imirkin: [esp distro codenames]
17:08 imirkin: i think xorg 1.19 brings hw cursors to reverse prime screens, which is always good
17:26 headless:reboots
17:51 headless: imirkin: I've attached Xorg.0.log
17:51 headless: starnge this is that it calls intel driver near the end
17:52 headless: +the
17:52 imirkin: yeah, so your primary gpu is the intel one
17:52 imirkin: that's what does all the rendering.
17:53 imirkin: you could try booting with nouveau.modeset=0 which will disable nouveau from loading at all
17:53 imirkin: and confirm that you're still having issues
17:54 imirkin: hakzsam: pushed an updated branch. mostly just adding support for pre-SM35 shifts.
17:58 headless: s/this/thing/
18:22 imirkin: if someone could test my int64 branch on fermi or kepler1, that'd be awesome - i don't have one of those plugged in
18:22 imirkin: branch here: https://github.com/imirkin/mesa/commits/int64
18:23 imirkin: run piglit as ./piglit-run.py -t shader_int64 -1 tests/gpu.py int64
18:23 imirkin: karolherbst: --^
18:29 karolherbst: cool
18:36 headless:reboots again
18:36 hakzsam: imirkin: cool
18:37 hakzsam: imirkin: can you show me the output of that test with and without the sched logic?
18:39 imirkin: hakzsam: https://hastebin.com/enosinukog.pl
18:42 hakzsam: thanks
18:43 imirkin: note that sub u32 { # $r0 $r2 (8) is a little misleading - there's a NULL dst[0] and a non-null dst[1]
18:43 imirkin: perhaps it's upsetting some kind of logic
18:46 imirkin: for (int d = 0; insn->defExists(d); ++d)
18:46 imirkin: recordWr(insn->getDef(d), cycle, ready);
18:46 imirkin: i wonder if that's it...
18:47 hakzsam: definitely possible yeah
18:48 hakzsam: I don't really look at this right now though
18:48 hakzsam: a bit later :)
18:48 headless: imirkin: so, quite unexpectedly, that option fixed everything
18:48 imirkin: headless: ok, i guess it is some kind of silly MATE interaction with a secondary gpu
18:50 headless: imirkin: thanx fir your help!
18:50 imirkin: headless: note that your power usage will go up
18:50 imirkin: since nouveau is no longer suspending your gpu
18:51 headless: imirkin: I don't care that much, laptop's is AC powered most of the time
18:51 imirkin: ok
18:51 imirkin: hakzsam: yeah, that's it
18:52 imirkin: hakzsam: ok, i will fix it up somehow. don't worry about it...
18:52 imirkin: i think the solution is to fix things on the input end, since the whole thing with null being a valid dst is kinda bs.
18:54 hakzsam: yeah, having dst[0] == NULL and dst[1] =! NULL is a bit weird
19:01 headless: heh, I was sure Nouveau was driving my display all that time :-)
19:04 headless: *for
19:22 imirkin: hakzsam: mostly a few emitters need to be adjusted to cope
19:23 imirkin: and the DCE pass updated
19:23 imirkin: er hrm.... maybe i'm supposed to stick a dumb ssa thing in there
19:23 imirkin: hold on
19:25 imirkin: well that's just super. something manages to DCE it. after the DCE pass!
22:19 kattana: hei
22:19 kattana: does nouveau use cuda for opencl operations?
22:20 kattana: mm.. I meant opencv
22:20 kattana: my question is really whether cuda can be used under nouveau
22:25 mupuf: kattana: nope, cuda is unsupported
22:52 mystified: pls can you guts assist with GPU issues. Fresh install. Used Nouveau driver
22:52 mystified: Desktop is Xfce
22:52 mystified: Gpu nvidia G210 only supported by Nvidia upto nvidia-340 series
22:52 mystified: here in the pastebin are details of my xorg log, driver in use, system details
22:52 mystified: here in the pastebin are details of my xorg log, driver in use, system details
22:53 mystified: http://pastebin.com/hnDwyHxQ
22:53 mystified: thanks in advance
22:54 karolherbst: what's the issue?
22:54 karolherbst: ohh I see
22:55 imirkin: mystified: you're not using nouveau, you're using vesa.
22:56 karolherbst: I guess either a broken xorg.conf or nouveau ddx not installed
22:56 imirkin: my guess is you have modeset=0 somewhere?
22:56 karolherbst: or that
22:56 imirkin: or nomodeset
22:56 imirkin: karolherbst: could i get you to test int64 on your kepler for me?
22:56 imirkin: or did you say you're busy?
22:57 karolherbst: both, currently nvidia is loaded for stuff, but I could have compiled mesa already :D, wait a sec
22:57 imirkin: ok, well, no rush
22:57 karolherbst: int64 was it?
22:57 imirkin: yes.
22:59 mystified: thx karolherbst
22:59 mystified: thx imirkin
23:00 mystified: intel i7-960 generation 1
23:16 imirkin: hakzsam: ok, i think i've got it all fixed up. updated the branch. running tests now.
23:22 mystified: Just tried installing Mesa but made no diff
23:23 imirkin: not sure why you thought it would...
23:24 mystified: any other suggestion s ? THX
23:25 mystified: At alpine-linux distro they stated I need mesa
23:25 imirkin: did you read my earlier ones?
23:25 imirkin: you *also* need mesa, but that has nothing to do with your current problems.
23:25 mystified: you're not using nouveau, you're using vesa
23:26 mystified: Ok how to remove vesa.. I've already installed nouveau
23:26 imirkin: nouveau should end up getting used. the fact that it's not means that you have some special bit of configuration stopping it.
23:26 imirkin: remove said bit of configuration, and all will be well
23:27 mystified: ok
23:30 mystified: I've just looked in both rc.conf & rc.conf.d
23:30 imirkin: my guess is you have modeset=0 or nomodeset somewhere
23:31 imirkin: on your kernel cmdline
23:31 mystified: sory not rc
23:31 imirkin: or in the module loader's options
23:31 mystified: xorg.conf
23:31 mystified: they don't exist
23:36 karolherbst: mystified: cat /sys/module/nouveau/parameters/modeset
23:36 karolherbst: and
23:36 RSpliet: mystified: rather vitally as well, your (unfiltered!) dmesg log is missing from the paste
23:36 karolherbst: cat /proc/cmdline
23:37 RSpliet: nor am I certain that you installed all nouveau components (esp. the ddx part)
23:38 karolherbst: RSpliet: there is something wrong going on at the module level already
23:38 karolherbst: RSpliet: because there is no reference on nouveau
23:39 RSpliet: karolherbst: dmesg would clarify a lot
23:40 mystified: http://pastebin.com/BYn6KLmR
23:40 mystified: looks like your right
23:40 karolherbst: yeah
23:40 karolherbst: that nomodeset has to go
23:40 mystified: I'm not a techie
23:41 mystified: how to do that
23:41 karolherbst: I guess you are using grub
23:41 mystified: Thx
23:41 karolherbst: mhhh, I am no expert with grub so I wouldn't know where to change that
23:43 mystified: dmesg
23:43 mystified: http://pastebin.com/bvZUd0XW
23:43 RSpliet: normally these boot options are stored in /etc/default/grub
23:44 RSpliet: after editing that file, run grub2-mkconfig -o /boot/grub2/grub.cfg (or wherever your grub.cfg file is hidden, could be distribution-specific)
23:45 mystified: ok.. now staring to understand
23:46 karolherbst: RSpliet: most distributions have their own config for grub already, so a grub2-mkconfig without parameters should do already
23:46 karolherbst: afaik
23:46 karolherbst: "update-grub" on ubuntu for example
23:47 RSpliet: karolherbst: grub2-mkconfig outputs to the terminal... no idea about more distro-specific tools
23:47 karolherbst: mhh
23:48 mystified: loks like im not using grub.. I have something else
23:48 RSpliet: might be better off asking the folks of your specific distro for help with how to manage their systems
23:48 mystified: thx kindly
23:48 karolherbst: your kernel also has a rather high default log level
23:50 RSpliet: karolherbst: what makes you think that? I don't feel like the kernel is particularly verbose. The X.org.log is another beast, but meh
23:50 RSpliet: (it does claim to have a floppy drive! Those good old days...)
23:51 karolherbst: because it is cut of at the head
23:51 karolherbst: and the pci subsystems prints a lot
23:51 karolherbst: I mean sure, it always prints a lot
23:52 karolherbst: but there are messages I never saw
23:52 karolherbst: mhh
23:52 RSpliet: Nothing abnormal really... and it's only 600 lines, could well be that the log buffer is just set to something rather small
23:52 karolherbst: maybe the log buffer is just super small
23:52 karolherbst: I have 13k lines in dmesg
23:53 karolherbst: imirkin: do I have to do something to run piglit? because it always skip the tests
23:54 karolherbst: ohh wait
23:55 mystified: I've just spoken to alpine.. there in europe & "now in recovery from sorry, we're in post-FOSDEM mode"
23:56 mystified: thats why I was getting support from them
23:57 mystified: It strange .. I've used Trueos (Freebsd) and it was so easy to load nvidia & install driver or even edit xorgconf