00:48 foreverska: Is there anyone even kinda working on SLI support? I have the setup but nothing in the way of graphics drivers experience. Are there warlocks I can listen to while I get my bearings?
00:57 imirkin: foreverska: not to my knowledge
01:02 foreverska: :/ Guess I'll have to work for my beard. Find something a bit simpler to contribute to first and then I'll look at SLI.
01:03 imirkin: the tricky thing with SLI is figuring out how to actually split up a command stream into 2 workloads
01:04 imirkin: foreverska: if you're looking for some tasks, have a look at https://trello.com/b/ZudRDiTL/nouveau
01:04 imirkin: depending on what hw you have, i could recommend something
01:06 foreverska: NVE6, 2x GTX 660
01:06 imirkin: and what sort of stuff are you interested in?
01:09 foreverska: Well the rig is obviously a gaming rig so furthering support in free drivers for that would be excellent but to start out anything that gets my feet wet.
01:15 karolherbst1: imirkin: yay
01:15 karolherbst1: I fixed it
01:16 imirkin: karolherbst: congrats
01:16 imirkin: foreverska: well, first off you could see if reclocking works on your box... karolherbst has some patches for what ails ya
01:16 imirkin: foreverska: after that, find a game that doesn't work or is slow or whatever, and fix it
01:17 foreverska: Sweet. I'll look through some of these green cards as well and see if I can't find one or two.
01:18 karolherbst: imirkin: https://github.com/karolherbst/nouveau/commit/3f661f61e59ec8db24eab839de538bb2cb78b2fa
01:19 karolherbst: I bet there is a function to test if the device is suspended or not
01:19 karolherbst: but basically the issue is there
01:21 imirkin: karolherbst: shouldn't there be a pm_runtime_put_sync somewhere?
01:21 karolherbst: imirkin: no
01:21 karolherbst: pm_runtime_get_sync just increases the usage counter by one and wakes up the device snychronous
01:22 karolherbst: that's what has to be done in unload
01:22 imirkin: right
01:22 imirkin: is there a put_sync that needs to be done on load?
01:22 karolherbst: mhh don't think so
01:22 karolherbst: nouveau uses autosuspend
01:22 karolherbst: you deal with that kind of stuff a bit different
01:23 karolherbst: imirkin: put_sync: increment the device's usage counter, run pm_runtime_resume(dev) and return its result
01:23 karolherbst: imirkin: put_sync would do the opposite of course
01:24 karolherbst: which means we would power down the device at drm_device.load time if we would do that there
01:25 karolherbst: but I think a lot of that runtime_pm stuff can be simplified, but I might mess up things, so I leave it until issues arrive
01:25 karolherbst: there is a pm_runtime_put though in load
01:25 karolherbst: it looks somehow not right, but mhhh
01:26 karolherbst: I managed to crash my kernel while messing with it, so I will just leave it there
01:43 karolherbst: mhh I should choose better patch titles :/
01:45 imirkin: you can only go up from where you are :p
01:45 karolherbst: :D
01:45 karolherbst: yeah the last one is really bad
01:45 karolherbst: not that it's a wrong thing to do, it actually doesn't even tell you what the patch does
01:47 imirkin: it's _also_ the wrong thing to do :p
01:47 karolherbst: :D
01:47 karolherbst: https://github.com/karolherbst/nouveau/commit/4c36e561da3fd204f02c18532ae1560325ae29d3
01:48 karolherbst: or imabalancy?
01:48 karolherbst: mhhh
01:48 karolherbst: no imablance
01:48 imirkin: no, imbalance is the word
01:48 karolherbst: :D
01:49 karolherbst: it still won't work when the usage counter isn't 1 from the start :/
01:49 karolherbst: but when will anything else increase that usage_counter?
01:49 imirkin: dunno, but you have to use the API in the intended way
01:49 karolherbst: is there any reason it should be touched outside of nouveau?
01:49 imirkin: and this clearly is not the intended way
01:51 karolherbst: yeah, it doesn't look good, but until now I don't see a better way :/
01:51 karolherbst: except cleaning up the runtime_pm code entirely
01:52 imirkin: perhaps airlied will have some ideas
01:52 karolherbst: yeah
01:52 karolherbst: hopefully
01:52 karolherbst: at least my patch seems to work without issues. no combinations of runpm=0 and runpm=1 messes up the suspend functionality anymore
01:53 karolherbst: so I am sure I found at least the issue
01:54 karolherbst: but this if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_is_v1_dsm()) check inside nouveau_pmops_runtime_suspend can be moved into drm_device.load
01:54 karolherbst: and device there is the device can be suspended or not
01:54 karolherbst: then we would remove that pm_runtime_forbid call inside the put_the_device_into_suspend_state method anymore
01:54 karolherbst: which also looks kind of shady
01:55 karolherbst: why letting the runtime_pm code even try to put the device into suspend when we clearly know before we don't want that
02:11 karolherbst: imirkin: maybe calling pm_runtime_resume is a better idea
02:11 karolherbst: but maybe then the usage counter is still 0 :/
03:15 hakzsam-: imirkin, thanks for the envytools patches, works fine!
03:15 hakzsam-: pmoreau, I don't have any gk110/gk208, it's a gk107
03:17 wootehfoot: Q: Any loose GF117 GOP or VBIOS here?
04:01 karolherbst: imirkin: any idea how much it would help wine if the mesa overhead would be lower?
04:52 jemu: hi, i have nouveau hangs when watching video or playing s25rttr, i've been able to get a dmesg tail using ssh http://lpaste.net/3617972594931662848 what should i do next?
04:53 jemu: the display output freezes and doesn't unfreeze until i reboot
04:54 karolherbst: jemu: full dmesg please
05:24 jemu: karolherbst: full dmesg: https://clbin.com/tjGCN
06:29 karolherbst: jemu: what CPU do you have?
06:30 karolherbst: ohh see it
06:32 karolherbst: jemu: any way to reproduce that issue reliable?
06:32 karolherbst: a game itself is a bit too big to debug those errors :/
06:33 karolherbst: imirkin: what does that mean? read fault at 0000260000 engine 00 [GR] client 04 [GPC0/T1_1] reason 02 [PTE] on channel 6
06:34 jemu: karolherbst: reproducing takes about 10 min
06:35 jemu: so i can reproduce, but it always takes a while
06:48 rah: http://codepad.org/cp7AL1QE
06:48 rah: this looks a bit more useful than the usual error message
06:48 rah: is it?
08:59 karolherbst: imirkin: what is gk104_fifo_intr?
09:00 karolherbst: ohhhhh
09:00 karolherbst: gk104_fifo_intr is getting called _after_ nouveau was removed
09:00 karolherbst: ay
09:00 karolherbst: that explains segfaults at unload
10:05 bitanarchy: fedora hangs on the nouveau driver. how do I disable it?
11:35 karolherbst: how should sysfs/debugfs files be handled when the card is off?
11:35 karolherbst: any good idea?
11:40 l1k: karolherbst: you mean with runtime pm enabled?
11:41 imirkin: bitanarchy: nouveau.modeset=0 should force the nouveau kernel module to do absolutely nothing
11:41 RSpliet: bitanarchy: the easiest way is to padd it to the modprobe blacklist... much like any other driver you don't want to load
11:42 karolherbst: l1k: I mean when the gpu is off
11:43 karolherbst: l1k: we could wake up the gpu for like everything, but mhhh
11:43 karolherbst: or we just return an error
11:45 l1k: karolherbst: the former is how it's done (if it was turned off by runtime pm), e.g. in nouveau_drm_open() right at the beginning it's woken with pm_runtime_get_sync().
11:46 karolherbst: l1k: no, the card just stays off for most stuff
11:47 karolherbst: didn't try everything
11:47 karolherbst: but everythig I tried the card just stayed off
11:47 karolherbst: pstate prints stuff like that: "AC: core 0 MHz memory 0 MHz"
11:47 karolherbst: temp is N/A in sensors
11:47 karolherbst: nvkm_get_volt returns 0.6V
11:49 karolherbst: it doesn't make any sense to wakeup the card on hwmon stuff
11:49 karolherbst: so don't know
11:53 Wolf480pl: I don't think I'm a person you should listen to in this case, but I'd make it return error when card is off if opening file for reading, and wake up the card if opening file for writing
11:55 l1k: nouveau_debugfs.c uses the helpers in drm_debugfs.c and they don't call pm_runtime_get_sync(). as to the question if they should, I've no idea either. :)
11:57 karolherbst: l1k: I think it depends on the case actually :/
11:57 karolherbst: vbios.rom works without problems while the card is off
11:58 karolherbst: maybe I should have make my question more precise
11:58 karolherbst: mhh
11:58 karolherbst: what should we do for the hwmon interface?
11:58 karolherbst: this isn't something which will just dissappear in the future and sometimes you have some sensor reading applets or applications running
11:59 karolherbst: so waking up the card is not the solution
11:59 karolherbst: but what values shall be returned
11:59 karolherbst: should 0°C be returned? sounds wrong, because we don't know it
11:59 karolherbst: returning 0V for the core voltage? mhhh
11:59 karolherbst: maybe, maybe not?
12:01 karolherbst: I am also asking because I want to add a current_load interface to debugfs, and because it's doing some pmu communication, the open call just hangs :/
12:01 l1k: one thing to consider is that on MacBook Pros, turning off the card with runtime pm doesn't just mean D0cold, it means cutting the power. so the card won't answer to anything.
12:02 karolherbst: maybe returning -EAGAIN is the best solution in the end?
12:03 l1k: I think you should check the power state of the card and return an error instead of blocking.
12:03 karolherbst: yeah, but -EAGAIN or any other error?
12:04 karolherbst: at least for my current load interface I can simply return 0
12:04 karolherbst: because if the card is off, we are sure there is no load
12:05 l1k: sounds good
12:05 karolherbst: and -EAGAIN for everything we aren't sure off
12:05 karolherbst: like power consumption, pstate, other stuff
12:06 karolherbst: l1k: or would you prefer another error code?
12:07 l1k: I don't think my opinion carries a lot of weight but let me check errno.h...
12:09 l1k: yes EAGAIN is probably right.
12:23 cactipus: Hello all, I have a GTX 760, and I was wondering if I could run any tests to help out
12:25 karolherbst: cactipus: try out nouveau and report back if you got problems
12:27 cactipus: You don't need any `nvidia` driver memory dumps or anything?
12:29 karolherbst: cactipus: depends on the problems
12:31 cactipus: Ok, sounds good. I've been running nouveau for a week without any problems, so I'm feeling pretty good. Thanks!
12:31 karolherbst: cactipus: you could try out some reclocking though
12:33 cactipus: Ooh, that sounds fun
12:38 karolherbst: cactipus: I am pretty sure your card will crash on the highest perf level and if it does, ping me and I tell you what you should try out
12:38 cactipus: Ok. What if /sys/class/drm/card0/device/pstate doesn't exist?
12:38 cactipus: Attempting to write to it is failing with permission denied
12:39 karolherbst: cactipus: you need to load nouveau with nouveau.pstate=1
12:40 cactipus: Kernel boot param, got it
12:46 cactipus: Okay, I'm pretty sure that it's running, the `pstate` file now exists for `card0`. Do I need to set anything else, or should it be working now?
12:46 karolherbst: should be working
12:46 karolherbst: you can cat the pstate file though
12:48 kingsley: Hi
12:50 cactipus_: https://paste.gnome.org/pmoam6yvi
12:50 cactipus_: karolberbst: I took a peek at my pstate file
12:50 kingsley: The guy who maintains the package named "kdenlive" for debian seems to think I stumbled upon a bug in nouveau after doing an "apt-get dist-upgrade" on the unstable distribution.
12:51 karolherbst: kingsley: and what is that bug?
12:51 kingsley: I'll follow the Topic's request to read TroubleShooting, Bugs and FAQ.
12:51 kingsley: karolherbst: Thanks for asking.
12:52 karolherbst: cactipus_: 0a will work without problems
12:52 karolherbst: 0e/0f might crash your card under load
12:52 kingsley: karolherbst: Basically kdenlive and glxgears freeze.
12:52 karolherbst: but there is a patch for that for 4.4
12:52 cactipus_: How do I enable any one of these options?
12:52 karolherbst: cactipus_: write that into pstate
12:52 karolherbst: echo 0a > pstate
12:52 kingsley: karolherbst: Details are at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803528
12:52 cactipus_: Ah!
12:53 cactipus_: Is there any way I can contribute and document this some where for future nouveau users?
12:53 karolherbst: it should be already
12:53 karolherbst: ohh
12:53 karolherbst: you
12:53 karolherbst: mhh
12:53 karolherbst: still should be :D
12:53 cactipus_: Where? I took a look, but my google-fu could be lacking
12:53 karolherbst: http://nouveau.freedesktop.org/wiki/KernelModuleParameters/
12:54 cactipus_: As a linux scrub, I have no idea how to follow those instructions
12:54 karolherbst: but that pstate interface will go away in the future
12:54 cactipus_: Okay
12:54 karolherbst: because nouveau also wants to do dynamic reclocking at some point
12:55 karolherbst: kingsley: anything in dmesg?
12:56 karolherbst: or xorg log?
12:58 cactipus: ^ Yep, 0e was a little much
12:58 karolherbst: k
12:58 karolherbst: cactipus: ever build your own kernel module and isntalled that?
12:59 karolherbst: and which kernel are you using?
13:00 kingsley: karolherbst: Yes, there are plenty of things in dmesg... but none seem particularly suspicious looking, at least to me.
13:00 cactipus: karolherbst: I'm using kernel 4.1.12-1-lts, I've never built my own kernel module
13:00 karolherbst: kingsley: anything from nouveau?
13:01 kingsley: karolherbst: Sure.
13:01 karolherbst: cactipus: sorry, but today I don't feel like teaching others to do that :/ ever did something with git?
13:01 kingsley: karolherbst: Would you like me to check for anything in particular?
13:02 karolherbst: cactipus: git clone https://github.com/karolherbst/nouveau.git -b master_karol_stable_4_1
13:02 cactipus: karolherbst: No problem, hah. Yes, I've used git. What are you suggesting? Building nouveau from current master commit and installing it?
13:02 karolherbst: ther eis the source you may want to try out
13:02 karolherbst: it's my personal branch I used with 4.1
13:03 karolherbst: and there is quite some changes to it
13:03 karolherbst: cactipus: to build it you have basically to install the kernel header stuff, cd drm, make and install the module inside /lib/modules
13:03 karolherbst: and replace the currently installed nouveau.ko(.xz) file
13:04 karolherbst: ahh and regenerate initramfs
13:05 cactipus: Alright, I'm sure there'll be documentation online somewhere, too
13:05 cactipus: Thanks
13:05 karolherbst: mhhh I am sure you won't find anything if you search for "ubuntu install and build kernel module"
14:14 pmoreau: imirkin: Cool! But I think 64-bit is somewhat far off on my todo list. At least after having conditionals and loops working, so it's really far off. :D
14:15 imirkin: pmoreau: ok. well fp64 is no harder than fp32 from a nv50 ir standpoint
14:18 pmoreau: Ok, but hakzsam would probably rather have conditionals than fp64 :-)
14:18 pmoreau: I'll see if I get stuck on flow control, maybe I'll do fp64
14:19 pmoreau: I should also fix mul, as nouveau_compiler crashes on it for some reason
14:19 pmoreau: Something with DataFile or DataType iirc
14:24 karolherbst: cactipus: any luck so far?
14:26 imirkin: pmoreau: errrr... specifics?
14:26 imirkin: pmoreau: you shouldn't stick values directly into ops... load them first
14:27 cactipus: karolherbst: Nah, I'm leaving that for another day
14:27 imirkin: pmoreau: that allows const-prop to fix it up when it can
14:27 pmoreau: `DataFile ValueRef::getFile() const` invalid address
14:27 imirkin: pmoreau: pastebin the prog->print() output?
14:29 pmoreau: imirkin: https://phabricator.pmoreau.org/P56
14:30 imirkin: pmoreau: i need more info... that seems fine :)
14:31 imirkin: pmoreau: pastebin the NV50_PROG_DEBUG=255 output?
14:31 pmoreau: Hum, I would need to rewrite the SPIR-V binary, I'm not generating the correct code.
14:31 pmoreau: Sure
14:33 pmoreau: imirkin: I added it as a comment to the previous paste
14:35 imirkin: pmoreau: i was expecting an assert somewhere in there...
14:35 imirkin: EMIT: abs s32 $r2 s[0x14] (8) -- can def see how that'd fail emitting...
14:36 pmoreau: abs is absolute value, right?
14:37 imirkin: yeah... in practice it's a cvt
14:37 imirkin: but it's a special thing in the nv50 ir, not sure why
14:38 imirkin: pmoreau: where's it dying?
14:38 imirkin: none of your pastes have really provided me with that info =/
14:39 pmoreau: In `nv50_ir::ValueRef::getFile`
14:39 pmoreau: I can add a bt if you want
14:39 imirkin: that'd be swell
14:40 pmoreau: Added as a comment again :-)
14:40 imirkin: ok, so something is null
14:41 pmoreau: Should be more readable now
14:41 imirkin: if ((mode & 3) == 1) {
14:41 imirkin: const int pos = i->src(1).getFile() == FILE_IMMEDIATE ? 13 : 14;
14:41 imirkin: well THATs not gonna work
14:42 pmoreau: What is mode here?
14:42 imirkin: probably 1
14:42 imirkin: it's trying to be clever
14:42 imirkin: hold on
14:43 pmoreau: My question was more: what's its meaning?
14:43 imirkin: various annoyance... look up in that function :p
14:44 imirkin: pmoreau: see if this fixes it: http://hastebin.com/riremoniyi.coffee
14:44 pmoreau: Found the function
14:44 imirkin: and then make sure to double-check the encoding
14:44 pmoreau: Going to test the patch
14:44 imirkin: coz there's a 50% chance it's wrong
14:45 imirkin: the emitters are all pretty rough around the edges. when you start using new bits, you discover all sorts of fail
14:45 imirkin: envydis is pretty accurate for g80 though, so make sure to compare what codegen thinks it's emitting to what envydis says you emitted
14:45 imirkin: also nvdisasm should work well for CP
14:46 pmoreau: Ok, will check with envydis
14:47 pmoreau:loves the comments for each case of the `switch (mode)`
14:47 pmoreau: Especially the `case 0x01: // arr/grr` one
14:48 skeggsb: imirkin: i should have you better control over the vm for the next cycle (and a way to use it when i push some libdrm patches RealSoonNow), before then though, it should be ok to stick the 16MiB window at the top of the 40-bit address space
14:48 imirkin: skeggsb: actually the window has to be within the low 32 bits ;)
14:48 imirkin: neat huh :)
14:48 kingsley: https://wiki.freedesktop.org/nouveau/MesaDrivers/ says to "Make sure 2D acceleration works first."
14:49 kingsley: How do you "Make sure 2D acceleration works first."?
14:49 skeggsb: imirkin: fuck
14:49 skeggsb: that's not entirely ideal :P
14:49 imirkin: skeggsb: unless the address you give it is supposed to be shifted by 8
14:49 imirkin: skeggsb: will double-check, but there's no "high" byte you can give it
14:49 imirkin: well, what's really not entirely ideal is you can't disable this idiotic memory hole
14:50 skeggsb: well, yes :)
14:50 imirkin: i can't think of a serious use-case for it tbh
14:51 imirkin: skeggsb: i'll double-check blob traces and see how it matches up
14:51 skeggsb: i don't suppose local/shared can be disabled in the shader header or something, if you're not using it, and then the window disappears too?
14:51 imirkin: nope.
14:52 imirkin: lesseee here...
14:52 imirkin: PB: 0x01000000 GF100_3D.LOCAL_BASE = 0x1000000
14:52 imirkin: oh, blob has explicit control over this stuff. and it's not like it's going to map it
14:53 imirkin: so.... yeah. i'm SOL wrt finding it.
14:53 imirkin: calim has a love note about this in the compute code btw
14:53 imirkin: in hindsight i should have found/copied it
14:54 imirkin: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nve4_compute.c#n90
14:54 imirkin: these things go a lot smoother after you know what the issue is :)
14:55 imirkin: pmoreau: yeah, that stuff makes a lot more sense once you understand what they mean. took me a while too.
14:55 imirkin: pmoreau: basically each op can have up to 3 args
14:55 imirkin: pmoreau: and each combination of the 3 arg types has specific encodings across all ops
14:55 imirkin: pmoreau: of course only some of these combinations are valid
14:56 imirkin: pmoreau: so arr/grr = input/reg/reg or gmem/reg/reg
14:57 pmoreau: Oh!!! :-)
14:57 pmoreau: Thanks for the translation!
14:57 imirkin: or you can think of them as grunting sounds
14:58 imirkin: ones you might make as you're reading those comments ;)
14:59 pmoreau: Eh eh eh! Yeah, those were the sounds I thought of when I first read them.
15:00 imirkin: the loop above goes through the args and encodes all three arg types into a single int so that it can be fed into the switch
15:00 pmoreau: (Still compiling, as I had some failed rebasing, it's recompiling almost everything)
15:00 imirkin: personally i would have preferred one arg per nibble rather than tightly packing them into bit pairs
15:00 imirkin: but... it was like that when i got there
15:04 pmoreau: imirkin: It looks good "10000801 4400c780 10000c05 4400c780 a000ca09 0c314780 a000020d 0c114780 40070805 00000780 60060a05 00004780 30100205 c4100780 60060805 00004780 d0000005 a0c00781"
15:04 pmoreau: And the computation result was correct!
15:04 imirkin: pmoreau: a better fix: http://hastebin.com/modisuyaji.coffee
15:06 pmoreau: Well, it doesn't crash anymore, but "3 x -4 => 12" for him…
15:06 pmoreau: I'll try the newer fix :-)
15:07 imirkin: pmoreau: http://hastebin.com/zimisebaro.cs
15:08 imirkin: seems reasonable...
15:08 imirkin: you're taking absolute values though... so 3 * abs(-4) = 12
15:08 imirkin: makes sense.
15:09 pmoreau: Dunno why I'm taking absolute values…
15:09 imirkin: yeah dunno
15:09 imirkin: the expander sticks them in for some odd reason
15:10 imirkin: expandIntegerMUL
15:10 pmoreau: The same generating code works for add and div with negative values
15:11 imirkin: hmmmmmm
15:11 imirkin: did i accidentally the whole thing?
15:11 pmoreau: (By generating code, I mean my translating code from SPIR-V to NV50 IR)
15:12 pmoreau: BTW, your newer patch does work as well (well, not for negative values, but it wasn't suppose to fix that)
15:12 imirkin: yep, i sure did!
15:13 imirkin: give me a few for a patch
15:13 pmoreau: Sure! Thanks for fixing it! :-)
15:14 imirkin: ermmmmm
15:14 imirkin: hm.
15:15 imirkin: pmoreau: http://hastebin.com/fajeqabaru.coffee
15:15 imirkin: we can treat it as unsigned for the low 32 bits
15:18 pmoreau: imirkin: "math-int: ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp:455: void nv50_ir::CodeEmitterNV50::setSrcFileBits(const nv50_ir::Instruction *, int): Assertion `i->getSrc(0)->reg.size == 4' failed."
15:18 imirkin: pmoreau: where?
15:19 imirkin: pmoreau: please provide the NV50_PROG_DEBUG=1 output + backtrace
15:19 imirkin: pretty sure that this is unrelated to what i did
15:19 pmoreau: https://phabricator.pmoreau.org/P57
15:19 pmoreau: For the backtrace
15:19 pmoreau: Adding the DEBUG=1 output
15:21 pmoreau: Output addded as a comment
15:22 imirkin: heh yeah, that won't work ;)
15:22 imirkin: who's the genius who did that
15:22 imirkin: grrrrr
15:22 imirkin: stupid const prop
15:22 pmoreau: :D
15:23 pmoreau: gmem/reg/reg/reg/reg/reg, whoah, that's a lot of out/in!
15:24 imirkin: nope, that's the grunting sound.
15:26 imirkin: er hm. no, that's not why...
15:27 imirkin: pmoreau: + assert(s[0]->getFile() == FILE_GPR);
15:27 imirkin: add that right after that if () that i changed
15:27 imirkin: pmoreau: it'll probably hit that assert. if it does, do "p mul->print()" in gdb
15:28 pmoreau: Will do
15:30 pmoreau: imirkin: "error: no member named 'getFile' in 'nv50_ir::Value'"
15:30 imirkin: lol
15:30 imirkin: ->reg.file == ...
15:31 pmoreau: The compiler seems more happy with that version. :D
15:32 pmoreau: Hum… I didn't hit that assert…
15:33 imirkin: pmoreau: ok, well, i can't debug this remotely
15:33 imirkin: pmoreau: i believe in you!
15:33 pmoreau: FYI, i->getSrc(0)->reg.size == 2 when I hit the assert
15:34 imirkin: yeah, fully expected.
15:34 imirkin: that's unexpected is that i->getSrc(0)->reg.data != FILE_GPR
15:34 imirkin: errr wait
15:34 imirkin: that's legal isn't it
15:34 imirkin: hmmm
15:34 imirkin: hold on
15:34 pmoreau: reg.file rather?
15:35 imirkin: not just legal, but required... s[] can only go into the first arg
15:35 imirkin: hmmmm
15:35 pmoreau: And I didn't hit the assert, so i->getSrc(0)->reg.file == FILE_GPR
15:35 imirkin: ok, so hold on
15:38 pmoreau: Oh, I didn't hit the new assert cause the program didn't went so far apparently!
15:38 pmoreau: I added a breakpoint but hit the reg.size assert first
15:38 imirkin: pmoreau: switch (i->sType) instead
15:38 pmoreau: hightResult is false!
15:38 imirkin: yeah, i know
15:38 pmoreau: Ok
15:39 imirkin: it should be
15:39 imirkin: pmoreau: http://hastebin.com/gusukihoyi.coffee
15:39 pmoreau: Should I keep the "&& highResult"?
15:40 imirkin: yes.
15:40 imirkin: the abs's are thrown in for the s32 x s32 -> high s32 case
15:40 imirkin: coz getting the high bits right is tricky
15:40 imirkin: however thankfully there's no such thing as s32 x s32 -> low s32
15:41 imirkin: only s32 x s32 -> u32
15:41 pmoreau: \o/
15:41 pmoreau: Working!
15:41 imirkin: so we don't have to worry about it unless the high result is requested
15:41 imirkin: ok cool
15:41 imirkin: i can take care of pushing these out if you like
15:42 pmoreau: Yes please, thanks for having a look at it! :-)
15:42 pmoreau: Feel free to add a tested-by
15:43 pmoreau: I don't feel confortable enough with the code to add a Rb :/
15:43 imirkin: that's ok... i push entirely unreviewed stuff
15:43 pmoreau: :D
15:43 imirkin: hell, sometimes i don't even compile it
15:45 pmoreau: Is there a doc format in Mesa that I could use to document how kernel args are passed on various gens, where to find the thread ids and so on?
15:45 imirkin: pmoreau: ok i see what's going on
15:45 pmoreau: Probably some kind of docbook like in the kernel
15:46 imirkin: pmoreau: this could never hit on from_tgsi
15:46 imirkin: pmoreau: in tgsi, there's only a UMUL, no IMUL
15:46 imirkin: pmoreau: you should have kept the arg types as unsigned
15:46 imirkin: and it would all have magically worked out
15:46 pmoreau: Oh really?!
15:46 imirkin: but i'll still fix it. but it's a bug specific to your converter
15:47 imirkin: since it's def surprising :)
15:48 pmoreau: Well IMUL does exist in SPIR-V: https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#OpIMul
15:50 imirkin: pmoreau: but no umul :)
15:50 imirkin: pmoreau: so it's still the same thing
15:50 imirkin: sign doesn't matter.
15:51 pmoreau: Eh? Why wouldn't it matter?
15:51 imirkin: pmoreau: prove me wrong. find a situation where sign matters.
15:52 imirkin: assuming 2's complement math
15:52 imirkin: which is a fairly reasonable assumption... s-mag died off like 30y ago
15:53 pmoreau: Well, was thinking of the *real* sign, not of the bit sign --"
15:56 pmoreau: I found out where I was putting a signed type for the operation.
15:56 pmoreau: Should I stick an unsigned instead?
15:57 imirkin: i know, but my point is... signed multiply is indistinguishable from unsigned
15:57 imirkin: e.g. -1 * -1 = 0xffffffff * 0xffffffff = 0xfffffffe00000001 -- take the low 32 bits = 1
15:58 pmoreau: Yeah right
15:58 imirkin: 2's complement = good idea ;)
15:59 pmoreau: :-)
16:00 pmoreau: imirkin: Any ideas about the doc format?
16:01 imirkin: pmoreau: envytools seems like a better target
16:01 imirkin: pmoreau: envytools/hwdocs -> envytools.rtfd.org
16:01 pmoreau: Ok
16:01 imirkin: i suspect this stuff is all already documented there
16:02 imirkin: pmoreau: http://envytools.readthedocs.org/en/latest/hw/graph/tesla/cuda/isa.html
16:02 imirkin: pmoreau: look under registers ;)
16:03 pmoreau: Yeah, was having a look…
16:03 pmoreau: I'll read the whole document! :D
16:04 imirkin: the tesla docs are a lot more complete than fermi
16:06 vita_cell: karolherbst
16:06 imirkin: pmoreau: btw, pushed
16:07 vita_cell: imirkin
16:10 pmoreau: imirkin: Thanks a lot!
16:12 vita_cell: I tested karolherbst's volt fix, it works on Trisquel 7 x64 with Linux-Libre 4.3, I saved "nouveau.ko" and installed Mint 17.2 x64, installed same kernel in Mint, put "nouveau.ko" fix into kernel and updated initramfs, but it is unstable (memory) at 0e and 0f pstates.
16:13 imirkin: pmoreau: let me know if you hit other buts. although i'd sorta prefer you work them out yourself :p
16:14 pmoreau: imirkin: Will do! I was expecting the issue to be in my code generation, and was planning to have another look later.
16:16 imirkin: bugs*
18:26 puddlejump: Any idea if nouveau can run Kodi 15.2 on GeForce 8300, Kodi forums typ. say "use nvidia dammit" but I'd rather not
18:30 imirkin: puddlejump: there are lots of reported issues with kodi and nouveau
18:30 imirkin: puddlejump: i use mplayer, works great for me
18:31 imirkin: puddlejump: no one has really cared to investigate the issues, so i suspect that the overlap of kodi and nouveau users is minimal
18:35 foreverska: Well the fact Kodi uses non-free stuff (or did last I looked) kinda puts it in the class for people who don't mine non-free drivers.
18:36 imirkin: i know that mplayer is the only thing that i've found works reliably, so i just use that. if others want to use kodi for whatever reason, they can track down the issues.
18:37 imirkin: it's all due to their insistence on using the semi-broken GL_NV_vdpau_interop
18:37 imirkin: at least that's my guess
18:44 puddlejump: i'm not too familiar yet with Kodi, what does mplayer use mean, some kind of backend? can i use mpv instead?
18:47 imirkin: puddlejump: mplayer is one of the older video players. i've found that all of the "improved" versions somehow regress its ability to actually play back content
18:47 imirkin: puddlejump: mpv is one of those "improved" versions. i stick to mplayer.
18:47 puddlejump: thx i know what it is, how if at all does it relate to Kodi?
18:48 imirkin: i understood kodi to be a media player
18:48 puddlejump: kodi.tv yet
18:48 puddlejump: i mean yes
18:48 imirkin: mplayer is a media player
18:49 puddlejump: ok you just mean don't use Kodi at all
18:49 puddlejump: not an option!
18:49 puddlejump: ps this guy is using Kodi with nouveau https://bbs.archlinux.org/viewtopic.php?id=204066
18:50 imirkin: ok
18:53 puddlejump: Kodi is a lot more than just media player it is the go-to HTPC software
18:56 imirkin: ok
22:52 gnurou: imirkin: see, the list is actually useful! ;) (re: MP warp error 0x10) granted, it takes one month more than it should
22:52 imirkin: gnurou: yeah, this one turned out quite well
23:35 imirkin: hakzsam-: at your convenience, it'd be nice to get a blob trace of a fermi with cuda or compute shaders -- iirc you have the relevant setup? then i can teach rnndb about it.
23:35 imirkin: er, demmt
23:36 imirkin: skeggsb: btw, most recent nouveau has sorta broken demmt... something about channel hints not being set iirc
23:37 imirkin: i think it might be a flaw in demmt's memory model though...
23:55 hakzsam-: imirkin, sure I can do that