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