02:14 rhyskidd: Lyude: no idea, sorry
03:11 koz_: Does anyone else here use KDE? I'm getting weird rendering issues when alt-tabbing.
07:43 liamdawson: so when I don't have `nomodeset` on my machine, running lspci (even from non-graphical mode) hits a soft lockup, this seems to be all I could find log wise: https://paste.linux.community/view/raw/81fd3f89
07:44 liamdawson: I don't have a "known good" version of the kernel to compare to, because it just didn't work _at all_ in earlier kernel versions (guessing hardware support wasn't added yet - have an optimus GTX 1050)
07:50 karolherbst: liamdawson: nouveau.runpm=0
07:51 karolherbst: liamdawson: there is a patch to kind of not break the machine though: https://lists.freedesktop.org/archives/nouveau/2017-November/029185.html
07:52 liamdawson_: so does runpm disable the primus power management?
07:53 karolherbst: liamdawson: the issue basically is here, that we can't wake up the GPU anymore after it goes into suspend
07:53 liamdawson: because if that means running the DGPU at all times, that will tank my battery life :(
07:53 karolherbst: right
07:53 karolherbst: that's what the other patch is for
07:53 liamdawson: right, so is that even just screen off, or?
07:53 karolherbst: your GPU will go to sleep with it, but if we fail to wake it up, we don't do stupid stuff
07:54 liamdawson: my kernel is currently soft-locking multiple times per minute, with nomodeset as part of the boot
07:54 karolherbst: it is a basically a safe guard in case something goes wrong
07:54 liamdawson: something is _really_ weird
07:54 karolherbst: yeah
07:54 karolherbst: I know
07:54 liamdawson: oh, okay
07:54 karolherbst: something within the waking the GPU up process
07:54 liamdawson: explains the choppiness!
07:54 karolherbst: it is maybe an ACPI issue
07:54 karolherbst: maybe not
07:55 liamdawson: I notice I have an ACPI table load failure on boot
07:55 karolherbst: nobody really knows for now
07:55 liamdawson: 12 succeed, one fails?
07:55 karolherbst: maybe it uses windows 10 features and thinks it could use it
07:55 karolherbst: dunno
07:55 liamdawson: I don't imagine having windows installed would affect that?
07:55 karolherbst: I have a laptop with such an issue and might look into it next
07:55 karolherbst: no
07:55 liamdawson: yeah, didn't think so
07:55 karolherbst: it is more like the firmware is trying to figure out what kernel is running
07:55 liamdawson: one of the newer dell XPS15 devices here
07:55 karolherbst: and it enables certain features if it thinks the kernel supports stuff
07:56 karolherbst: yeah, I have that one as well
07:56 karolherbst: everybdy seems to have it :D
07:56 liamdawson: it's beautiful... except this haha
07:56 karolherbst: 9560, right?
07:56 liamdawson: I think so
07:56 liamdawson: if that's the 4k screen one
07:56 karolherbst: yeah, I think the 9550 is fine...
07:56 karolherbst: well
07:56 karolherbst: at least you don't need the nvidia GPU for anything
07:57 liamdawson: would blacklisting the device make the issue go away, in the interim?
07:57 liamdawson: the intel graphics will handle my non-Windows usecases
07:57 karolherbst: well, all display connects are wired to intel afaik
07:57 karolherbst: so there are really only two choices: disable nouveau, or run nouveau with nouveau.runpm=0
07:58 karolherbst: there are also some issues with getting the GPU in a state where we can do OpenGL on it, but I think I've tracked down all of those already
07:58 liamdawson: so just to clarify, `runpm` causes the DGPU to run, or not run, at all?
07:58 liamdawson: (if set to 0)
07:58 karolherbst: runpm=0 just disables the kernel feature to turn the GPU off
07:58 liamdawson: cool
07:59 liamdawson: other option is to blacklist the nouveau mod?
07:59 liamdawson: as in lsmod...?
07:59 karolherbst: but well... nouveau can't really use that card anyway, because enabling the hardware acceleration engines breaks stuff...
07:59 karolherbst: yeah, kind of
07:59 liamdawson: I was using bumblebee/Nvidia drivers previously, but was running into issues quite recently
08:00 karolherbst: well
08:00 liamdawson: such as gnome crashing after locking the screen
08:00 karolherbst: bbswitch basically uses the same code as nouveau for runpm
08:00 liamdawson: so same issue, then?
08:00 karolherbst: most likely
08:00 liamdawson: Brilliant!
08:00 karolherbst: disabling the bbswitch stuff should work as well
08:00 liamdawson: okay, so for now, I'll aim to run _only_ the intel graphics
08:00 liamdawson: (in Linux)
08:00 karolherbst: well
08:01 karolherbst: you can configure bumblebee in a way, that it will keep the GPU always on
08:01 liamdawson: without turning it off at the UEFI level
08:01 karolherbst: which should work
08:01 liamdawson: I'd prefer not to, from a battery perspective
08:01 karolherbst: right
08:01 liamdawson: currently travelling
08:03 liamdawson: might also explain why tlp broke too, it would have been fiddling with GPU power state
08:04 liamdawson: thanks for the context karolherbst!
08:20 liamdawson: is there somewhere I can follow the status of this issue?
08:21 liamdawson: looks like I'm going to use runpm, because the intel graphics don't actually seem to hardware accelerate in Wayland
08:35 karolherbst: liamdawson: well, it should hw accell in wayland as well
08:35 liamdawson: the intel graphics?
08:35 karolherbst: yeah
08:35 liamdawson: it tells me it's using llvmpipe
08:36 karolherbst: weird
08:36 liamdawson: and I'm trying to search for intel drivers, and all I can find info on is for X11
08:36 liamdawson: so I'm wondering if it's just not supported yet
08:36 karolherbst: well, intel uses mesa as well
08:36 karolherbst: but maybe there is an intel dri-drivers package or something
08:36 liamdawson: so I'm looking for a mesa/wayland combo, or something else?
08:36 karolherbst: did you test with glxinfo or eglinfo?
08:37 liamdawson: uh, nothing that fancy, Gnome settings > Details
08:37 liamdawson: I'll try those commands now
08:37 liamdawson: hmm
08:37 liamdawson: I'm seeing some intel info in glxinfo
08:37 liamdawson: maybe it's just not as powerful as I'd hoped?
08:38 liamdawson: (it's like 5 fps when doing the Gnome animations, which didn't feel right)
08:38 karolherbst: mhh, actually you should test with es2_info
08:38 liamdawson: alright, I'll install the appropriate package
08:39 liamdawson: okay, what am I looking for?
08:39 karolherbst: GL_RENDERER
08:39 karolherbst: on X it prints "GL_RENDERER: Mesa DRI Intel(R) Haswell Mobile" for me
08:39 liamdawson: GL_RENDERER: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
08:39 karolherbst: looks fine
08:40 liamdawson: so why does Gnome say llvmpipe? :/
08:40 karolherbst: no clue
08:40 liamdawson: huh, it's soft locking my machine again
08:40 karolherbst: you may want to ask in some gnome channels about that
08:40 liamdawson: no, actually
08:40 liamdawson: it finally loaded, and says the intel graphics
08:40 liamdawson: cool, it's just not as powerful as I'd hoped
08:41 karolherbst: well
08:41 karolherbst: the intel gpu is quite capable
08:41 liamdawson: could be to do with the 4K resolution?
08:42 karolherbst: might be
08:42 liamdawson: I think I'll roll with the proprietary drivers until I hear more (or can help) about the status of Nouveau with this device
08:42 liamdawson: :(
08:43 karolherbst: well, even if nouveau would work, it would be slower than the intel gpu
08:43 karolherbst: because we can't reclock the GPU without nvidia providing those PMU firmwares
08:43 liamdawson: because hardware acceleration isn't happening, right?
08:43 karolherbst: well, that we can do
08:43 karolherbst: but we can't change clocks
08:43 liamdawson: wait, so Nvidia has boned nouveau on the 10xx series?
08:45 liamdawson: If so, I think I remember an appropriate Linus-ism for this one
08:46 karolherbst: it started with the gm20x gpus actually
08:46 karolherbst: so kind of the 9xx and the 750 (ti)
08:46 karolherbst: only the PMU can do most of the reclocking bits and to run stuff on the PMU that stuff needs to be signed with a key only nvidia knows
08:47 liamdawson: oh ffs
08:47 liamdawson: though I was just reading that AMD basically do the same thing
08:48 karolherbst: well, nvidia is quite late to the party though
08:48 liamdawson: well, thanks for your help
08:49 liamdawson: I've learned a lot tonight
08:49 karolherbst: and the newest GPUs you can use with a deblobed kernel are actually nvidia ones
08:49 karolherbst: not intel, not amd
08:49 karolherbst: they won't work there
08:49 karolherbst: well intel until haswell I think?
08:49 liamdawson: is this for security purposes, or something else?
08:50 karolherbst: well officialy they say it
08:51 karolherbst: but I think actually they just crawled up the asses of the media industy
08:51 karolherbst: to have better means of doing drm
08:51 liamdawson: ah, those guys, the reason wwwwwwwwwwwwwwwwwwwwwwwwwwe can't have nice things
08:51 liamdawson: whoops, soft lock
08:52 karolherbst: I think nvidia is saying something like that no malware is tempering with the power management stuff of the GPU
08:52 karolherbst: well
08:52 karolherbst: should be able to
08:52 liamdawson: so, bitcoin miners ;)
08:52 karolherbst: well, actually not
08:52 karolherbst: this has nothing to do with that
08:53 karolherbst: it is more like that no malware pokes into random regs and "burns" your GPU or something
08:53 karolherbst: or let the fans run at 100% or 0% all the time
08:53 karolherbst: that kind of stuff
08:53 liamdawson: I feel like there'd have to be other ways to solve that problem
08:53 karolherbst: you know, because that's a mayor problem, right?
08:53 liamdawson: like how your mobo can perform a thermal shutdown
08:53 karolherbst: well GPUs can do that for years
08:54 liamdawson: yeah
08:54 karolherbst: well, it is a bullshit argument and everybody knows it
08:54 liamdawson: well, I've got to go, but thanks again for the input
08:54 karolherbst: but they still keep on lying
08:54 karolherbst: yeah, no problem
10:32 karolherbst: and we snould propably fix that hwmon bug as well: "temp1: +511.0°C" :D
10:34 karolherbst: (0xffffffff & 0x0001fff8) >> 8 = 511
11:11 karolherbst: Lekensteyn: you are aware of those runpm issues on those new dell XPS 15 laptops?
11:12 karolherbst: seems like that if CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is enabled in the kernel and acpi_rev_override=1 passed to the kernel, then it kind of works
11:25 Lekensteyn: karolherbst: yes I am, my siblings have these models (and I think you mentioned you had the same model?)
11:25 karolherbst: yes
11:25 karolherbst: I am no expert regarding all that ACPI stuff though. I would guess that this runpm stuff is rather complex?
11:25 karolherbst: well, reading the ACPI code I mean
11:26 Lekensteyn: I haven't yet had the time to get through the table and investigate it, but in three weeks it will hopefully get better :)
12:01 karolherbst: Lekensteyn: mhh, currently thinking about if I should just go ahead and try to take a look myself. Might be faster than waiting several weeks
12:11 karolherbst: pmoreau: how can I build llvm to use lib64 instead of lib for stuff?
12:12 pmoreau: Good question; it should be possible to overwrite the CMake variable for it, as long as LLVM’s CMakeLists.txt does not hardcode it.
12:12 pmoreau: Let me have a look
12:13 mupuf: karolherbst: well done for your patch, btw!
12:13 karolherbst: mupuf: well, yeah, but skeggsb was mainly clueless why it is needed, because it should be done already
12:13 mupuf: oh, some debug needed the
12:13 karolherbst: yes
12:13 karolherbst: I didn't post the patch to get it accepted anyway
12:14 karolherbst: but more to have a point where we can start discussing a proper solution
12:14 mupuf: :)
12:15 karolherbst: pmoreau: well, I will try to figure out what fedora is doing
12:15 pmoreau: You could have added the NVIDIA ML to the CCs, if you wanted them involved as well.
12:16 karolherbst: ohh tstellar maintains it
12:16 karolherbst: pmoreau: mhh, would have made sense, right
12:17 pmoreau: It’s not too late to forward it to them, or reply to your own message with them in CC, maybe tagr or whoever might have some answers about it.
12:20 karolherbst: pmoreau: -DLLVM_LIBDIR_SUFFIX=64
12:20 karolherbst: :)
12:20 pmoreau: Sounds easy enough :-D
12:21 pmoreau: Indeed! I wasn’t searching for the correct string inside their CMakeLists.txt
12:35 karolherbst: so, now the same for mesa
12:42 karolherbst: pmoreau: please move CFLAGS _after_ calling autogen.sh
12:42 karolherbst: uhm CPPFLAGS
12:43 pmoreau: karolherbst: I have removed that part altogether now, as I added a .pc file to SPIRV-Tools, removing the needs for all the hacks in the configure.ac file. I haven’t pushed them yet as
12:43 pmoreau: 1) I haven’t pushed my SPIRV-Tools changes
12:43 karolherbst: ahh, okay
12:44 pmoreau: 2) I was having issues getting autotools to pick the new PKG_CONFIG_PATH when running from a script. Running manually worked fine though
12:45 pmoreau: I can have a look at it again tonight, and push those changes
12:45 karolherbst: pmoreau: but I also meant it more generally
12:45 karolherbst: please don't set CFLAGS in the environment, but pass those as flags to configure
12:46 karolherbst: because this way they are listed if you do "head config.log"
12:46 pmoreau: How do you do that?
12:46 karolherbst: just move them
12:46 karolherbst: ../configure ... CFLAGS="...."
12:47 pmoreau: I only use autotools for Mesa (and planning to drop it once meson builds clover), so I looked for the quickest way that got it done. :-D
12:48 pmoreau: OK, will change the script for CFLAGS and the other ones
12:48 pmoreau: Thanks for the info!
12:48 karolherbst: well, autogen.sh calls configure
12:49 karolherbst: pmoreau: uhm... does your mesa branch have the pascal stuff already?
12:50 pmoreau: What Pascal stuff?
12:50 karolherbst: support
12:50 karolherbst: no idea on what your tree is based on
12:51 pmoreau: The branch was last rebased on the 12th of November it seems
12:51 karolherbst: okay, nice
12:51 pmoreau: So, I would guess it is included
12:53 karolherbst: *sigh* //usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/7/../../../libOpenCL.so when searching for -lOpenCL
12:54 pmoreau: Hum, not sure what that is :-/
12:54 karolherbst: I try to build spir-v-testing
12:56 pmoreau: spir-v-testing what is that one? (too many spirv things around, I forgot what it could be)
12:57 karolherbst: your stuff
12:57 karolherbst: https://phabricator.pmoreau.org/diffusion/SPVTES/
12:57 pmoreau: I had issues when running OpenCL applications, which would not pick up my custom OpenCL build because the OpenCL ICD was not installed. (I deactivated it cause it always needed root privileges to install. I installed the opencl-mesa package from Arch instead to have it.)
12:57 pmoreau: Ah, that one
12:57 karolherbst: Generating g_arg_w_int32.test
12:57 karolherbst: and then that error appears
12:58 pmoreau: Hum, not sure
13:00 karolherbst: if I try to compile it directly with clang++, this happens: fatal error: 'iostream' file not found
13:00 karolherbst: ...
13:01 pmoreau: :o
13:01 pmoreau: Which clang++ is it using?
13:01 karolherbst: mine
13:02 pmoreau: It should be using the one you compiled, as otherwise it won’t support emitting SPIR-V.
13:02 pmoreau: (Well, shouldn’t matter for the cpp files, only the cl ones.)
13:03 karolherbst: yes
13:04 karolherbst: seriously, those autotools and whatever are seriously broken by design
13:05 karolherbst: V=1 has no effect if I also pass in -j1 or what?
13:06 RSpliet: I'd like to chime in, but quite frankly I was a little horrified by the Meson discussion I just found on the ML
13:06 karolherbst: ahh, it still uses gcc for the tests
13:06 RSpliet: so I'm not sure if I want to burn my hands on that
13:07 pmoreau: RSpliet: Which discussion did horrify you? I might have missed that one.
13:07 karolherbst: pmoreau: g++ -L/usr/lib6/ -lOpenCL -o g_arg_w_int32.test g_arg_w_int32.o /home/kherbst/git/spir-v-testing/util.o .... and then /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/7/../../../libOpenCL.so when searching for -lOpenCL happens
13:07 RSpliet: pmoreau: the one where they spent a lot of time debating whether the default build should contain debugging features and which ones
13:07 karolherbst: ....
13:07 karolherbst: ah right, this one
13:07 pmoreau: Ah, I have CC=clang and CXX=clang++ by default on my computers.
13:08 pmoreau: I can try tonight with gcc
13:08 karolherbst: pmoreau: yeah well, that shouldn't be the problem
13:08 karolherbst: just wandering why it uses the 32bit stuff
13:08 pmoreau: Hum, true.
13:09 karolherbst: ohh wait, I have no libOpenCL.so file....
13:09 karolherbst: only .1 and so on
13:09 karolherbst: the hell
13:09 pmoreau: I am used to Arch where there is lib32 and lib, with lib64 being an alias to lib :-D
13:09 karolherbst: right
13:10 pmoreau: RSpliet: Ah, that one, right
13:10 karolherbst: RSpliet: well, usually sane people thing there is a common understanding of such things like, options passed to configure are application features being toggled, not "smart" compiler flags being changed
13:10 karolherbst: because this is the only way to stay sane
13:10 pmoreau: I will sadly not be able to help you more right now though: I do need to work, and I don’t have the code/setup at hand either :-(
13:11 karolherbst: mhh
13:11 karolherbst: it kind of works
13:12 pmoreau: What did you change?
13:12 karolherbst: pmoreau: https://gist.github.com/karolherbst/2195514027398fc0e9683a3c0a2e27e9
13:12 karolherbst: I created that symlink
13:13 karolherbst: what does that invalid source mean?
13:13 pmoreau: “invalid source” mmhhh
13:13 pmoreau: I’m trying to remember :-D
13:13 karolherbst: well, this is pascal, maybe something needs to be wired up?
13:14 pmoreau: I haven’t tried on Pascal, that is true, but if it was something that was not wired up, I would expect a different error message
13:17 pmoreau: karolherbst: Can you break in src/gallium/state_trackers/clover/core/program.cpp:64 and see where it goes, please?
13:18 karolherbst: I have a better idea what is wrong
13:18 pmoreau: Great :-)
13:18 karolherbst: it uses /lib64/libdrm_nouveau.so.2
13:19 karolherbst: \o/
13:19 karolherbst: g_arg_rw_struct_char4: PASS
13:19 pmoreau: \o/
13:19 karolherbst: so you can check pascal as well on your wiki page :p
13:20 pmoreau: Try to run `make test` from the root dir
13:20 karolherbst: yeah
13:20 karolherbst: already doing that
13:20 pmoreau: One should be failing, the async_copy one
13:20 karolherbst: instruction_sets fails
13:20 pmoreau: I haven’t finished that one yet.
13:20 karolherbst: smad24 and umad24 fail as well
13:20 pmoreau: Ah, mad24 might not RE'ed/work on Pascal
13:21 karolherbst: ./async_work_group_copy.test: fails as well, right
13:21 pmoreau: Going to add that to Trello (for mad24 on Pascal)
13:21 karolherbst: it even works with runpm=1, nice
13:21 pmoreau: Yup :-)
13:21 pmoreau: I have been doing most of the development on my laptop, with runpm=1
13:22 karolherbst: so after spending like too much time on getting everything to work on my laptop, it finally pays of, yay
13:22 pmoreau: Still need to give your series a try. --"
13:22 karolherbst: :D
13:22 karolherbst: well I don't bother, because it is kind of pointless on pascal
13:22 karolherbst: changing the pcie link works though
13:23 pmoreau: If you have any inputs on how to improve the instructions, things to fix (besides the CFLAGS thing), feel free to tell me :-)
13:24 karolherbst: --with-dri-drivers=nouveau <== don't
13:24 pmoreau: I remember having issues if I did not do that, but I’ll have another try.
13:24 karolherbst: it is nouveau_vieux
13:25 pmoreau: Yup
13:25 karolherbst: pretty pointless to build it in the first place
13:25 karolherbst: so passing --with-dri-drivers= does the trick
13:26 pmoreau: Will do
13:27 karolherbst: well everything else is personal taste, so it is fine
13:35 karolherbst: pmoreau: smad24.test: ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp:3462: virtual bool nv50_ir::CodeEmitterGM107::emitInstruction(nv50_ir::Instruction*): Assertion `!"invalid opcode"' failed.
13:36 karolherbst: madsp (SUBOP:34) s32 $r2 $r2 c0[0xc] $r3
13:37 pmoreau: Guess I had the same issue on my Maxwell card :-D
13:37 pmoreau: https://trello.com/c/Dndla19m/29-re-and-implement-madsp-for-gm107
13:39 karolherbst: so those are just 24bit mads?
13:41 pmoreau: yes
13:41 pmoreau: Well, madsp (at least on some generation) could be configured to do mad with different precision.
13:42 pmoreau: https://phabricator.pmoreau.org/rMESA7761aa0732d717231cfe5b1d21811422e0c8b995
13:43 karolherbst: I think we have that 24bit in envydis already
13:43 karolherbst: { 0x5a80000000000000ull, 0xff80000000000000ull, OP8B, T(pred), N( "imadsp"), T(5a80_0), T(5a80_1), T(5a80_2), ON(47, cc), REG_00, REG_08, REG_20, REG_39 },
13:44 karolherbst: { 0x0002000000000000ull, 0x0007000000000000ull, N("u24") }, for T(5a80_0)
13:45 karolherbst: I try to implement it somehow on maxwell
13:56 feaneron: in https://trello.com/b/ZudRDiTL/nouveau, do the labels mean "dificulty" (green → easy ... red → hard) or "priority" (green → low .. red → fix that now) ?
13:57 feaneron: duh, nevermind. if i had clicked in any ticket, i'd have seen it stands for "dificulty"
13:57 feaneron: sorry for the noise folks
13:58 pmoreau: feaneron: No worries :-)
13:58 karolherbst: pmoreau: actually, I have to check out this: { 0x5280000000000000ull, 0xff80000000000000ull, OP8B, T(pred), N( "imadsp"), T(5a80_0), T(5a80_1), T(5a80_2), ON(47, cc), REG_00, REG_08, REG_39, C34_RZ_O14_20 },
14:00 feaneron:looks for an easy task to start contributing - accepting suggestions :)
14:02 pmoreau: Which GPU do you have? (It’s easier to work on something if you have the corresponding hardware.)
14:02 karolherbst: feaneron: mhh, check out the gsoc list :D
14:03 karolherbst: but to be more serious, well
14:03 karolherbst: fix the issues you encounter
14:05 karolherbst: pmoreau: any idea what NV50_IR_SUBOP_MADSP_SD is?
14:05 feaneron: pmoreau: it's a kepler 920m. yeah, that's the idea - no budget for any other card now...
14:05 pmoreau: SD=Standard Definition, as opposed to HD :-D
14:05 pmoreau: No clue
14:07 feaneron:checks the gsoc list
14:07 pmoreau: 920m, which chipset is that? (it should tell you in `lspci -d 10de:`, most likely a GMXXX thing
14:08 feaneron: even though it's 9xx, it's kepler (GK208M)
14:08 pmoreau: Eh, OK
14:09 feaneron: yeah, confusing. appearently, it was made for some kind of crypto currency mining or such?
14:11 pmoreau: 920M -> GK208, 930M -> GM108, 940M -> GM107, all launched at the same time
14:11 pmoreau:added the 920M to the wiki’s CodeNames page
14:13 pmoreau: So, I was previously going to say “great, there are probably more low hanging fruits on Maxwell than previous gens”, but that is no longer appropriate :-/
14:14 karolherbst: somebody should kill this NV50_IR_SUBOP_MADSP thing...
14:16 pmoreau: Translating some of the SPIR-V opcodes to NVIR operations should be fairly easy to do, but it might be easier to work on something which is at least partly upstreamed.
14:23 feaneron:particularly interested in the reclocking stuff
14:24 RSpliet: feaneron: I thought the same thing a good 7 years ago. Conclusions I've drawn include "not really a beginners task"
14:25 RSpliet: Don't want to discourage you, happy to answer questions, but it's a tedious job that's currently stalled due to circumstances
14:25 feaneron: RSpliet: thanks for the warning. i really have no parameters to decide what's doable or not for now
14:25 RSpliet: That's why we are here ;-)
14:26 RSpliet: problem with clock changes is that it's an all-or-nothing game. 80% still gives you no positive feedback, so you need a long breath to pull it off
14:26 karolherbst: pmoreau: mad24() is where all arguments are 24bit?
14:27 RSpliet: karolherbst: this page should be in your bookmarks: http://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-mad24
14:27 karolherbst: RSpliet: why?
14:28 RSpliet: because it answers questions like those without human intervention. ptx is pretty close to hw
14:29 karolherbst: I am sure it doesn't answer if I can put a constbuf argument as src1 or src2 only?
14:30 karolherbst: and at which positions all those bits have to be set to select the size of the values
14:30 pmoreau: From the 1.2 spec: “Multiply two 24-bit integer values x and y and add the 32-bit integer result to the 32-bit integer z.” and “x and y are 32-bit integers but only the low 24-bits are used to perform the multiplication.”
14:30 karolherbst: I mean, I am thankful for helping and so, but I don't see how that should help us figuring out how the instruction should look like on the ISA level
14:32 karolherbst: the painful part is, what the hell should SUBOP:34 mean
14:33 feaneron: maybe https://trello.com/c/yErAzlUl/146-fermi-kepler-fan-management ? it's labeled as easy, and i have a kepler card.
14:33 RSpliet: karolherbst: it helps to get started. There's also a way of translating ptx to opcodes and vice versa. I forgot the exact syntax, but it uses the cuda toolkit. Let me see if I can dig that up for you as well (if imirkin doesn't beat me to it)
14:33 karolherbst: yeah, I am aware, but I was actually asking about the mad24 opencl function, where the docs are a bit more specific to what the expected result is
14:33 pmoreau: ptxas to generate a binary, and then nvdisasm on it?
14:34 RSpliet: pmoreau: yeah something like that :-D
14:34 karolherbst: yep
14:34 karolherbst: I have the script on my local machine
14:34 pmoreau: karolherbst: That was from the OpenCL 1.2 spec, about the mad24 OpenCL function ;-p
14:34 karolherbst: pmoreau: yeah, yours, right
14:35 karolherbst: anyhow, I turned it into a imadsp u24 u16h0 u32 $r2 $r2 $r3 c0[0xc]
14:35 pmoreau: Ah, sorry, you were replying to Roy :-)
14:35 karolherbst: which clearly seems wrong
14:35 karolherbst: should be u24 u24 u32, right?
14:36 imirkin: ptxgen in envytools
14:37 pmoreau: mupuf: Would https://trello.com/c/yErAzlUl/146-fermi-kepler-fan-management be easy? Or is it possible to run into your annoying fan function you are trying to RE?
14:38 pmoreau: imirkin: Oh, nice! Didn’t know it existed, will have to try it
14:39 karolherbst: imadsp u24 s24 u32 $r2 $r2 $r3 c0[0xc] much better
14:39 karolherbst: but
14:39 karolherbst: in nv50ir it was "madsp (SUBOP:34) s32 $r2 $r2 c0[0xc] $r3"
14:40 imirkin: karolherbst: it's a pain with types. you can read the notes about how it's a hack.
14:41 karolherbst: I am aware, but using such bitmask is painful in itself already
14:43 imirkin: to have full support for the op - yes.
14:43 imirkin: but for the handful of cases it's used ... meh
14:44 imirkin: why is this coming up btw?
14:44 imirkin: there's a ton of scrollback and i don't feel like reading it right now
14:45 karolherbst: pmoreau opencl tests
14:46 karolherbst: pmoreau: something is super weird with this test
14:46 imirkin: well iirc we have a TYPE_U24
14:46 pmoreau: karolherbst: What is weird with it?
14:46 imirkin: and the emitter could cleverly emit the right op for those
14:46 karolherbst: pmoreau: it expects 1 * 0x00ffffff + 0, right?
14:47 karolherbst: why does the application tells me it expects 8167772152
14:47 karolherbst: ohhhh wait
14:47 karolherbst: that's c++ doing silly things
14:47 karolherbst: std::cerr << name << ": FAIL: " << out_h << " instead of " << std::cout.hex << res << std::cout.dec << "\n"
14:48 pmoreau: Ah, there should be a hex/dec around out_h as well
14:49 karolherbst: use std::hex and std::dec
14:49 karolherbst: FAIL: 1 instead of ffffff
14:49 karolherbst: now I get this
14:50 pmoreau: Yeah, that looks better than std::cout.hex, especially when actually outputting to std::cerr :-D
14:50 karolherbst: :D
14:51 karolherbst: mhhh imadsp u24 u24 u32 $r2 $r2 $r3 c0[0xc]
14:51 karolherbst: pmoreau: do you know if it should be imadsp u24 u24 u32 $r2 $r2 c0[0xc] $r3 instead?
14:52 karolherbst: but I always get 1
14:52 karolherbst: no matter what numbers I put into it
14:52 karolherbst: I even did 1, 2, 4 for testing
14:53 pmoreau: Probably. I’ll have a look on Kepler, as it is working there
14:53 pmoreau: (but tonight, not now)
14:53 karolherbst: okay, I think it does a * 1 + 0
14:54 karolherbst: uhm, op1
14:54 karolherbst: not a
14:54 karolherbst: or nothing happens with $r2
14:54 karolherbst: might be the case as well
14:55 karolherbst: imirkin: do you know if there is something weird with that on maxwell/pascal?
14:55 karolherbst: with imadsp
15:20 karolherbst: from the cuda installer help: "--uninstall (deprecated)"
15:42 pmoreau: Once you install it, you can never go back… :o
15:42 imirkin_: karolherbst: i don't know anything about about IMADSP
16:18 johnjay_: hey imirkin_ is it true there are 1000+ projects that use xlib and haven't moved to xcb yet?
16:19 imirkin_: sounds like a lowball estimate
16:20 imirkin_: there never was a reason to move to xcb
16:20 imirkin_: so ... why bother
16:20 johnjay_: but, but... it's BETTER. it says so in the readme file!
16:20 imirkin_: i'm sure it is
16:20 imirkin_: on many levels
16:20 imirkin_: none of which matter to 99% of applications
16:21 johnjay_: so now instead of just including one library or the other, linux includes *both*. So even if it's 30% the size that's still an increase in space
16:22 johnjay_:wonders if they should just change xlib to get rid of the functionality nobody used for a better result
16:22 imirkin_: https://xkcd.com/927/
16:22 karolherbst: those few kbs
16:23 johnjay_: karolherbst: I used the comm command to get a list of packages that depend on x11 but not xcb. it's about 1600 entries
16:23 karolherbst: so what?
16:24 karolherbst: you will have dozens of libs on your system which only have one user
16:24 karolherbst: some just thought xcb is a good idea
16:24 karolherbst: and others thought it is a good idea to use it
16:24 johnjay_: when I reverse the search and do xcb only and not x11 I get 87 packages. lol
16:24 karolherbst: so?
16:25 karolherbst: what is your point here?
16:25 johnjay_: the main advantage of xcb it says is to reduce space and extend functionality
16:26 johnjay_: but how is it reducing anything if you have to have both app A and the app B that "enhances/extends/replaces" A
16:26 karolherbst: are you sure they meant disc space?
16:27 karolherbst: but anyway
16:27 karolherbst: there are valid use cases for xcb
16:28 johnjay_: wikipedia simply says to extend the protocol and reduce "library size"
16:28 johnjay_: then links to some paper: https://www.freedesktop.org/software/xcb/xlib_impl.pdf
16:28 karolherbst: library size means less RAM usage mainly
16:29 karolherbst: and then again: what is your point
16:29 karolherbst: why do we have this kind of conversation?
16:29 johnjay_: maybe in 2004 it was 700kb of RAM was a lot?
16:29 karolherbst: do you want to get rid of one of those two?
16:29 johnjay_: I don't know, why have any conversation
16:29 karolherbst: fine, then work towards this
16:30 karolherbst: well, you seemed to care enough to bring it up
16:30 johnjay_: the first paragraph of the wiki article says it was founded "to replace Xlib"
16:30 johnjay_: So I was curious... did it replace Xlib? the answer is no apparently
16:30 mjg59: It does. Applications and libraries can use xcb instead of xlib.
16:31 mjg59: For those cases, it's a replacement
16:31 johnjay_: it's like you don't perceive the cause effect relationship here. i read something on wikipedia. i ask myself, "is that thing" true. Then the effect is I ask someone or talk about it
16:32 karolherbst: seriously?
16:33 karolherbst: okay, let me put it this way
16:33 karolherbst: the usual way in software development isn't that somebody comes up with a replacement and then everybody switches over
16:33 karolherbst: and that is all there is to it
16:34 karolherbst: some value the advantages of xcb so much, that they switch
16:34 karolherbst: others, don't care
16:35 karolherbst: and now the question: should they care? Does everybody should move to "the" replacement? Are we then always occupied with moving to a replacement, if somebody announces another one every month?
16:37 karolherbst: personally all those "why do we sill have X" discussions are not worth my time, because you usually can answer this questions with either a) devs are too lazy to switch b) there is no advantages for project A to move c) they didn't know better
16:48 marmistrz: pmoreau, ping
17:04 gnarface: johnjay_: you're still viewing "Linux" as a static thing - a fixed install base with no ability for the end user to exclude or include things beyond a one-size-fits-all base package. this is a very primitive way of thinking based on the artificial limitation of the windows installation disk.
17:05 gnarface: johnjay_: it'll all make a lot more sense when you learn to start letting go of these types of prejudices
17:06 gnarface: in reality, the answer to your question is that it doesn't even matter a little bit. distros could include one or the other or both. end users only need the one their programs rely on.
17:08 gnarface: xcb was created to fill someone's perceived whim, that's all. it worked, or works, somewhere, sometimes. and as you've seen, it didn't in any way supplant the existing solutions, because there's no market imperative to force artificial obsolescence on open source libraries; that's again, a windows-centric type of thinking. it's in itself obsolete as a concept when you're not trying to drive marketing hype to make
17:08 gnarface: money. none of this was ever about selling these libraries. that changes a lot, at a fundamental level.
18:03 liamdawson: anyone here know how to force bbswitch to keep the DGPU enabled, not suspend it?
18:03 imirkin_: dunno anything about bbswitch, but if you're running nouveau just do nouveau.runpm=1
18:04 liamdawson: unfortunately, proprietary drivers, because it's a GTX 1050
18:04 liamdawson: basically just looking for the bbswitch version of that
18:04 imirkin_: this is not the right place for bbswitch questions, sorry
18:05 liamdawson: no worries, thanks for the response :)
18:05 liamdawson: bumblebee the right place to ask?
18:20 karolherbst: liamdawson: there are two options on bbswitch: load_state and unload_state, and I think 1 means on and 0 off, not quite sure though
18:21 karolherbst: liamdawson: anyhow, I found a working solution for the dell xps
18:21 karolherbst: liamdawson: https://wiki.archlinux.org/index.php/Dell_XPS_15_9560#Disable_discrete_GPU
18:21 karolherbst: but you also need to have a certain option enabled in the kernel for that
18:22 liamdawson: wait, does that fix the full issue?
18:22 liamdawson: like the soft lockups altogether?
18:22 karolherbst: kind of
18:22 karolherbst: it seems to work for me
18:22 liamdawson: huh
18:22 liamdawson: I'll try, thanks
18:24 karolherbst: well that options doesn't do anything if the kernel wasn't compiled with it though, so you really have to check with your kernel config
18:24 liamdawson: okay
18:28 vinzusama: hey liamdawson karolherbst you're running the nouveau driver with Dell XPS's ? which models ?
18:28 liamdawson: I went proprietary now
18:28 liamdawson: 9650, I think?
18:28 liamdawson: or 9660
18:28 liamdawson: whichever is highest and actually exists :)
18:28 karolherbst: liamdawson: well it helps there as well
18:29 vinzusama: okay, mine is 9560, I'm running proprietary drivers but interested to go to nouveau
18:29 liamdawson: I'll need to recompile my kernel and try that
18:30 vinzusama: liamdawson, which linux distrib do you use ?
18:39 liamdawson: Fedora
18:45 vinzusama: is it possible to run the nouveau driver with XPS series ?
18:51 vinzusama: I can see that there's no power management support for NV130 family, but can it be done with bumblebee aside nouveau ?
18:53 imirkin_: that's not the power management that it's referring to
18:53 imirkin_: auto-suepend of the gpu should work fine
18:53 imirkin_: bumblebee with nouveau is counterproductive for most users
18:53 karolherbst: imirkin_: well not on a XPS 15 it won't
18:54 karolherbst: it is bascially broken there, like completly
18:54 imirkin_: karolherbst: it'll work as well as it does with bumblebee ;)
18:54 karolherbst: right, it won't work there as well
18:54 imirkin_: which is my point
18:54 karolherbst: k
18:54 imirkin_: i.e. don't use bumblebee unless you *really* know what you're doing
18:54 karolherbst: right
18:59 vinzusama: karolherbst, what you say is that the nouveau driver doesn't work at all on a XPS 15 ? I did try but unsuccessfuly, so I'm running on proprietary now :(
18:59 karolherbst: not really, I tracked some of the issues down, but we still need to think of proper solutions for those problems
18:59 vinzusama: sorry, english is not my birth language :)
19:00 vinzusama: karolherbst, so you're running nouveau driver for now ? are you on Arch ?
19:57 pmoreau: marmistrz: pong
20:15 bobnode: Using F26 with cinnamon desktop (cinnamon-3.6.6-8.fc26.x86_64). After upgrading from F25 to F26 (xorg-x11-drv-nouveau-1.0.15-1.fc26.x86_64), there is no longer a Display Resolution of 1920x1080 available. Is this a good place to look for help on the issue?
20:16 Lyude: btw karolherbst you haven't happened to fix any nouveau related mmiotrace issues recently have you?
20:16 Lyude: bobnode: you got the right place
20:16 Lyude: imirkin_: ^
20:17 karolherbst: Lyude: well, I wrote that one mmiotrace patch, didn't I?
20:17 Lyude: hehe, I meant specifically with nouveau though. I think I had some issues recently trying to run some mmiotraces on it
20:18 karolherbst: should have been the same issue
20:18 bobnode: Lyude - https://paste.fedoraproject.org/paste/7yldKKIcBCDy1heVbUnn4g
20:18 Lyude: (they're useful for helping me visualize the right spots to actually write to powergating registers)
20:18 Lyude: *clockgating
20:18 karolherbst: Lyude: with my mmiotrace patch you should be able to trace nouveau as well
20:18 Lyude: karolherbst: alright, did that already make it into mainline btw?
20:19 bobnode: It's a 3840x2160 native display. But I use a 1920x1080 resolution. I can add and use 1920x1080 after login using xrandr, but on reboot 1920x1080 is no longer available.
20:19 karolherbst: no
20:20 Lyude: bobnode: smells like a kernel driver bug
20:20 Lyude: Oh. i'm surprised your system is even using the nouveau ddx
20:21 Lyude: bobnode: are you sure you're actually on X or wayland
20:22 bobnode: Lyude - I can boot a prior kernel and see if that help. How to determine X or Wayland?
20:22 Lyude: always worth a shot. And to figure out which one you're on, just open up a terminal on your desktop and type echo $WAYLAND_DISPLAY
20:22 Lyude: If nothing comes up you're on X, otherwise you're on wayland
20:24 bobnode: Lyude - X
20:25 bobnode: Lyude - Off to reboot. If I don't return, then thanks!
20:25 Lyude: bobnode: no problem; if it is a bug a
20:25 Lyude: oh no
20:25 Lyude: what if he never tells us if his problem is fixed
20:25 Lyude: :(
20:27 karolherbst: Lyude: sometimes that's just the way it is
20:28 Lyude: true, but i also have that gpu
20:28 Lyude: so that's probably something we should fix
20:29 Lyude: well, not that exact model but I'm sure any kepler will do. hopefully
20:38 annadane: hi. i have issues with freezing with nouveau and plasma on debian sid - the relevant details in /var/log/messages seem to be https://paste.debian.net/998224/ - using the following kernel (uname -a): Linux debian 4.13.0-1-amd64 #1 SMP Debian 4.13.13-1 (2017-11-16) x86_64 GNU/Linux
20:39 annadane: the freezing in question seems to be: can still move the mouse, but nothing is responsive, can't click on anything, can't even access a virtual terminal
20:40 imirkin_: annadane: try ssh'ing in from a different box and seeing what's up
20:41 gnarface: hmmmm
20:41 annadane: imirkin_, i don't have another box
20:41 bobnode: Lyude - No luck with the kernels currently have installed.
20:41 gnarface: happened to me too on 4.13, but with the official drivers
20:41 Lyude: bobnode: good, otherwise I wouldn't have knew what caused your bug :)
20:41 gnarface: also had some unrelated alsa issues so i just went back to 4.9
20:41 annadane: konsole - plasma's terminal emulator - also bugs out in weird ways
20:42 annadane: well, i know i had freezing issues with stable too
20:42 annadane: aka kernel 4.9
20:42 gnarface: annadane: were you running mplayer at the time by chance?
20:42 Lyude: bobnode: by the way, could you get me your Xorg log and kernel log?
20:42 annadane: gnarface, no
20:42 gnarface: annadane: ssh or mumble?
20:42 annadane: gnarface, no
20:42 gnarface: hmm, unrelated then
20:43 gnarface: (probably)
20:45 annadane: i can give my /proc/cpuinfo and graphics card and all that other good stuff if you like
20:45 bobnode: Lyude - https://paste.fedoraproject.org/paste/cgepMSa6Pfcoa10gYYqBpg
20:46 pmoreau: karolherbst: What did I needed to check/do for you tonight? I got lost between what I needed to look at and what you managed to fix/get running. :s
20:46 gnarface: annadane: i can't actually help you, i was just fishing to see if there was a correlation to my problem from earlier. but i think for these guys to help you, you need to be able to recreate the bug reliably and capture a mmiotrace of it happening
20:47 karolherbst: pmoreau: well, I tried to implement madsp for maxwell
20:47 bobnode: Lyude - https://paste.fedoraproject.org/paste/AZkB03o84jTi~ZlqNSVWnQ
20:47 imirkin_: bobnode: is that Xorg -configure? you shouldn't need an xorg.conf, having one is more likely than not to be counterproductive
20:47 Lyude: ^^
20:47 karolherbst: pmoreau: but something went terribly wrong there and I have no idea if that's the compute part of nouveau or just the wrong opcodes
20:47 karolherbst: need to check with the cuda tools
20:47 pmoreau: OK
20:47 annadane: the 4.14 kernel is actually in experimental, i wonder if that would help at all
20:48 annadane: though i really don't want to install from experimental, i'd rather wait for it to land in sid
20:48 gnarface: anything is possible... different mesa version might help too
20:48 gnarface: random parts-swapping isn't a great debugging method though for this type of thing
20:49 orbea: annadane: what 4.14? here in slackware 4.14.0 and 4.14.1 seem rather unstable. There was even a bcache bug that destroyed file systems... (fixed in 4.14.2)
20:49 orbea: 4.14.2 seems fine so far here though
20:49 bobnode: imirkin - Oops, removing. Was left over from failed attempt to correct. Will reboot and get fresh logs...
20:49 annadane: orbea, not sure i understand your question. the current kernel in debian unstable (sid) is 4.13 and 4.14 is in experimental which indicates it could move to sid soon, or even 4.15
20:50 annadane: though in my experience kernels actually take somewhat long to migrate
20:50 annadane: a rolling release debian is not
20:50 orbea: oh right, debian screws up the kernel versions...forgot that
20:51 annadane: honestly? the solution seems to be "nouveau doesn't work well with plasma" and to just replace my graphics card with AMD
20:51 orbea: yea, buying nvidia is a mistake :)
20:51 annadane: i could, i guess, ask the plasma people...
20:52 gnarface: annadane: most of the nouveau developers will in fact tell you that is the case.
20:52 imirkin_: yes, avoiding nvidia is definitely the way to go if you're looking for a smooth open-source experience.
20:52 annadane: no, i know. i wasn't aware of nvidia's anti-open-source attitude when i bought this computer
20:52 imirkin_: of course it's too late for that now, you're stuck with what you have
20:52 annadane: well, no, i'm not stuck, i could replace my graphics card
20:53 annadane: i'm just lacking in technical knowledge of how to do so
20:53 imirkin_: i'm generally aware that KDE doesn't work great on nouveau
20:53 Lyude: it's very easy
20:53 Lyude: i mean
20:53 Lyude: assuming you have a desktop
20:53 Lyude: laptops are a whole different story
20:53 imirkin_: i haven't had a lot of desire to investigate since that would involve trying to run KDE
20:53 annadane: yeah, desktop
20:53 annadane: the main thing i guess is finding one which is compatible
20:54 orbea: could always drop kde and use something else that works better with nouveau
20:54 Lyude: annadane: amd
20:54 annadane: Lyude, yes, but i mean in terms of interfacing with the other components on the machine
20:54 annadane: orbea, the problem is i like using kde :(
20:55 gnarface: can you disable compositing in kde? it might just be an issue with compositing
20:55 annadane: gnarface, "different mesa version"... such as? i mean i'm really just sticking to the sid repository as much as possible
20:55 annadane: gnarface, possibly. not sure how to do that but i'll do a search
20:56 gnarface: i didn't have any particular mesa version in mind when i suggested that
20:56 johnjay_: i thought nvidia was *the way* to go with open source back in the day
20:56 johnjay_: i guess it's the opposite now
20:56 annadane: they've definitely lost my money on future purchases and i'll tell them so
20:56 gnarface: it was never, but now they've gotten openly hostile to nouveau development with the newer cards' firmware
20:56 annadane: fucking assholes
20:57 Lyude: please do, we honestly appreciate it :)
21:02 Lekensteyn: karolherbst: re acpi_rev_override, it is easy to see what it does (" If ((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 5))"), but what is not clear is why the else branch (which calls "LKEN") is causing issues
21:06 karolherbst: Lekensteyn: is that the ACPI code of the xPS?
21:07 Lekensteyn: yes
21:08 karolherbst: maybe I will indeed take a look tomorrow then
21:08 hussam: closed source nvidia drivers were always glitchy on Linux from the late 2000's cars till today's pascal cards. I remember complaining about issues in 2007 on arch forums. Those issues happened on my old AMD sempron in 2007, an intel core2duo, and the current skylake i5. Also on all cards I bought since.
21:08 Lyude: they're glitchy on everything
21:09 Lekensteyn: SSDT 11 (note that you need to use acpixtract from acpica git or replace some " @ " in the ascii part of the hexdump in acpidump to properly extract the contents)
21:09 Lyude: but it honestly just seems like so many people get used to the things it's broken with that they just kind of assume that's the norm and that it's not glitchy
21:09 annadane: but i don't get the freezing issues with the proprietary drivers
21:09 annadane: sigh
21:09 Lyude: annadane: wonder where it's hanging
21:09 Lyude: can you ssh into it when it happens?
21:10 karolherbst: annadane: yeah, because the prop driver doesn't turn the GPU off
21:10 annadane: i _can't_ ssh in. i don't have another computer
21:10 Lyude: oh :(
21:10 gnarface: annadane: can you ctrl+alt+f2 to another virtual console?
21:10 karolherbst: ohh wait, different issue
21:10 annadane: i'm actually planning on buying a laptop soon so i'll be able to do it then
21:10 Lyude: bobnode: you gave me the wrong x log
21:10 bobnode: Lyude - Correct. There is no x log after reboot
21:11 gnarface: annadane: alt+printscreen+R,E,I,S,U,B might be something else to try. if the keyboard still works but just X is frozen, you may still have options.
21:11 Lyude: if you got into X there is one, journalctl -b -e --lines all _COMM=gdm-x-session
21:11 Lyude: once you're logged in
21:11 annadane: okay.
21:11 annadane: that's a start.
21:11 annadane: it's so hard to debug these things because no one usually has any idea
21:11 Lyude: i mean, we wrote the drivers ;)
21:12 bobnode: Lyude - Will do. stupid systemd hiding all the logs
21:12 annadane: gnarface, i'm not even sure if the keyboard works; trying to access a virtual terminal doesn't work
21:12 orbea: heh, journald was the straw that broke the camels back for me :P
21:13 annadane: gnarface, REISUB in that order or (as i suspect) those are just various options?
21:13 gnarface: annadane: in that order, though i don't know for sure if they all still do anything.
21:14 gnarface: annadane: in that order, while holding alt+printscreen the whole time
21:14 annadane: what a bizarre fix
21:14 bobnode: Lyude https://paste.fedoraproject.org/paste/CjmZH5MqMZmlRarev-KWaw
21:14 bobnode: Lyude https://paste.fedoraproject.org/paste/1AYLg1CxPAN~rnVAkfXSOg
21:14 gnarface: annadane: it'll just reboot, and it only works if magic sysrq key is compiled into your kernel, but it is for most stock kernels.
21:14 gnarface: annadane: but that'll also tell you for sure whether your keyboard input is still being acknowledged; since you say the mouse input is, there is a good chance
21:15 Lyude: there is also a sysrq key to force a return to fbcon
21:15 annadane: honestly at this point i wonder whether switching to wayland would help... lol
21:15 Lyude: V I think it is
21:15 Lyude: (uppercase)
21:15 gnarface: annadane: then you can figure out if the real reason you can't get to a virtual terminal is because it's disabled by default in your xorg conf for one reason or another - then you can re-enable it and go back to trying to debug the frozen Xorg issue from the second virtual terminal
21:15 Lyude: annadane: on KDE? no your life will be worse
21:15 Lyude: plasma's getting there but it definitely isn't there yet with wayland
21:16 annadane: shame
21:16 pmoreau: karolherbst: I pushed a few changes to SPVTES; I added two control flow tests as well. loop_with_if will completely fail, due, I think, to an issue with the buildLiveSet function in RA, but I might be doing something wrong with the BBs.
21:16 annadane: it's good at virtually everything else
21:17 karolherbst: pmoreau: I could try to take a look
21:17 Lyude: also bobnode btw, journalctl is pretty nice if you learn more about it anyway
21:17 karolherbst: pmoreau: one thing: is it possible to visualize the spirv somehow?
21:17 Lyude: i totally see what you're talking about, there's no 1080p listed in those modelines
21:18 karolherbst: would be even more awesme if we would do that through NV50_PROG_DEBUG
21:18 Lyude: what is your actual monitor setup like?
21:18 pmoreau: karolherbst: Whenever you have to time. I plan to have a look at it pretty soon otherwise.
21:18 karolherbst: ?
21:19 bobnode: @Lyude - Sorry for getting off topic. At the moment, just the laptop display, no external.
21:19 karolherbst: I also meant like if some of the spirv tools can do that
21:19 pmoreau: karolherbst: You can pass CLOVER_DEBUG=spirv CLOVER_DEBUG_FILE=somefilenamewithoutextension, and it will dump it in textual format.
21:19 Lyude: ergh, anyone remember the debug option in nouveau that makes it print (and only print) "subdev ____ initted in 5ms" messages for all of the subdevs so I can see the order they get setup in>
21:20 Lyude: bobnode: alright. i have some ideas why this might be happening, but nothing concrete. wonder if I can copy your monitor and reproduce it here at some point
21:20 pmoreau: karolherbst: Otherwise, spirv-dis will output the textual representation of a SPIR-V binary.
21:20 pmoreau: https://github.com/kbenzie/vim-spirv if you are using Vim
21:20 Lyude: bobnode: hold on, going to have you try something real quik
21:21 bobnode: @Lyude - okay!
21:23 Lyude: bobnode: oh
21:23 Lyude: when was the last time you updated this machine?
21:23 Lyude: or is that just an old kernel you're in right now
21:24 bobnode: Lyude 4.13.15-200.fc26.x86_64
21:24 Lyude: OH, i'm looking at the build os for your xserver
21:24 Lyude: whoops
21:25 Lyude: hm, i just realized this might not even be nouveau's fault
21:25 Lyude: bobnode: can you get me the output of /sys/kernel/debug/dri/0/i915_display_info ?
21:26 Lyude: (if that file isn't there, try dri/1 instead)
21:29 annadane: i guess for now i'll just install the fucking proprietary nvidia bullshit
21:29 annadane: i don't tend to have problems with it, i just don't like using closed source anything because you don't know if it's spying on you
21:29 karolherbst: Lyude: reviewing your patches :D
21:30 Lyude: karolherbst: oh neat! they've still got a ways to go but I pushed a corrected version of programming cg_ctrl for kepler
21:30 bobnode: Lyude - dri/0 = https://paste.fedoraproject.org/paste/ywowNW2GKrzN0M7CEpz06g
21:30 Lyude: turns out we had the programming sequence wrong for kepler1 as well, it just never caused any problems on my GPU somehow
21:30 Lyude: and since I kind of just dropped most fermi related code other then the mmiopacks, we can actually follow the new cg programming style the blob follows
21:31 Lyude: knew it. bobnode, you're going to want intel-gfx for this :)
21:31 Lyude: #intel-gfx
21:31 Lyude: nouveau's not driving the display here
21:32 bobnode: Lyude - Correct - is funneled through the intel bits. Ok, will try over there. Thanks for the helps!
21:32 Lyude: np
21:33 bobnode: :)
21:34 yann-kaelig: Hi
21:35 Lyude: btw karolherbst, those patches will probably get changed again in the future, but testing helps greatly
21:35 yann-kaelig: I want to be sure I'm not goign to make a mistake, but nouveau has or not mesa opencl support ?
21:35 Lyude: i've only really run this on my gtx760
21:35 imirkin_: yann-kaelig: no opencl/clover with nouveau
21:35 pmoreau: yann-kaelig: Currently not, but being worked on.
21:35 pmoreau: Not sure when it would land though
21:36 yann-kaelig: ok, I see. thx for the clarification.
21:37 imirkin_: probably not relevant, but opengl compute does work just fine
21:37 imirkin_: [on GF100+]
21:45 annadane: anyway, thank you guys for doing what you do. it's not your fault nvidia won't cooperate
22:05 Lyude: karolherbst: thanks for the review btw
22:05 Lyude: will do those changes the next time I rebase
23:05 yann-kaelig: nvidia driver use the mesa-opencl library or has his own opencl ?
23:06 pmoreau: It has its own implementation, part of the CUDA toolkit IIRC
23:07 pmoreau: Which is limited to 1.1 on most hardware; some cards have access to 1.2, but there is no support for higher versions though they started adding some 2.0 features recently.
23:07 yann-kaelig: so i'm a little lost because everything start to be very complicated in the world of graphics, what for the libclc in this case ?
23:08 yann-kaelig: libclc currently supports the AMDGCN, and R600 and NVPTX targets, NVPTX is not for nvidia driver ?
23:16 koz_: yann-kaelig: NVPTX needs the Nvidia blob.
23:16 koz_: AFAIK, Nouveau doesn't support it.
23:18 yann-kaelig: ok, thx. I really try to understand all of this but when I 'm watching the present linux graphic stack I have headaches
23:18 yann-kaelig: :)
23:32 pmoreau: Nouveau does not support PTX as input format, for sure.
23:33 pmoreau: I am quite sure that the NVPTX target is used by clang when consuming CUDA kernels, but the CUDA toolkit is still needed to compile the PTX code into an actual GPU binary.
23:34 yann-kaelig: well, another thing and bas news, I tried nouveau with KDE, but that doesn't work. After the display manager everything freeze
23:34 yann-kaelig: s:d:
23:34 pmoreau: Yeah, this is well known sadly (if it’s the bug I am thinking of)
23:40 koz_: pmoreau: What bug? I use KDE with Nouveau, and aside from some rendering weirdness, I get no issues.
23:41 pmoreau: koz_: With Nouveau being the card driving the screen, not an Intel + Nouveau combo?
23:41 koz_: pmoreau: Yeah, Nouveau driving the screen.
23:41 koz_: (screens, to be exact, since I have two)
23:42 pmoreau: KDE/Qt ends up triggering some races inside Nouveau IIRC, because of some multi-threading rendering or context sharing between multiple threads.
23:42 annadane: i think mine is intel + nouveau combo and i get freezing issues on kde as well
23:42 koz_: pmoreau: What sort of symptoms does this exhibit?
23:43 annadane: the processor is intel, graphics card is nvidia
23:43 imirkin_: annadane: does the intel gpu drive everything?
23:43 imirkin_: oh
23:43 annadane: imirkin_, don't know how to check
23:43 koz_: The only weirdness I've ever seen with KDE and Nouveau was that occasionally, I get some weird rendering issues when alt-tabbing.
23:43 imirkin_: annadane: pastebin xorg log
23:43 koz_: (like, the window only partly redraws)
23:43 imirkin_: koz_: with DRI3 enabled?
23:43 koz_: imirkin_: Nope, it's not stable with DRI3.
23:44 annadane: imirkin_, okay, but i'm currently using the proprietary drivers, not sure if nouveau needs to be active for you to see the log
23:44 koz_: (I've tried a few times, and I get all kinds of wtf madness)
23:44 pmoreau: koz_: The whole thing dying/freezing IIRC
23:44 imirkin_: annadane: ah, then nevermind. it would be, but no real reason for you to switch.
23:44 koz_: pmoreau: I get that if I enable DRI3.
23:44 imirkin_: koz_: yeah, afaik KDE + DRI3 = major fail with nouveau
23:44 annadane: if it's a well known bug it at least gives some hope it might be fixed in future
23:44 imirkin_: i dunno whose fault it is
23:44 koz_: imirkin_: Oh, that I have observed.
23:44 imirkin_: i assume nouveau's
23:44 pmoreau: Ah, I always forget that DRI3 needs to be part of the equation.
23:45 imirkin_: apparently EXA-based drivers can't properly support DRI3
23:45 koz_: But I do still get that alt-tabbing weirdness.
23:45 imirkin_: (according to MrCooper, who i tend to trust in such matters)
23:45 annadane: nothing else for me is wrong with nouveau + kde aside from the random freezing
23:45 annadane: it's annoying how there's not a simple solution
23:46 imirkin_: yes, sadly anything with "random" as part of the description will rarely have a solution
23:46 imirkin_: not to mention a simple one
23:47 annadane: i did try ctrl alt f3 and ctrl alt f1, didn't work