00:21njsg: Thanks for all the pointers, I'll write some notes tomorrow and let's see if I can try to at least understand a bit of this
00:24imirkin_: njsg: i owe danvet some tests on a pre-nv50 gpu, so i might just plug my nv44 in
00:27njsg: LCD backlights and/or its inverter started misbehaving, and that's why I connected this CRT. It's currently on 800x600, as IMHO the non-interlaced 1024x768 flickers too much.
00:29imirkin_: yeah, i might not be able to see any flickering
00:29imirkin_: since i have a flat panel
00:29imirkin_: but i can at least see if it works
12:46barteks2x: Not sure where would be a good place to ask, but recently (as in, after the last reboot) I can't get DRI_PRIME=1 to work (should use dri3, so it should just work). While I also do have official nvidia drivers installed on the system, they shouldn't be in use and nouveau used to work. But now I can't get it to work
12:49barteks2x: I had it working before with the same versions of everything
12:49barteks2x: and by "doesn't work" I mean "it has no effect"
13:27imirkin: barteks2x: LIBGL_DEBUG=verbose should provide more info
13:27barteks2x: I'm getting a bunch of messages like this "libGL: Can't open configuration file /etc/drirc: No such file or directory." but other than that, I don't see any real information
13:28barteks2x: and it just says it's using i965
13:29imirkin: pastebin the output of LIBGL_DEBUG=verbose strace -f -e file glxinfo > /dev/null
13:29imirkin: er, with DRI_PRIME=1 thrown in there too
13:31barteks2x: the only mention of nouveau I see is "openat(AT_FDCWD, "/usr/lib64/libdrm_nouveau.so.2", O_RDONLY|O_CLOEXEC) = 5", and that file exists
13:31imirkin: uhm. stupid question....
13:31imirkin: ls -l /dev/dri
13:32imirkin: nouveau's not loaded.
13:32imirkin: should load nouveau.
13:32imirkin: i hear that may be required :p
13:33barteks2x: I *think* it should be loaded, but I may be dumb and not remember how
13:33imirkin: the module's not loaded
13:33imirkin: or it's loaded and didn't recognize your device
13:33imirkin: dmesg should have more info
13:33barteks2x: modprobe nouveau should load it right?
13:33imirkin: should happen automatically though
13:33imirkin: unless you blacklisted it
13:33imirkin: (nvidia blob likes to blacklist)
13:34barteks2x: unloading and reloading it fixed the issue O.o
13:34imirkin: yay, problem solved.
13:34barteks2x: I honestly have no idea how that's possible. Maybe nvidia driver was loaded the first time I tried to load nouveau? I may need to properly configure blacklist
13:35barteks2x: I use nvidia gpu rarely enough that when I do need it, I can just load what's needed manually
13:36barteks2x: And apparently now with bumblebee official nvidia driver gives me *worse* performance than nouveau
13:47karolherbst: barteks2x: depends on the benchmark
13:48karolherbst: max fps is lower with bumblebee as there are more copies involved
13:48karolherbst: so yes, glxgears will be slower
13:48karolherbst: but everything where it matters will be faster
13:50karolherbst: barteks2x: anything using OpenCL or Cuda will trigger a load of the nvidia driver as well
13:51pmoreau: karolherbst: NVIDIA’s 441.x drivers have some additional OpenCL 2.0 support: device-side enqueue and SVM, just saw that in the release notes.
13:52karolherbst: there was SVM before that though
13:53karolherbst: pmoreau: I actually traced some SVM stuff with the 435 or 440 driver...
13:53karolherbst: could be they added it in 440 ...
13:53pmoreau: Ah, maybe they write it down in every release notes? I haven’t really looked at them before; I was looking for some info about some RTX improvements in that driver version.
13:54karolherbst: pmoreau: btw, any plan to continue working on your spirv clover support patches?
13:54pmoreau: Yes, I updated and recompiled the latest LLVM yesterday, with updated SPIRV-LLVM-Translator
13:54karolherbst: pmoreau: 441 is a special driver... could be their grid one? or windows?
13:54karolherbst: ahh, windows
13:55pmoreau: Maybe not today as I’ll be getting home late, but at least by the end of the week for updating the IL MR.
13:55pmoreau: Yes, Windows
13:55karolherbst: I didn't check when they added SVM to the linux driver, but it's just coarse buffer SVM
13:59pmoreau: Okay; they didn’t specify in the notes which type of SVM support they added.
13:59karolherbst: pmoreau: yeah, would be cool to get it done (the IL MR) so we can also run the CTS using that interface as well, also some might be interested in using this to get rid of an online compiler... ohh, maybe we could make the llvm integration optional then?
14:00karolherbst: no idea how badly this violates the spec though
14:00pmoreau: Hum, good question.
14:00karolherbst: but that would allow us to get rid of llvm entirely in the mesa build :D
14:00karolherbst: (well, ignoring radeonsi/r600)
14:01pmoreau: I think that might be doable for 2.1 or 2.2, when SPIR-V was introduced in core, but I don’t think that would fly for earlier versions.
14:01karolherbst: the 1.2 extension
14:02pmoreau: I don’t think the extension allows to get rid of the compiler, even if it’s allowing for SPIR-V.
14:02pmoreau: Also, we will still have the issue for 1.0 and 1.1.
14:02karolherbst: pmoreau: CL_COMPILER_NOT_AVAILABLE if program is created with clCreateProgramWithSource and a compiler is not available i.e. CL_DEVICE_COMPILER_AVAILABLE specified in the table of OpenCL Device Queries for clGetDeviceInfo is set to CL_FALSE
14:02karolherbst: from the 1.0 spec
14:02karolherbst: so we can :)
14:03karolherbst: that's from clBuildProgram
14:03karolherbst: there is still the interfaces to retrieve program binaries
14:03karolherbst: so we are all good in theory
14:03karolherbst: and we expose the spirv through them currently as well
14:03karolherbst: or the nir?
14:04karolherbst: but that's something I want to change later as well (moving the spirv->final program step further up and return the serialized program binary instead)
14:04pmoreau: Hum, but how useful would that be for 1.0 and 1.1 if you just give up on all programs given to compile?
14:05karolherbst: pmoreau: clCreateProgramWithBinary
14:05karolherbst: think about FPGAs as well
14:05karolherbst: they have extra tools to create such binaries
14:05karolherbst: and your application simply uses clCreateProgramWithBinary
14:06karolherbst: pmoreau: clover-online-compiler=full|spirv|none
14:06karolherbst: better interface
14:06pmoreau: Yeah okay, not sure if applications will decide to switch to using clCreateProgramWithBinary just for us. But on the other end, why use OpenCL on Nouveau.
14:06karolherbst: ohh, clCreateProgramWithIL can't fail due to that?
14:07karolherbst: pmoreau: no, it's more about not having a full LLVM compiler stack shipped
14:07karolherbst: think about containers on aarch64
14:08karolherbst: I mean, we don't have to support it now
14:08karolherbst: but that might be something we could add if it's not too difficult
14:10pmoreau: Good point
14:13karolherbst: mhh. I think getting rid of the OpenCL C/C++ compiler as the only option might be good enough already
14:13karolherbst: you don't really win that much stripping all of the compiler out of mesa
14:13karolherbst: especially because it's ton of work
14:13karolherbst: and spirv->final binary is cheap compare to compiling OpenCL C++ source code
14:13karolherbst: even when compiling OpenCL C
14:14pmoreau: I agree with the spirv->final binary being cheap compared to the ret.
16:06barteks2x: regarding me saying that I get better performance with nouveau than with nvidia+bumblebee: That was in Minecraft. I'm sure that with shaders with dynamic shadows or some other effects it would probably flip into nvidia being faster but with normal usage, it doesn't seem to be. I know glxgears is useless for benchmarks.
21:02pmoreau: And obviously I forgot to compile LLVM with RTTI support. Welp, I’ll look back on those patches tomorrow then.
21:03imirkin_: rtti isn't actually necessary
21:03imirkin_: someone just flipped it on
21:03imirkin_: it's only needed for a debug thing somewhere
21:03imirkin_: i'd rather you fix the stupid meson thing
21:04karolherbst: what stupid meson thing?
21:04imirkin_: someone said that nouveau can't build without rtti
21:04imirkin_: or without rtti being enabled in llvm
21:05imirkin_: it's not intrinsic to meson
21:05imirkin_: just how it's set up
21:05karolherbst: I think we require rtti in clover
21:05imirkin_: this was not the case with the autoconf rules
21:05imirkin_: that may be
21:05imirkin_: but not in nouveau
21:05imirkin_: there's a debug typesafety check somewhere
21:05imirkin_: and that's about it
21:06pmoreau: It is needed in clover, as it uses dynamic_cast. But yeah, Nouveau requires it as well apparently.
21:07karolherbst: pmoreau: only for debug builds
21:07imirkin_: but it doesn't _really_ erquire it
21:07karolherbst: is the bug
21:07imirkin_: it definitely doesn't require it in llvm
21:07imirkin_: it's highly internally-constrained usage
21:07pmoreau: Thanks, I was going to ask about the bug report link.
21:07karolherbst: imirkin_: ABI
21:07karolherbst: either all has rtti support or nothing
21:07imirkin_: please elaborate.
21:07karolherbst: rtti changes the C++ ABI
21:08imirkin_: does it though?
21:08imirkin_: first i've heard that said so definitively
21:08imirkin_: definitely you want to inspect rtti in one lib using the types of another lib, you have to have it enabled
21:09karolherbst: I could imagine that it doesn't happen with all compilers though
21:10pmoreau: Ah, I had forgotten about that typeid usage; I only looked for dynamic_cast.
21:10karolherbst: imirkin_: but apparently in the itanium ABI rtti changes the vtable layout
21:10imirkin_: hah. itanium.
21:10karolherbst: well, that's what gcc uses
21:10imirkin_: they get what they deserve!
21:12karolherbst: imirkin_: there was also a thread on libc++: http://lists.llvm.org/pipermail/cfe-dev/2017-May/053729.html
21:13karolherbst: maybe all compilers and c++ runtimes are fixed now... but.. well
21:13karolherbst: no fun debugging such issues
21:13imirkin_: heh. libc++. wtvr.
21:14karolherbst: the c++ spec should defined an ABI ...