02:06 pmoreau: ashmew2: Could you give a link to the output of dmesg please? And which version of Mesa are you running?
02:15 ashmew2: pmoreau: Thanks for the response! I'm on gentoo with mesa 11.0.6 .
02:15 ashmew2: I'm currently installing 11.1.1 (testing).
02:19 ashmew2: I\ll post the dmesg in a bit, I reconfigured my kernel in the middle so logs are tainted with NVIDIA.
02:19 pmoreau: Ok :-)
02:20 pmoreau: DRI_PRIME=1 was the one with the vendor string "Nouveau" I guess?
02:20 ashmew2: pmoreau: Yes
02:20 ashmew2: brb, rebooting
02:23 ashmew2: https://bpaste.net/show/67a3b3ae8081
02:23 ashmew2: Back
02:23 ashmew2: That's the link for dmesg | wgetpaste
02:25 ashmew2: pmoreau: Do you need any logs with mesa 11.0.6 ? I'm gonna build 11.1.1 now. (Just to be sure)
02:27 ashmew2: I remember submitting a raw dump for my Geforce4000MX card a long long time ago, this has come so far now : )
02:46 pmoreau: ashmew2: Sorry, was doing some coding and completely forgot to have a look at IRC… Having a look at your dmesg
02:47 pmoreau: ashmew2: The NVIDIA kernel still gets loaded, you need to blacklist it
02:47 ashmew2: pmoreau: sure. I'll add a rule to modprobe
02:48 pmoreau: Is the screen plugged into the NVIDIA or the Intel card?
02:49 ashmew2: pmoreau: Intel card.
02:50 pmoreau: Could you paste your Xorg.0.log as well please?
02:52 ashmew2: https://bpaste.net/show/5b7013d3c2d8
02:52 ashmew2: Xorg.0.log , pmoreau
02:52 pmoreau: Thanks
02:52 ashmew2: ill just do a quick reboot, i blacklisted nvidia
02:53 ashmew2: Also upgraded to mesa 11.1.1, but it still shows version 2.1
02:55 ashmew2: back
02:55 pmoreau: Still the same?
02:56 ashmew2: $ DRI_PRIME=1 glxinfo | grep -i version | grep -i opengl
02:56 ashmew2: OpenGL version string: 2.1 Mesa 11.1.1
02:56 ashmew2: OpenGL shading language version string: 1.30
02:56 ashmew2: OpenGL ES profile version string: OpenGL ES 2.0 Mesa 11.1.1
02:56 ashmew2: OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
02:56 ashmew2: yup... :(
02:56 pmoreau: What about vendor string and renderer string?
02:57 Tom^: are you sure you are building mesa with the right flags?
02:57 ashmew2: server glx vendor string: SGI
02:57 ashmew2: client glx vendor string: Mesa Project and SGI
02:57 ashmew2: OpenGL vendor string: nouvea
02:57 ashmew2: OpenGL renderer string: Gallium 0.4 on NVC1
02:58 ashmew2: Tom^: hmm, I'm not sure, on gentoo I just do an emerge with VIDEO_CARDS set to "nouveau intel"
02:58 karolherbst: float stuff
02:58 ashmew2: Tom^: Can I alter some OpenGL related flags?
02:58 ashmew2: karolherbst: sorry?
02:58 pmoreau: I guess you already had a look at http://nouveau.freedesktop.org/wiki/Optimus/#offloading3d ?
02:58 karolherbst: ashmew2: do you compile mesa with --enable-texture-float?
02:58 Tom^: karolherbst: knows more, i dont use gentoo. but you want --enable-texture-float etc.
02:58 ashmew2: pmoreau: yeah, that's how I started using DRI_PRIME
02:59 karolherbst: ashmew2: -bindest on gentoo
02:59 karolherbst: *bindist
02:59 ashmew2: karolherbst: I didn't add it explicitly, no
02:59 karolherbst: if you compile mesa with bindist you only get 2.1
02:59 ashmew2: https://packages.gentoo.org/packages/media-libs/mesa according to this page, bindest is a local flag for mesa
02:59 ashmew2: bindist*
03:00 karolherbst: yeah I know, but is it set for you?
03:01 pmoreau: Oh true, I had forgotten about this --enable-texture-float
03:01 ashmew2: USE="bindist mmx sse sse2 dbus sqlite X apng alsa pulseaudio policykit cups gtk3 acpi kms static-libs tools uvm abi_x86_32 multilib"
03:01 karolherbst: there is this nice "$(use_enable !bindist texture-float)" thing in the mesa ebuild
03:01 karolherbst: ;)
03:01 ashmew2: that's my make.conf from portage, it is set
03:01 karolherbst: why do you have bindist set?
03:02 karolherbst: do you distribute your binaries?
03:02 ashmew2: karolherbst: no distribution, only use :D
03:02 karolherbst: yeah then -bindist
03:02 ashmew2: so I change the make.conf from bindist to -bindist
03:02 karolherbst: bindist is only important if you don't want to dig into all that legal stuff, but if you don't give your binaries away, it doesn't matter anyway
03:02 karolherbst: yeah
03:03 karolherbst: bindist is used to disabled patented code and stuff
03:03 karolherbst: to make binaries safe to be distributed for everybody
03:03 karolherbst: and all kind of other stuff
03:03 ashmew2: Got it! Thanks for the explanation.
03:03 pmoreau: ashmew2: You'll need the package "libtxc_dxtn" (or similarly named), since S3TC is used by games for compressing textures.
03:03 ashmew2: now I do a emerge --changed-use =mesa-11.1.1
03:04 ashmew2: pmoreau: ok, Sure, I'll install it if it's not already there.
03:05 ashmew2: pmoreau: The game already works when I use the intel card (but it stutters a lot)
03:05 karolherbst: yeah libtxc_dxtn may improve performance
03:05 karolherbst: and sometimes it only fixes visual artefacts
03:05 pmoreau: ashmew2: You won't have reclocking on your NVIDIA card though
03:06 ashmew2: pmoreau: I think so, this machine is about 4 years old.
03:06 ashmew2: I tried using the NVIDIA drivers, they crash and my X goes down along with sound and everything.
03:06 ashmew2: SSH still works so the kernel is alive
03:07 pmoreau: My point was more: almost all Tesla cards have reclocking support in Nouveau, Kepler cards also, but Fermi ones, not yet.
03:08 ashmew2: Got it.
03:08 ashmew2: I also tried doing a switch to NVIDIA driver-install opengl libraries and use those with nouveau
03:08 ashmew2: It fails terribly.
03:09 karolherbst: yeah you can't mix those
03:10 ashmew2: I really find nouveau interesting tbh, do you guys need a C developer?
03:11 ashmew2: Gallium architecture looks a lot better than conventional DRI.
03:12 pmoreau: We certainly welcome more contributors! :-)
03:13 ashmew2: Cool! I'm kinda lost in http://nouveau.freedesktop.org/wiki/Development/ though. .
03:14 pmoreau: We have an ever-expanding todo list here: https://trello.com/b/ZudRDiTL/nouveau
03:15 ashmew2: pmoreau: Thanks! I'll look through it and find something that I can do
03:16 pmoreau: In which area would you rather work: kernel side (reclocking, power/clock gating, or fixing bugs) or user-space side (new OpenGL extensions, running OpenCL kernels, fixing bugs)?
03:17 ashmew2: pmoreau: I think the kernel side is more inviting :D
03:17 pmoreau: Eh eh! :-)
03:17 ashmew2: I have some experience with the network stack, but I think i can grasp the graphics stack
03:18 karolherbst: ashmew2: well if you want to help I would rather looking into issues you got yourself
03:18 karolherbst: so that you won't easily give up when you don't understand everything at first, because you have the motiviation to fix that bug
03:18 karolherbst: and in the meantime you learn all the other stuff you need to know ;)
03:18 karolherbst: I don't feel like that digging into a bunch of docs first helps much
03:19 ashmew2: karolherbst: I completely agree. Relevant experience is important.
03:19 ashmew2: But I think I can try to understand the basic graphics stack in Linux still.
03:19 karolherbst: and I still have no big clue about that :/ :D
03:19 ashmew2: XD
03:20 ashmew2: karolherbst: btw, maybe offtopic, but do you think Gentoo really lets you explore more of the kernel/low level stuff compared to other distros?
03:20 karolherbst: ashmew2: depends
03:20 karolherbst: ashmew2: if you use genkernel.... then most likely not
03:20 Tom^: there comes a point when you realize distro doesnt matter and linux is still linux.
03:20 Tom^: its all just a matter of which distro is the least in the way of your preferences :P
03:20 karolherbst: well you can compile your own kernel on every distribution
03:21 karolherbst: I think gentoo makes a good job in forcing you to learn all that kind of stuff
03:21 ashmew2: yeah, that's true.
03:21 karolherbst: also
03:21 karolherbst: -* helps a lot with this
03:21 ashmew2: From my personal experience, I really feel Gentoo's forcing me into learning a lot of kernel stuff I wouldn't pick up on Arch
03:21 karolherbst: because you always have to deal with USE flag stuff and read up what the various things are for and stuff
03:22 ashmew2: Tom^: I agree with that point as well. Although some distros are way more difficult to customize than others (Yes im bashing Ubuntu)
03:23 Yoshimo: ashmew2: there are distros for every taste
03:23 ashmew2: Yoshimo: yes, and individual preferences are the deciding factor. I understand.
03:24 ashmew2: Even non linux stuff is decent at times, I hack at KolibriOS in spare time (it's written in assembly completely, no C)
03:25 Yoshimo: i like my Kubuntu, although with experimenting with nouveau and gallium-nine it can get a bit messy at times.
03:27 ashmew2: The last breakage I had with ubuntu was mostly due to the fact that I wanted to get rid of Unity. I broke too much stuff which begged a reinstall.
03:27 ashmew2: OK, emerge done
03:28 ashmew2: https://bpaste.net/show/b39b7490847c
03:28 pmoreau: Ah ah ah! Really nice joke! http://phoronix.com/scan.php?page=news_item&px=Croteam-Vulkan-Screenshot
03:28 ashmew2: weeeeeeeeeeeeeeeeeeeeeeeee
03:28 karolherbst: pmoreau: :)
03:29 pmoreau: ashmew2: 4.1 seems better ;-)
03:29 ashmew2: A LOT BETTER :D
03:29 ashmew2: Thanks guys!
03:29 ashmew2: Ill try running steam, just to be safe. . .
03:30 ashmew2:'s heart thumps...DRI_PRIME=1 steam
03:30 pmoreau: 4.2 should be around quite soon IIRC, and 4.3 in some not too distant future
03:30 pmoreau: ashmew2: For steam, you need Mesa in 32-bit, do not forget that
03:30 ashmew2: I forgot, need to run xcompmgr otherwise windows are not rendered.
03:31 ashmew2: pmoreau: yes, I already set up the 32 bit stuff
03:31 ashmew2: pmoreau: by mesa in 32-but you mean the libGL 32 bit libs right?
03:31 pmoreau: Right
03:32 pmoreau: And you might also want libtxc_dxtn in 32-bit
03:32 ashmew2: DAYUMMM, the game ran!
03:32 ashmew2: Sure, I'll look into it
03:32 ashmew2: Btw, the machine hangs if I use NVIDIA driver in a few minutes
03:33 pmoreau: Great if Nouveau works better!
03:35 ashmew2: Sorry about that, something didnt work out right..black screen and everything disappeared
03:35 ashmew2: I connected to my emacs server on a tty so that I won't get dropped again. I'll try again and log steam output.
03:35 karolherbst: then you got your first task ;)
03:36 ashmew2: karolherbst: :D
03:36 Caspear1: I have one of those laptops with both an Intel and an NVIDIA GPUs. How can I tell/control which is used for what?
03:37 ashmew2: Caspear1: if you are using nouveau, you basically dictate that using DRI_PRIME switch
03:38 ashmew2: Caspear1: have you already set up the xrandr setprovideroffloadsink bridge between both your cards?
03:38 Caspear1: ashmew2: No idea? Whatever the stock F23 does.
03:40 ashmew2: Caspear1: try xrandr --listproviders . It will tell you about some stuff.
03:40 ashmew2: If you paste it here, I can maybe help you to get started ;)
03:41 Caspear1: Long lines:
03:41 Caspear1: Provider 0: id: 0x8c cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 3 associated providers: 2 name:Intel
03:41 Caspear1: Provider 1: id: 0x66 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 5 associated providers: 2 name:nouveau
03:41 Caspear1: Provider 2: id: 0x66 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 5 associated providers: 2 name:nouveau
03:42 ashmew2: Caspear1: cool, so you already have both of them set up.
03:42 Caspear1: If you say so :-)
03:42 ashmew2: Caspear1: try glxinfo | grep -i renderer
03:43 Caspear1: OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
03:44 Caspear1: I guess it is set to use the Intel chip?
03:44 ashmew2: Caspear1: now do DRI_PRIME=1 glxinfo | grep -i renderer
03:45 Caspear1: Ooooh
03:45 Caspear1: OpenGL renderer string: Gallium 0.4 on NVC1
03:46 Caspear1: This was way easier than I expected! :-D
04:31 karolherbst: imirkin_: where is the fragmant shader be uploaded or like configured or whatever? I see some ZCULL_MASK writes there, in the near of RASTARIZE_ENABLE and some CB_ stuff
04:59 karolherbst: mhh found it that unk0360 and uink0364 look somehow suspicious :/
05:01 karolherbst: nouveau currently sets a static value into 0x0360 but the binary driver uses different values, would be nice to know what that is
06:11 ashmew2: Hey
06:11 ashmew2: Caspear1: Sorry about that, X crashed, did you figure it out?
07:34 ashmew2: Looks like when the driver crashes, the kernel goes with it. I checked dmesg over ssh before the machine died, it's a kernel NULL pointer dereference.
07:34 ashmew2: pretty sure this was the same thing happening with official NVIDIA driver as well, so it has to be some common part...
07:35 ashmew2: nouveau_fence_work + <offset>
07:49 Tom^: ashmew2: get a newer kernel, 4.0.5 is quite old
07:53 ashmew2: Tom^: 4.4 sounds okay?
07:53 Tom^: sure
07:55 Tom^: ashmew2: your xorg server is old too :p
07:56 Tom^: ashmew2: and your xf86-video-nouveau or what its named in gentoo is a version behind ;)
07:57 ashmew2: Tom^: hehe, sure! I'll update everything to bleeding edge.
07:57 Tom^: i would make sure intel is up to date aswell
07:57 Tom^: then see if it crashes and start debugging it
07:57 ashmew2: I think I'll grab all the testing packages from upstream
07:59 ashmew2: This is what I could manage; http://imgur.com/ohOQtBE
07:59 ashmew2: After this the SSh also broke.
08:26 imirkin: gnurou: whatever's required to operate it... i assume just the 3d class interface, but if there's more to it, then yes please :)
08:51 imirkin: ashmew2: unless you have screens connected to the nvidia chip, i would recommend looking at the DRI3 portion of http://nouveau.freedesktop.org/wiki/Optimus/
08:51 imirkin: ashmew2: note that it will require a dri3-enabled intel ddx, which by default, it is not in gentoo.
09:04 pmoreau: How does NV50 IR deal with something like: `vec4 foo = vec4(1.0, 2.0, 0.0, 3.0); out vec4 color; void main() { color = foo; }`?
09:05 pmoreau: I wanted to create `Value`s for `foo` outside of `main`, but that doesn't work since `new_LValue` takes the current function and uses it to retrieve the program.
09:57 imirkin: pmoreau: normally everything is inside of the MAIN function
09:57 imirkin: pmoreau: which is artificially created by the from_tgsi code
09:58 pmoreau: I tried putting it in the main, but then emit complained loudly while emiting a store to const memory :-D
09:59 imirkin: pmoreau: right, you can't emit to const memory
09:59 imirkin: pmoreau: er, store
09:59 imirkin: pmoreau: i think you wanted a gpr :)
09:59 imirkin: pmoreau: const = uniforms
09:59 pmoreau: Hum.
09:59 pmoreau: I know that ;-)
10:00 imirkin: you can't write to it from the shader
10:00 imirkin: if you want to anger a lot of opts, you could instead store to local memory
10:00 imirkin: but then you'll miss out on lots of optimizations... memoryopt tends to take care of it, but it runs late in the opt cycle
10:00 pmoreau: Right, but you should be able from OpenCL or CUDA
10:02 pmoreau: So I probably need to tweak the code, since GLSL can't… Not even with compute shaders?
10:04 pmoreau: Mmmh… I'll have to check what the blob does.
10:08 imirkin: pmoreau: no, you can never write to uniform data
10:08 imirkin: pmoreau: certainly not from opencl or cuda either. the whole point of it is that it's uniform. constant.
10:09 pmoreau: Well, you still have to initialise it. :-)
10:09 imirkin: not from the shader.
10:09 pmoreau: I have to "extract" the const init from the kernel code, and put that in a const buf
10:09 imirkin: mmmmmm you mean like
10:09 imirkin: uniform int foo = 1
10:09 imirkin: then yes, that needs to be pulled out
10:10 imirkin: but if you mean "const int foo = 1", then that's not a uniform/const at all
10:10 imirkin: that's just a value in the program, stick it into a gpr and move on.
10:10 pmoreau: Right, `uniform int foo = 1`. I realise I had forgotten it in my example
10:11 imirkin: yes, in that case it has to go into a constbuf. but more than that, only if it hasn't been overridden by something else.
10:11 Caspear1: ashmew2: Yes, I have, thank you!
10:11 imirkin: more generally, this is not something you need to worry about... it should be taken care of by a higher layer.
10:11 pmoreau: Well, I do get it in the SPIR-V code
10:13 orbea: imirkin: is this backtrace of a mpv segfault helpful? Seems to be a nouveau issue according to the error? http://pastebin.com/5mi2RYq6
10:14 orbea: it doesn't reproduce everytime
10:20 karolherbst: pmoreau: so you basically get something like mov c[somewhere] in SPIR-V? mhh maybe you could just move the initial value into a gpr and just reference to this in later references? But it would be interessting to know what the blob would do in such a case, yes
10:21 orbea:reads the bttrace better and thinks he needs to rebuild some things with debugging support...
10:23 pmoreau: karolherbst: This is the SPIR-V I'm trying to parse: https://phabricator.pmoreau.org/P87 (basically `__constant int4 val = { 0, 1, 2, 3 }; __kernel void const_vec_load(__global int* out) { out[0] = val.x; … out[3] = val.w; }
10:25 pmoreau: I could just link the variable %10 to constant %9, rather than trying to *physically* do the initialisation, maybe.
10:25 karolherbst: well if it's a constant then you could also just immediate the value I guess
10:26 karolherbst: or are these constants changed later?
10:28 pmoreau: The constants aren't changed late :-D
10:28 karolherbst: this SPIR-V stuff looks a bit strange
10:28 pmoreau: s/late/later
10:28 karolherbst: mhh but I think I got it now
10:28 karolherbst: looks somehow functional to me
10:29 karolherbst: okay
10:29 karolherbst: yeah well, then if they are constant then just do like imirkin said: mov $r constant
10:30 karolherbst: and "%5 = OpConstant %2 0" should get like mov $r5 0
10:30 pmoreau: That I already have :-)
10:30 karolherbst: k
10:30 karolherbst: so %9 is the problem
10:30 pmoreau: It's the "%10 = OpVariable %4 UniformConstant %9" which is problematic, due to the indirection
10:30 karolherbst: $r9 = { $r5 $r6 $r7 $r8 } right?
10:30 pmoreau: OpVariable being a pointer
10:30 pmoreau: Yep
10:31 karolherbst: and %10 is a pointer to %9?
10:31 pmoreau: Right
10:32 karolherbst: is SPIR-V SSA?
10:32 pmoreau: I could detect on "%17 = OpLoad %3 %10 Aligned 16" that %10 is a uniformconstant var, and inline the pointed constant, that should work
10:32 pmoreau: Yes it is! Did you listen to my talk? :-P
10:32 karolherbst: because then you might could just drop %10 completly and rewire all %10 to %9 "somehow"
10:32 karolherbst: I just want to be sure before talking garbage :D
10:33 pmoreau: No problem :-)
10:33 karolherbst: sometimes I don't remember stuff quite well ;)
10:33 karolherbst: it obviously looks pretty SSA anyway :D
10:34 pmoreau: Wasn't it you who suggested to bypass the initial passes on NV50 IR that were not on SSA form, and skip directly to when NV50 IR is in SSA?
10:34 karolherbst: pmoreau: is there some kind of reflection possible in SPIR-V? like get the type of that value?
10:34 RSpliet: pmoreau: what are you trying to convert this SPIR-V to?
10:34 karolherbst: pmoreau: could be
10:34 karolherbst: but I doubt it
10:35 pmoreau: RSpliet: To NV50 IR, but not sure if that's the answer you're looking for :-)
10:35 RSpliet: pmoreau: and is this the flat token representation, or do you already have an AST of this?
10:35 karolherbst: pmoreau: you know what, just build a plain nv50 SSA out of that
10:36 pmoreau: karolherbst: I store the mapping type <-> id, so yes, I can retrieve the type
10:36 karolherbst: it makes no sense to convert it to non SSA nv50, then to SSA nv50, to convert it to a non SSA nv50 again
10:36 karolherbst: I think the non SSA nv50 part is only there because tgsi is somehow non SSA? or is it and I missed something
10:37 pmoreau: RSpliet: The paste is the decoding of the SPIR-V binary, since it's easier to read ;-) So flat token representation
10:37 pmoreau: TGSI is non SSA IIRC
10:37 karolherbst: yeah, looks like it anyway
10:37 karolherbst: yeah I would directly translate to SSA nv50, I guess it could spare you some pain
10:38 RSpliet: pmoreau: but do you have tree-wise representation of this? somehow that seems easier to transform to NV50IR than linearly going through the tokens
10:38 karolherbst: the main opts are done on the SSA nv50 anyway
10:39 pmoreau: There is only `prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);` before going to SSA.
10:40 karolherbst: ohh I guess it builds the CG :)
10:40 karolherbst: yeah makes sense
10:41 pmoreau: RSpliet: I did build a tree representation in my first try, but switched to a linear traversal for the new version. So far it hasn't been much of a problem not to have a tree representation.
10:41 karolherbst: does tgsi comes with such a graph? I would expect not, because otherwise nobody would have to do that in nv50ir
10:43 pmoreau: It doesn't AFAICT, it is build while converting it in nv50_ir_from_tgsi.cpp
10:44 karolherbst: mhhh
10:46 karolherbst: maybe it would be possible to convert the SPIR-v tree into nv50ir BBs and wire up the dependencies SSA like. I don't know what would make more sense in the end, but I think this could mean less compiler overhead in the end, which isn't as unimportant as with OpenGL
10:55 pmoreau: I'm not sure I followed you there: you mean building the cfg and placing the phi node in nv50 IR ?
11:08 pmoreau: Argh, time to stop coding/thinking and have a break.
11:09 pmoreau: Cleaning up the code should help, but on the other hand, it's probably better to think about this unseen case before cleaning.
11:09 pmoreau: Will see
11:14 karolherbst: pmoreau: I meant to convert SPIR-V to a nv50ir with all the CFG stuff
11:14 karolherbst: in SSA form
11:17 pmoreau: Ok. I should have the CFG stuff already, just miss the phi nodes.
11:17 pmoreau: (bbiab)
12:13 orbea: I upgrade my mesa install to the current git master with what I hope is proper debugging support and now I'm getting this error with mpv, any ideas? "Mesa: User error: GL_INVALID_OPERATION in VDPAUFiniNV"
12:13 orbea: *upgraded
12:14 orbea: only when using vdpau ofc
12:21 imirkin: orbea: that backtrace would have been useful if you had had symbols for libvdpau_nouveau and libdrm_nouveau. as-is, not sure what i could do with it.
12:21 imirkin: pmoreau: i think that constant isn't what you think it is. it's probably a program const, not a uniform.
12:22 imirkin: pmoreau: skipping the pre-ssa codegen lowering passes won't work
12:22 imirkin: pmoreau: among other things, as part of doing ssa, lots of other stuff is done, like a dominator tree, etc.
12:22 orbea: imirkin: yea, I realized, I have those symbols now, but no segfault still
12:23 orbea: and i dont know gdb well info to get useful info on teh new error
12:23 imirkin: orbea: i'm insufficiently familiar with the NV_vdpau_interop stuff to comment.
12:24 orbea: ah
12:24 pmoreau: imirkin: Too bad for not being able to skip the lowering passes…
12:25 pmoreau: imirkin: No, it is a uniform const: both the pointer and the variable have their storage class set to uniform constant
12:25 imirkin: pmoreau: i mean, you could "skip" them, by taking everything they do and rewriting them as SSA-enabled versions
12:25 pmoreau: Would it be worth it?
12:25 imirkin: pmoreau: but let me tell ya - it won't be easy
12:25 imirkin: a whole bunch of those passes effectively alter (well, add) control flow
12:26 imirkin: and the nv50 ir does NOT like it when you do that once it's all SSA'd
12:27 pmoreau: Ack
12:49 orbea: imirkin: do you know where would be a good place to ask about that NV_vdpau_interop issue? #mpv did not seem to know either
12:56 imirkin: well presumably it's their code, so they should be able to debug it a bit
12:56 imirkin: or explain what they think mesa might be doing wrong
13:04 orbea: the mpv debugging output had apparently nothing interesting in it :/
13:05 orbea: this seems the most I got from them, but this is a bit over my head http://dpaste.com/079WXKX
13:05 orbea: after that it turned into "you should be using nvidia drivers" spiel...
13:07 imirkin: and from me you'll get the "you should be using mplayer" spiel :)
13:07 orbea: heh
13:07 imirkin: it's the only player that, in my experience, works reliably
13:07 imirkin: everything else fails at *something*
13:07 imirkin: (involving video decoding)
13:08 orbea: interesting, I guess I can give it another try
13:08 imirkin: (to be clear... mplayer. not mplayer2. not mpv. not mplayer-but-not-really. mplayer.)
13:23 karolherbst: funny, now I mmted another application and now the zcull stuff makes less sense :/
13:35 karolherbst: imirkin: does it matter if a value gets pushed through PUSH_DATA or IMMED_NVC0?
13:35 imirkin: no
13:35 imirkin: IMMED_NVC0 can only take values up to 0x2000 or so
13:35 karolherbst: so IMMED_NVC0 just safes a bit of bandwidth?
13:38 imirkin: just a more compact encoding, yes
13:38 imirkin: single fifo word vs 2
13:38 karolherbst: k, understoof
13:38 karolherbst: *understoof
13:39 karolherbst: anyway, that zcull buffer seems some kind of application global. In heaven the blob uses the same buffer always :/
13:39 karolherbst: allthough it changes the region, whatever that means now :/
13:42 imirkin: a single buffer may have multiple regions? dunno
13:44 karolherbst: mhh I kind of saw differences in the window offset or some other offset for each region
13:44 karolherbst: yes
13:47 karolherbst: and I think most data is still saved per region except the buffer now :/ having some docs on this would be really helpful
13:48 karolherbst: ohh, the ZETA_FORMAT changes after ZCULL_REGION changed
13:49 karolherbst: but no strong link between them
13:50 karolherbst: I am sure I am missing some interactions between ZCULL/RT[0]/ZETA :/
14:35 transhuman: hi getting a thermal error being logged and some reboots, that I think are related, but can't verify, getting a fan boost error that it has reached temperature 105 C this seems low to activate, does that mean its not configured, how do i verify that I have an overheat condition?
14:39 imirkin: transhuman: do you have a fan on your gpu?
14:39 imirkin: if it's getting to that temp that means that either we're messing up fan control royally, or there is no fan in the first place
14:43 transhuman: actually further investigation, fan is stuck, looks like its time for a new video card, sorry to be a bother
14:44 transhuman: I assumed it was a software glitch
14:44 transhuman: thanks
14:44 transhuman: have a good night
14:54 orbea: imirkin: I got the segmentation fault in gdb again with mpv, this time with mesa/libdrm debug sysmbols, is it more helpful? http://pastebin.com/T29aURxk
14:54 orbea: I also looked at the mplayer configure --help, im not so much a fan :P
14:55 imirkin: orbea: yes and no. yes, it's more helpful. but no, i have no clue why that'd be happening.
14:56 imirkin: orbea: use your distro's package manager to install it
14:56 orbea: I have my own slackbuild for the mpv git master
14:56 orbea: I'll show it to #mpv too
14:57 orbea: oh, you mean mplayer
14:57 orbea: yea, Im not so much a fan of the slackware one with samba and static ffmpeg
14:58 imirkin: ah
14:59 orbea: I also learned how to set breakpoints in gdb, so here is a backtrace for the "GL_INVALID_OPERATION in VDPAUFiniNV" http://pastebin.com/rZNG22Tp
14:59 karlmag: orbea: -14.1 or -current?
15:00 orbea: current, but a bit customized
15:00 karlmag: 'k
15:00 karlmag: just curious
16:15 ashmew2: imirkin: Yes, my card is connected to the Intel chip (not the nvidia chip).
16:16 imirkin: monitor, presumably
16:16 ashmew2: imirkin: ha, my screen* (forgive my early morning sleepiness)
16:18 ashmew2: Found DRI3, I will rebuild all the required stuff with DRI3.
16:18 ashmew2: brb, kernel change.
16:43 ashmew2: Got stuck with some kernel trouble, GRUB won't show the new 4.4 kernel. I modified the boot line manually for now so I can emerge stuff with DRI3
16:46 imirkin: ashmew2: iirc the xf86-video-intel ebuild does not allow you to enable dri3
16:47 imirkin: it just has a hard --disable-dri3 in there =/
17:34 gnurou: imirkin: I think there are some kernel bits required as well, let me ask... I actually think that's the kind of stuff we can help with, but let me make sure
17:35 gnurou: karolherbst opened an issue on Github, so now I won't forget about it (or will have no excuse if I do)
17:55 ashmew2: imirkin: Thanks for the info, i'll hack around with the ebuild and enable dri3
17:55 ashmew2: on xf86-video-intel
17:55 imirkin: cool
17:56 ashmew2: I'm guessing DRI3 will speed things up a bit more and there would be no null pointer exception. Possible reason of the null pointer dereference is that nvidia card is too fast for intel to offload?
17:56 imirkin: it will cause somewhat different code paths to be taken
17:57 imirkin: hopefully ones that don't destroy your box
17:59 ashmew2: My NVIDIA card used to work fine till a certain windows driver version -> update BSOD. After that I switched to Linux, used nouveau with a 2.6 kernel with DRI PRIME, I think it worked fine. Game update -> Stuttering unplayable. Now with 4.x , Null pointers ;D
17:59 imirkin: which GPU do you have btw? GF108?
18:00 ashmew2: GT 540M
18:00 imirkin: i don't think nouveau gained prime until 3.13 or so
18:00 ashmew2: hmm..then maybe it was a 3.x kernel, but from what I remember I was on 2.x for a long long time..maybe it was a 3.x
18:00 imirkin: ashmew2: does it say NVC1 or GF108 (those are the same)?
18:01 imirkin: anyways, it's not too important
18:02 ashmew2: OpenGL renderer string: Gallium 0.4 on NVC1
18:02 ashmew2: When I run glxinfo
18:02 ashmew2: I think it was always NVC1
18:03 imirkin: yeah. that's your actual gpu :) GT 540M is some marketing thing.
18:03 ashmew2: Wow, thanks for the info!
18:04 ashmew2: I even wrote bash/curl scripts to download all README.txt files from NVIDIA's ftp servers to isolate which was the oldest driver supported for GT 540M and downloaded it.
18:04 ashmew2: The FTP is slow :O
18:04 imirkin: anyways... just so you're aware, perf is likely to suck compared to blob, since we don't support reclocking on fermi gpu's
18:04 ashmew2: Everyone's talking about not supporting reclocking on fermi GPUs ;)
18:05 imirkin: i presume it's a laptop, which means it probably boots to the lowest perf level
18:05 ashmew2: imirkin: I think I won't have any issues with the performance with perf once these Null pointer dereferences go away. I've been having the same crashes with blob.
18:06 ashmew2: Whatever I want to do runs fine till the crash. I really feel if I could go back to a sufficiently old driver (Release date 2011 / 2012), that'll fix all issues for me.
18:06 imirkin: well, bugs get fixed, you were on a moderately old kernel before
18:07 imirkin: i guess you're on 4.4 now?
18:07 ashmew2: yes 4.4 now
18:07 ashmew2: Getting the intel ebuild so I can enable dri3
18:07 ashmew2: mesa already supports it, so I already added dri3 to mesa
18:07 ashmew2: Also, I'll update the video drivers (intel and nouveau) to latest (testing)
18:08 imirkin: sounds good
19:19 ashmew2: How can I make sure I'm using DRI3 ?
19:22 sarnex_: ashmew2: run LIBGL_DEBUG=verbose glxgears
19:22 sarnex_: libGL: Using DRI3 for screen 0
19:23 ashmew2: libGL: Using DRI2 for screen 0
19:23 sarnex_: did you set Option "DRI" "3" in your nouveau.conf?
19:23 ashmew2: ah, no I didn't!
19:23 sarnex_: :)
19:23 imirkin: nothign to do with nouveau actually
19:24 imirkin: it's the intel ddx that must be set for it
19:24 ashmew2: I already built the intel driver with --enable-dri1
19:24 sarnex_: oh sorry i didnt know you have a 2 gpu system
19:24 ashmew2: --enable-dri3
19:24 ashmew2: sarnex_: no problem, thanks!
19:24 ashmew2: so how can I check it now?
19:25 sarnex_: set it in intel.conf
19:25 ashmew2: erm , locate intel.conf returns nothing..I'm sorry I just know about xorg.conf (and I'm not using it right now)
19:25 orbea: imirkin: the "GL_INVALID_OPERATION in VDPAUFiniNV" in mpv has a bad effect with nouveau, it spams dmesg and my syslog enough to fill up the partition and freeze my os with nouveau error message. Still not really sure its an mpv issue, but this mpv issue report has the details. https://github.com/mpv-player/mpv/issues/2798
19:26 sarnex_: ashmew2: something like this http://pastebin.com/raw/srzyXzZe
19:26 sarnex_: ashmew2: by intel.conf i mean make an intel.conf in the folder that xorg will scan for conf files
19:26 sarnex_: for me on gentoo its /etc/X11/xorg.conf.d/
19:27 ashmew2: sarnex_: ah ok! I understand.
19:28 ashmew2: I'm on gentoo too, and yeah I know that dir :)
19:28 sarnex_: :)
19:28 ashmew2: okay done
19:28 ashmew2: and There's no way to switch without a startx?
19:29 ashmew2: something like xsource intel.conf ? LD
19:29 sarnex_: yeah you have to restart X
19:35 ashmew2: sarnex_: Thanks! on DRI3 now.
19:35 sarnex_: ashmew2: cool glad it works
19:35 ashmew2: so building mesa with DRI3 worked after all
19:40 ashmew2: Ill try to run with PRIME=1 again, and see how it crashes this time :)
19:41 sarnex_: DRI3 doesnt require you to set the sink with xrandr anymore
19:41 sarnex_: its automagic
19:41 ashmew2: woah
19:41 ashmew2: cool
19:41 ashmew2: erm, but I think I already set it earlier
19:41 ashmew2: do I need to revert/change xrandr?
19:41 sarnex_: i dont know if setting it is bad
19:41 ashmew2: ok, we'll know soon enough :)
19:42 ashmew2: ah, but restarting X resets xrandr as far as I know
19:42 ashmew2: and I can verify nouveau and i965 with glxgears.
19:44 imirkin: dri2 and dri3 aren't mutually exclusive
19:44 imirkin: if you set up the dri2 offloading, that's only used for dri2
19:44 ashmew2: That's even better!
19:45 ashmew2: imirkin: so should I just run my opengl stuff again? LD
19:45 ashmew2: ;D
19:45 ashmew2: ah! Using DRI3 fixes the need to run xcompmgr to draw windows.
19:46 ashmew2: but it keeps flashing a black window every 10 seconds or so on losing focus..
19:47 imirkin: weird
20:09 ashmew2: ok, almost 20 min into the game on nouveau
20:09 ashmew2: no lag
20:10 ashmew2: no crashes so far
20:10 ashmew2: A lot of fanboost related messages in dmesg, but I think thats just normal
20:15 ashmew2: Except for the flickering (game not affected, only drawing of menus, maybe it affects static objects?) everything else seems ok!
20:20 imirkin: cool. weird about the flashing.
20:25 ashmew2: it used to be completely black without xcompmgr and DRI2
20:25 ashmew2: so its a lot better
20:34 imirkin: dri2 requires a redirecting compositor for prime to work
20:41 ashmew2: so if I want to debug why the flickering occurs, what would be a good starting point? dmesg is clear..
20:44 imirkin: ashmew2: what version of the intel ddx is it exactly?
20:58 orbea: imirkin: do you mind also looking at this mpv isse? My referenced issue has the backtrace. https://github.com/mpv-player/mpv/issues/2757 You might have something worthwhile to add?
20:59 imirkin: orbea: interesting. i don't think i've seen bkref be 0 before
20:59 imirkin: let me double-check the code for which one that is...
21:00 orbea: one of the mpv devs linked one he suspected
21:00 orbea: https://github.com/grate-driver/libdrm/blob/master/nouveau/pushbuf.c
21:00 imirkin: yes, i mean it's from there
21:00 imirkin: but what does it mean :)
21:00 orbea: ah
21:01 imirkin: i added the assert iirc, but it was to prevent various badness from happening
21:01 imirkin: how is there even a relocation... you're on some modern(ish) gpu right?
21:01 imirkin: you must be if you're using vdpau
21:02 orbea: yea, gtx 780 ti
21:03 imirkin: yeah relocs were a thing for like geforcefx
21:03 orbea: that sounds strange then...
21:04 orbea: the crash doesn't happen very often that its important, but enough to notice it
21:06 imirkin: yeah, i mean it's clearly a nouveau issue
21:07 imirkin: but i haven't the faintest clue how it's happening
21:08 imirkin: iirc in your last trace you didn't have debug symbols for libdrm_nouveau
21:08 imirkin: er, in your last backtrace
21:09 orbea: Yea, I missed them, but then when I was failing to debug the other newer issue it came back and I got its backtrace with more symbols
21:09 imirkin: i haven't seen that.
21:10 orbea: i ended up spending a few hours rebuilding thing with debugging symbols and chasing mpv/nouveau bugs wiith gsb in tmux today...
21:11 orbea: gdb*
21:13 ashmew2: imirkin: its 2.99.917-p20160203
21:13 ashmew2: Its the latest available on gentoo amd64 testing
21:14 ashmew2: ^ intel DDx version
21:14 imirkin: ashmew2: hm ok. that's a pretty recent (albeit random) snapshot
21:25 ashmew2: imirkin: it was the newest I could find :)
21:28 imirkin: fwiw i'm using the 2.99.917 package and haven't seen the flickering issues
21:28 imirkin: whatever the regular gentoo amd64 one is, not ~amd64 iirc
21:29 imirkin: fwiw i also run with the xorg.conf setting AutoAddGPU set to false
21:29 imirkin: although if you use xorg 1.17.4 you need an extra patch for that not to super-break... hold
21:29 orbea: imirkin: could this be related? https://bugs.freedesktop.org/show_bug.cgi?id=92438
21:30 imirkin: orbea: oh hm, i forgot that mpv might be multithreading stuff. if they are, then nouveau will fail.
21:31 imirkin: orbea: or you can just mplayer :) works great.
21:31 imirkin: orbea: try to get a backtrace with libdrm_nouveau debug symbols as well
21:32 orbea: uh, how do I add them?
21:34 imirkin: check with your distro
21:36 orbea: slackware doesn't do that, I had my own libdrm slackbuild fora while, but I didn't see anything in the ./configure --help for debuggging
21:37 imirkin: do you strip debug symbols before installing?
21:37 imirkin: coz if you do, don't :)
21:38 orbea: no, I made sure not to strip them, but I guess that wasn't enough?
21:38 orbea: would it be as simple as a -g cflag?
21:38 imirkin: dunno, maybe it's fine
21:38 imirkin: i'm out
21:38 orbea: night
21:38 imirkin: good luck
21:39 orbea: thanks
21:39 imirkin: ashmew2: this is the autoaddgpu bug i had in mind: https://bugs.gentoo.org/show_bug.cgi?id=568272
21:41 ashmew2: Cool! I'll check it out