06:37 karolherbst: mupuf: do you want to look over the patches again before I send them to the ML? This way I could ping ben directly and ask him to merge it :D
07:11 mupuf: I want to have a look at the
07:11 mupuf: m
07:38 karolherbst: mupuf: we could set power_crit to what we can draw from the power supply (pci slot + power pins)
07:38 mupuf: karolherbst: how do you know that?
07:38 karolherbst: no idea :D
07:38 mupuf: I would say you need to parse the power budget table
07:38 karolherbst: well it is in the specs
07:38 mupuf: and expose that
07:38 karolherbst: yeah that too
07:39 mupuf: yes ... but see, there are 2 kinds of power pins
07:39 mupuf: the 75 and the 85W
07:39 karolherbst: we have many hwmon sysfs entries for that
07:39 karolherbst: but crit is the highest and this should be the value we really should never ever go above
07:39 karolherbst: there are?
07:39 mupuf: yes...
07:39 karolherbst: I don't think it is part of the specs though
07:39 mupuf: the 85W is non-standard
07:39 mupuf: but it is common
07:40 mupuf: and that's the one with 8 pins instead of 6
07:40 karolherbst: no, the 8 pin is also in the spec
07:40 karolherbst: and it is a doubled 6 pin
07:40 karolherbst: k, found it
07:40 mupuf: oh well, then you still do not know if it is a 6 or 8 pins one
07:40 karolherbst: 25W slot for non VGA devices
07:41 karolherbst: 75W slot for x16 vga devices
07:41 karolherbst: 75W per 6 pin
07:41 karolherbst: 150W per 8 pin
07:41 karolherbst: 2x 8 pin is not part of the spec
07:41 mupuf: oh well
07:41 mupuf: my point still remains
07:41 mupuf: you can't know
07:42 mupuf: until you parse the budget table
07:42 mupuf: there is already some support for it ... but since I could not easily reverse the table, it kind of lingered
07:42 mupuf: now that the GM2xx exposes the budget, we can work
07:42 mupuf: but ... we can't update the vbios :s
07:43 karolherbst: mupuf: yeah, but with power_crit isn't meant what the device can use at maximum, it just a value where the system should do something about the power consumption and fast
07:44 karolherbst: the "normal" max is power_cap
07:44 karolherbst: but this is a RW value :/
07:44 karolherbst: mhhh
07:44 karolherbst: yeah why not, can be used somehow
07:44 karolherbst: ohh right, max is power_max, my fault
07:48 mupuf: karolherbst: nothing is plugged to do the polling anyway
07:48 mupuf: ignore this for now
07:48 mupuf: especially until we we prove that the reading is correct!
07:48 karolherbst: yeah I know, it was just a thought
07:49 karolherbst: but I think I will fix the extdev.addr thing, because this value has to be rshifted by 1 in any case...
07:50 mupuf: have you tested the bus well?
07:50 mupuf: that part was the big unknown for me
07:50 karolherbst: every use of extdev.addr rshifts it by 1
07:50 karolherbst: therm/ic for example
07:50 karolherbst: ohh the bus
07:51 karolherbst: mhhh well it works for every gpu I tested it on. Also it is in the open-gpu-docs
07:51 mupuf: oh well, sounds great then
07:51 karolherbst: 1 bit "External Communications Port"
07:52 karolherbst: "This field defines which communications port is used for this device. See the I2C Control Block Header for the listing of the Primary and Secondary Communication ports."
07:53 karolherbst: the address field is also quite interessting: "8-bit aligned, right shifted 7-bit address of the I2C device. The I2C spec defines 7 bits for the address [7:1] of the device with 1 bit for R/W [0:0]. So, generally, most addresses are listed in their 8 bit adjusted form with 0 for the R/W bit. This field must list that 8-bit adjusted address."
07:56 mupuf: I know how i2c works, I wrote my own protocol analyzer and pushed it in nva
07:56 mupuf: I talked about which bus to select
07:56 karolherbst: yeah, but I was thinking of fixing the stuff in the bios/extdev file
07:56 mupuf: nvai2cspy, if you want to have a look :p
07:57 karolherbst: instead of having each use of addr doing a rshift 1, just shift it in the bios subdev and expose a rw flag
07:57 karolherbst: we can also fix this up later, though
08:01 mupuf: not sure it is a good idea, if we fix it, we should do it in the i2c abstraction
08:03 karolherbst: yeah maybe
08:48 karolherbst: mupuf: okay, I think I am done with improvements: https://github.com/karolherbst/nouveau/commits/power_sensors
08:51 AndrewR: so, I finally compiled Xephyr from Xserver 1.18.1 with glamor acceleration, and tried it with nouveau (nv92). It surprisingly worked w/o artefacts as Xephyr -glamor -screen 1024x768 -ac :2 BUT using -glamor_gles2 command line switch resulted in heavy artefacts! So, does this mean GL ES2 on nv92 is broken?
08:51 AndrewR: aw, need to check if LIBGL_ALWAYS_SOFTWARE=1 resulted in same behavior ..:/
08:52 karolherbst: I would say GLES isn't well tested with nouveau, so there might be issues
08:54 AndrewR: karolherbst, then guess I better to enable ES2 part of piglit tests ..(I've disabled them awhile back, because I used to build mesa w/o gles support)
08:55 AndrewR: but software rendering with glamor_es as acceleration arch resulted in even more funny picture - no text at all!!
08:55 karolherbst: :D
08:56 karolherbst: I think only the intel driver is good
08:56 AndrewR: karolherbst, probably, but no intel GPU in this room
08:57 AndrewR: at least just -glamor with llvmpipe is good, as in - text and icons and menus all here
09:47 masta: imirkin_, did you see http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=8d1fd61a3723ab8cb6b7bfeb8be38e16282cc1ed <-- Tegra X1 firmwares posted
10:22 mupuf: karolherbst: the remaining patch is R-b: me
10:22 mupuf: the hwmon patch has one comment
10:22 mupuf: please fix it and I would be satisfied
10:22 mupuf: thanks!
10:33 karolherbst: mupuf: nice, thanks
10:45 karolherbst: mupuf: uhh we might have a problem thought: loading nouveau, unloading nouveau, turning off gpu, turing on gpu, loading nouveua: -EIO from i2c read
11:03 karolherbst: mhh okay, so nvkm_i2c_init has to be run before we can do the stuff in iccsense
11:11 martm: this shitface befoe his death, does one have something to say too?
11:12 martm: airlied: do you want to die ?
11:14 martm: than fucking hold your profile ..
11:18 martm: fucking molested dudes...irish gang is goint to be buried so fast
11:22 martm: this fucking idiot in corraspondance with estonian communists tried to assault me..mofo fucking idiot
11:22 martm: how the fuck i ask!!!!!!!!!!!!!!!!!!!!
11:23 martm: idioot türa raisk!
11:23 martm: türa sa sitt kui sa veel näole näitad, paneme su magama!
11:29 pmoreau: …
11:32 mupuf: karolherbst: well, sounds normal that we need to follow the dependencies :D
11:33 mupuf: ok, I was wondering a bit about this, doing stuff in ctor
11:33 mupuf: I guess you need to move it to init() instead
11:33 mupuf: no biggies
11:33 karolherbst: yeah I know
11:33 karolherbst: but we only have to do that once
11:33 karolherbst: no reason why we should do that on every wakeup
11:34 karolherbst: is there something like init_once?
11:40 karolherbst: ahh oneinit
11:46 karolherbst: nice
11:48 karolherbst: k, oneinit works :)
11:55 pq: has anyone tried asking why this "Christopher M. Penalver <christopher.m.penalver@gmail.com>" bz.fd.o is an ubuntu bug tracker for nouveau?
11:55 pq: *thinks bz.fd.o is...
12:00 pmoreau: In one of the bug reports, there was a link to the Ubuntu launchpad (I think?) and when I had a look at it, it had all the messages from the bz.fd.o symlinked.
12:01 pmoreau: So it could be that he only posted on the Ubuntu launchpad bugs, but they got symlinked/applied on fd.o as well?
12:01 karolherbst: is it only me, or is the lists.freedesktop domain somehwat overloaded?
12:02 pmoreau: the whole fd.o was down this morning, so could be that it's still no fully functional.
12:03 karolherbst: k
12:03 pq: yeah, seems like fd.o is slowly coming back
12:04 pq: pmoreau, sounds like a misconfiguration that should be reported somewhere then, it's so weird to see that stuff when you assume the bug has been filed at fd.o since it's showing at fd.o.
12:10 pq: or does anyone think it's harmless or even useful?
12:11 karolherbst: I never read those launchpad bugs because somehow I always get the feeling there is nothing usefull in there, ...
13:25 karolherbst: do you also get random answers from anything you write to the ML asking for tech support?
13:34 pmoreau: pq: It looks like the symlink is done from fd.o into launchpad, and not the other way round. I was wrong. (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1228506 for bug report https://bugs.freedesktop.org/show_bug.cgi?id=70389)
14:25 karolherbst: skeggsb: I just rebased like today :/
14:26 skeggsb: well, either way, one of you were going to have to :P i just happened to merge secure boot first
14:28 karolherbst: yeah
14:28 karolherbst: anything else new?
14:29 airlied_: gnurou, skeggsb : one or both of you can ack tagr's patch?
14:32 skeggsb: imirkin_: hrm, testing on gf100.. i'm not seeing the glamor issue happen now for some reason
14:32 skeggsb: airlied_: done
14:33 skeggsb: dunno if i'm not trying hard enough or something
14:33 skeggsb: it used to be pretty immediate
14:35 karolherbst: I wish git would resolve those alignment issues itself :/
14:36 karolherbst: skeggsb: rebased https://github.com/karolherbst/nouveau/commits/power_sensors
14:37 karolherbst: skeggsb: I also have written a really nice tool against libnouveau: https://github.com/karolherbst/nouveau/blob/master_karol_no_touchy/bin/nv_cmp_volt.c
14:38 karolherbst: it's a bit hackish, but it will be only usefull on fermi+ cards anyway
14:38 skeggsb: karolherbst: hmm, it conflicts when merging here still.. and the hash of the top commit of your tree before your patches doesn't match mine..
14:38 karolherbst: ohhh maybe that one drm-next commit does too much :/
14:39 skeggsb: i'll cherry-pick them across, see if that's better
14:39 karolherbst: mhhh
14:39 karolherbst: do rebase -i
14:39 karolherbst: and remove those three top commits
14:39 karolherbst: two nvif ones and one dma
14:39 skeggsb: all good, patches apply if i cherry-pick them
14:39 karolherbst: ahh okay
14:39 karolherbst: yeah
14:40 karolherbst: I just had to remove three patches which changed on my 4.4 branch then
14:40 martm: din't i say it slowly!
14:40 martm: i yeah, made my mind up
14:41 martm: this guy is ok, but i gonna hit a ...
14:41 karolherbst: skeggsb: I tend to develop against the last kernel release without the drm-next stuff, so my patches are usually based upon your master but with the last drm-next commit removed
14:41 martm: a mental stuff again..this time i gonna fuck them up
14:44 karolherbst: skeggsb: also we should discuss where/how I should put the pmu counter stuff into nvif. I think I get the idea, but maybe there is a nvidia interface I simply can provide with these
14:45 karolherbst: the thing nvidia uses to get their core/memory/video/pcie load in their software stack, I never managed to find out how they get that information from the kernel into userspace
14:49 martm: :)
14:52 martm: it is what it is:)
14:59 martm: sorry a vote for airlied:)
15:00 martm: cheers, man you arrogant bastard:)
15:00 martm: if he wanted i would had been in mental institution allready
15:04 martm: listen guys, what the ...https://www.youtube.com/watch?v=QzEwx4BoYI0
15:08 martm: mental or what the fuck hardly anymore cares, or care so to speak!
15:21 pmoreau: imirkin: Will 11.3.0 do? Or do you want 11.2-rc1?
15:21 hakzsam_: pmoreau, he wants 11.2 I guess
15:21 martm: listen i got enough allready, i want to go to sleep, is it ok?
15:21 pmoreau: (11.3.0-devel, as of c95d5c5)
15:21 imirkin: pmoreau: mmmmmmmmmmmmmm i'd *prefer* 11.2-rc1, but i don't *think* any features have been pushed to HEAD that would show up on g96...
15:22 imirkin: or actually, i guess OES_texture_border_Clamp
15:22 imirkin: so 11.2-rc1 would be ideal
15:22 pmoreau: imirkin: I can checkout the release tag and rebuild
15:22 imirkin: pmoreau: that'd be fantastic
15:22 imirkin: karolherbst: fyi, ES vs desktop GL is mostly a mesa core distinction, not a backend driver distinction.
15:23 imirkin: karolherbst: so it's not like nouveau works well with desktop but poorly with ES or something. it's all the same.
15:23 pmoreau: I guess that's the 11.2-branchpoint tag
15:23 martm: babes it looks ok!
15:23 imirkin: pmoreau: there should also be a mesa-11.2.0-rc1 tag
15:23 karolherbst: imirkin: yeah I know, but I expect that there are still some differences?
15:23 karolherbst: maybe some features are ES only
15:23 imirkin: karolherbst: not as far as nouveau is concerned
15:23 martm: it really does looks like you made it!
15:23 martm: does look
15:24 pmoreau: Ah! Starting with mesa-, there it is :-)
15:24 karolherbst: imirkin: ohh so there is really no code path inside nouveau which is only hit by ES?
15:24 imirkin: karolherbst: conceivable i suppose, but extremely doubtful
15:25 martm: well..spir-v has prolly some overhead
15:27 martm: non-the less i think codegen should work
15:28 martm: after all krh was away doing some code again:)
15:28 martm: lene marlin do you know?
15:31 martm: or kyla, mental stuff
15:31 martm: :)
15:43 martm: ah cheers, mental stuff, yeah it's could be but yeah...hardly such fucktards come to tell what is right and what is wrong
15:44 martm: i mean wtf. chipsies portuguease
15:45 martm: are there any sort of problems?
15:46 martm: my best mate said there are some, why don't those shitholes bug the fuck off right?
15:51 pmoreau: imirkin: Here you go: https://phabricator.pmoreau.org/P90
15:51 martm: i am telling to those guys to get the fuck off right, and please don't bother estonian human around the world, and even airlied is going to be on my side
15:52 imirkin: pmoreau: awesome thanks!
15:53 pmoreau: imirkin: You're welcome :-) Do you want me to generate one for each major release?
15:53 imirkin: pmoreau: in general, yes
15:53 pmoreau: Ok, will try to remember.
15:53 imirkin: oh, i'll remind you :)
15:53 pmoreau: :-D
15:54 imirkin: you're the only one here who has one plugged in on a regular basis
15:55 pmoreau: imirkin: BTW, should I submit this one? https://phabricator.pmoreau.org/rMESA5ac4806b391f8db820bc3a8a28bad43086b4e223 It's due to %r0 on Tesla getting a definition due to being a function arg, but without being linked to an actual instruction
15:56 imirkin: pmoreau: so what does ->defs() contain?
15:56 imirkin: oh, is the function holding that valuedef?
15:56 pmoreau: yes
15:57 imirkin: i don't see where...
15:57 pmoreau: Since %r0 is added as an arg, to avoid any other instruction from "erasing" it before one can retrieve thread ids
15:57 imirkin: so... it's an arg. what's in ->defs()?
15:58 imirkin: alternatively, point me at the code that creates this value and sticks things into its defs list
15:58 imirkin: i'm not saying you're wrong, i'm just not overly familiar with functions and arguments
15:59 imirkin: that's not really used in the normal flow of things
15:59 pmoreau: r0 is added as an arg in NV50LoweringPreSSA::visit(Function *f)
15:59 pmoreau: (I need to recompile with my SPIR-V stuff to hit the bug)
15:59 mupuf: skeggsb: nice one: https://github.com/skeggsb/nouveau/commit/d5bf1480a475a2fa068e945710dfbe92f8f4bc05
16:00 imirkin: so that's not %r0
16:00 imirkin: it's $r0
16:00 imirkin: i still don't see how its ->defs() get populate
16:02 pmoreau: I had found it at some point, but forgot since, and of course, didn't wrote it somewhere…
16:02 pmoreau: So I need to think about it again
16:03 imirkin: this time document it in the commit ;)
16:03 pmoreau: It gets a def from the mov operation in that function, but there is the instruction. So there is another def coming from somewhere else…
16:04 pmoreau: Will definitely do! :-)
16:11 imirkin: the mov operation in that function doesn't define the arg, it refs the arg
16:14 pmoreau: I do get a def on arg after executing the `f->ins.push_back(arg)`
16:14 pmoreau: Let's step through it then
16:15 imirkin: oh, that's surprising
16:15 imirkin: OH!
16:15 imirkin: i totally missed it
16:15 imirkin: std::deque<ValueDef> ins;
16:15 imirkin: std::deque<ValueRef> outs;
16:15 imirkin: duh.
16:16 pmoreau: #0 nv50_ir::ValueDef::set (this=0x7fffffffa5c0, defVal=0xc4f500) at ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir.cpp:159
16:16 pmoreau: #1 0x00007fffe85facee in nv50_ir::ValueDef::ValueDef (this=0x7fffffffa5c0, v=0xc4f500) at ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir.cpp:116
16:16 pmoreau: #2 0x00007fffe8663d6d in nv50_ir::NV50LoweringPreSSA::visit (this=0x7fffffffa750, f=0xc6c750) at ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp:672
16:16 imirkin: yeah, it totally makes sense. i didn't notice it was an array of ValueDef's
16:16 imirkin: ok
16:16 imirkin: so
16:16 pmoreau: Oh right, deque<ValueDef>, which explains the creation of a ValueDef
16:17 imirkin: so i'd just say replace my ->defs().size() == 0 with ->getInsn() == NULL
16:17 imirkin: or !=
16:17 imirkin: wtvr
16:19 pmoreau: K
16:34 pmoreau: imirkin: What is the difference between %r0 and $r0 BTW?
16:53 imirkin: pmoreau: one is a fixed register (i.e. colored), the other is just a regular pre-ra lvalue
16:54 imirkin: bbl
16:54 pmoreau: Oh, ok
18:55 Jayhost: Is there an easy way to idle gpu for clock testing?
20:26 failingCuzNvidia: any1 know if it's possible to make nouveau work with tegra x1?
21:09 Jayhost: failingCuzNvidia I'm not the person to ask but the blogs are positive depending on what gpu
21:10 imirkin: are there multiple gpu options on the tegra x1?
21:13 Jayhost: imirkin I don't believe so. My confusion
21:14 imirkin: anyways, it should be possible in principle, but i don't think anyone outside nvidia has done it
21:15 imirkin: (in large part because devices aren't exactly easy to come by)
21:22 Jayhost: I guess the pixel c is the one using nouveau standalone
21:23 imirkin: it's a hacked up nouveau, and running blob userspace afaik
21:25 Jayhost: Pretty strange yeah?
21:26 gnurou: failingCuzNvidia: Nouveau works with Tegra X1, if you can boot an upstream kernel
21:27 gnurou: and there is only one integrated GPU option with X1 (gm20b), although you could also plug a dGPU into a PCIe port
21:36 imirkin: gnurou: are you aware of anyone outside nvidia getting it working?
21:41 gnurou: imirkin: actually someone on #tegra has been asking help to get it to work recently... the tegra-nouveau-rootfs scripts that I maintain are helpful for that, so it's not too hard to do
21:41 gnurou: of course most people are more interested in dGPU than Tegra, but there is some interest still
21:44 imirkin: gnurou: so that'd be a "no"? :) until that guy on #tegra gets it going... heh.
21:44 gnurou: he got it on Jetson TK1, TX1 is next :)
21:44 gnurou: and it's basically the same thing
21:44 imirkin: yeah
21:44 imirkin: oh btw, unrelatedly, could you send me the .config you use on your TK1?
21:45 imirkin: i'll see if that has the same stability issues mine has
21:45 gnurou: the tegra_defconfig of my staging/work branch on https://github.com/Gnurou/linux is what I use
21:46 imirkin: ok cool, thanks
21:46 gnurou: I suggest sticking to this branch, it's the one that works for us
21:46 gnurou: on both TK1 and TX1 by the way
21:48 imirkin: ok
21:51 gnurou: nouveau mainline now works for Maxwell 2 dGPU, but for Tegra I still suggest taking my staging/work branch of https://github.com/Gnurou/nouveau