00:00 karolherbst: mhh sadly radeonsi was a bit faster today :D
00:01 hakzsam: ahah yeah
00:06 karolherbst: huh... bios: unable to locate usable image
00:10 karolherbst: uhh ACPI
01:39 K1rk: Hello
01:39 imirkin: and a good day to you, sir
01:39 K1rk: I am trying to troubleshoot an issue on Linux Mint 17.3 w\ MATE, sometimes when using the Switch Users feature, xorg crashes and drops the machine to console.
01:39 K1rk: I spoke with the folks over in #xorg and they advised me it appears to be a nouveau issue.
01:39 K1rk: See xorg log here: https://iota.lt/d/qDRsqUUpAH/Su2HkVTf.txt
01:40 imirkin: pastebin dmesg as well?
01:41 imirkin: "failed to set drm interface version" usually means it's some sort of stupid permissions error... does linux mint 17.3 by any chance use systemd?
01:41 K1rk: yeah
01:41 K1rk: Here's dmesg
01:41 K1rk: https://iota.lt/d/qDRsqUUpAH/2qdWzpu0.txt
01:42 K1rk: imirkin, Linux Mint 17.3 is based off of Ubuntu 14.04
01:42 imirkin: and does ubuntu 14.04 use systemd? :)
01:43 imirkin: [my knowledge of such things is minimal]
01:43 K1rk: dpkg -l | grep systemd shows
01:43 K1rk: ii systemd-services 204-5ubuntu20.15linuxmint1 amd64 systemd runtime services
01:44 K1rk: It looks to be installed
01:44 imirkin: anyways... my *guess* is that there's some sort of issue whereby the drm master doesn't get dropped... or... something
01:44 imirkin: it's *unlikely* to be a nouveau issue, but i wouldn't exclude it
01:44 imirkin: my guess it's some sort of funny interaction with systemd
01:44 imirkin: sorry to send you around in circles
01:44 K1rk: lol
01:45 K1rk: That doesn't sound all too surprising to me.
01:45 K1rk: systemd can be pretty funky
01:45 imirkin: basically i'm not 100% sure how the switch users thing works
01:45 K1rk: But honestly I don't understand why the user switcher tool would even do anything to touch drivers
01:45 imirkin: but since X is being run as a user
01:45 K1rk: ah, maybe that's why
01:45 imirkin: there's some funky interaction when X restarts
01:45 K1rk: The transition from the user back to root
01:45 imirkin: there can only be one drm master
01:46 imirkin: perhaps it's something we fixed in xf86-video-nouveau 1.0.12
01:46 imirkin: tbh i don't know
01:46 imirkin: [you're using 1.0.11]
01:46 imirkin: also for all i know a newer Xorg version fixes this as well
01:46 K1rk: xserver-xorg-video-nouveau-lts-vivid 1:1.0.11-1ubuntu2build1~trusty1
01:46 imirkin: sorry for being so inconclusive.
01:47 K1rk: There's no newer version of that package available from my repository at this time
01:47 imirkin: ok, well, version 1.0.12 was released 4 months ago
01:47 K1rk: Actually in terms of IRC support discussions on FOSS communities this has been quite helpful.
01:48 K1rk: It's much better than sitting here in silence while my question gets bumped off the page by people peering and joining
01:48 K1rk: :)
01:48 K1rk: I can ask in the mint IRC
01:48 K1rk: The mint developers do some weird stuff merging ubuntu stuff with their own stuff
01:49 K1rk: It could be a mint specific issue too
01:49 K1rk: I just usually find I get better answers if I stick to the irc for the software itself first
01:49 K1rk: Most of the people in the mint channel aren't going to be xorg experts
01:50 imirkin: i don't see anything related in 1.0.12 actually
01:50 K1rk: I may consider trying the nvidia proprietary driver for awhile and see if the issue persists with it, it's easy enough to switch back and forth on my distro.
01:50 imirkin: sure, whatever works for you
01:51 K1rk: However the proprietary driver was doing something odd as well, that's why I went back to nouveau. On the proprietary driver there seemed to be a bug where sometimes I would get a roughly 100x100 pixel black square on the upper left corner of the monitor, and stuff under that square couldn't be seen haha
01:51 imirkin: i try to avoid learning the details of various distros that i don't use
01:51 imirkin: my theory is that if you use a distro, you're a pro at it, and don't need help operating it
01:51 K1rk: I try not to worry too much about the differences between distros
01:51 imirkin: i realize that's not always the case, but... i can't go around doing distro support for every distro out there
01:51 K1rk: I do sysadmin \ support for a datacenter so I am supporting all sorts of distros but I am weak on GUI stuff because we don't have much of it here.
01:52 imirkin: gui stuff sucks =/
01:52 K1rk: It does but I enjoy having a linux desktop
01:52 imirkin: all you need is a teletype
01:52 imirkin: and ed
01:52 imirkin: ;)
01:52 K1rk: lol
01:53 K1rk: This particular computer I am working on this issue for is not used by me, it is used by my mom and it's her first experience with Linux
01:53 K1rk: She got a virus on her windows PC and I finally convinced her to try it
01:53 imirkin: heh
01:53 K1rk: Since I don't live there anymore I usually support her over ssh
01:53 K1rk: lol
01:53 imirkin: might have gone with chromeos
01:53 K1rk: nah the needs are too advanced
01:53 K1rk: She has a windows VM and stuff
01:54 K1rk: Needs to be able to use Quicken still
01:54 imirkin: ah
01:54 imirkin: didn't want to set up a citrix thing for that?
01:54 K1rk: I just used virtualbox lol
01:54 K1rk: It's a little slow but I'm trying to discourage the crutch on windows
01:55 imirkin: virtualbox has issues with nouveau too, if you enable 3d accel
01:55 K1rk: I have noticed that.
01:55 K1rk: I wasn't aware it was a nouveau related issue
01:55 K1rk: But I've noticed some bugginess with it
01:55 imirkin: nouveau doesn't support concurrent drawing from multiple GL contexts
01:55 K1rk: woosh
01:55 K1rk: lol
01:55 imirkin: whereas virtualbox does that (i'm fairly sure, not 100% - it's proprietary software and i don't use it)
01:56 imirkin: fixing it is non-trivial, unfortunately, so i've let it slide for now
01:56 K1rk: Sorry I'm not sure what "multiple GL contexts" means I assume it's something with how virtualbox is presenting its UI to the driver
01:56 imirkin: real games are coming out that do this too, so i'll have to fix it eventually
01:56 K1rk: You will?
01:56 imirkin: eventually.
01:56 K1rk: I didn't realize I was speaking with a dev
01:56 K1rk: Nice :)
01:57 K1rk: Well honestly man if you want my opinino
01:57 K1rk: *opinion
01:57 imirkin: or maybe i'll be able to convince some sucker to do it
01:57 K1rk: Nouveau has done some amazing things in the past few years
01:57 K1rk: I remember when it sucked hard
01:57 imirkin: gtg
01:57 K1rk: It's gotten really amazing
01:57 K1rk: So props to you guys :)
01:58 K1rk: Np man take it easy
03:43 martm: imirkin: when gather you'r knowledge about how to put kickbufs not to execute, some sort of sleep where they queue commands and cpu would be active, minor bit talk to mlankhorst, then the fix should be trivial for mt
03:44 martm: imirkin: you had a convo about this, you put a semaphore in the pfifo, but leave the cpu active, you talked about this yourself
03:49 martm: imirkin: you were right about this thing, when you block the cpu to for instance reorder the cache with a shader, in contrast to cache of cpu's and parallel reordering and kickbuf/pusbuf itself, cpu is horribly slow, all that is added to the overhead, otherwise they would catch up quickly
03:56 martm: for instance cpu would do dma->vram or gart which is slowest, kickbuf would access vram with gpu or load them to the cache second slowest, reordering with shader will normally use the cache slots allready which is the fastest, so you don't want to distract the slowest while performing the reordering
04:04 martm: this is what i gather...two details i need you to find how to perform that queing of commands while not blocking cpu, and rough details about how mlankhorst patch works
04:22 martm: imirkin: yeah seems i was a bit off, the patch does not seem to change much of the behavior, it only moves the code from one place to another
04:29 martm: imirkin: so pure logics probably say if other did not arbitrate the writes of per-thread per-process push/kick writes, neither should that patch
04:31 martm: that is a lie, it really should:D
04:59 martm: - nv50_bufctx_fence(screen->cur_ctx->bufctx_3d, TRUE);
04:59 martm: + nv50_bufctx_fence(nv50, nv50->bufctx_3d, TRUE);
05:01 martm: i understand now, this fences on every context..not only on the current one..will patch it on..this should work, but slow i belive
06:29 martm: gotta read what is a notify stuff, there seem to be two types of bo's kick notify and fence ones
06:53 martm: https://hakzsam.wordpress.com/2014/06/26/a-first-attempt-at-exposing-nvidias-performance-counters-in-nouveau/ says the queries avoid stalling of the command stream
07:09 martm: soreau: do you want to break the curse me talking alone, jumping into conversation so i would not get banned cause of a monologue:)?
07:10 martm: i have 10% of that patch read from mlankhorst i still do not understand how it works, seems like a little patch but highly complex in that context
07:11 martm: return *(uint32_t *)((char *)nv30->screen->notify->map + nv30->fence->start);
07:21 martm: well in that case i expect this patch to work fast..following the hakzsam description about notify objects
07:45 martm: hakzsam: https://lists.freedesktop.org/archives/nouveau/2015-August/021807.html so it can process notify events while channel is busy/idle
07:45 martm: ?
07:45 martm: if (busy && chsw) {
07:45 martm: if (!(chan = (void *)priv->base.channel[chid]))
08:36 martm: /* wait for all activity to stop before releasing notify object, which
08:36 martm: * may be still in use */
08:36 martm: if (chan->chan && chan->ntfy)
08:36 martm: nouveau_channel_idle(chan->chan);
08:36 martm: nouveau_abi16_chan_fini
09:30 martm: very rough, embarrasing - /* Ensure the channel is no longer active on the GPU */
09:30 martm: + /* This will prevent pfifo from switching channels. */
09:30 martm: pfifo->reassign(dev, false);
09:31 martm: it seems no matter what , in contrast to what i thought, pfifo does not process the channels in parallel
09:36 martm: http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nv50_graph.c?v=2.6.38#L772
09:36 martm: have no clue, don't even understand if fence and notify bo's at all use the same channel
10:09 karolherbst: mhh I am getting better. No build error this time :)
10:32 karolherbst: mupuf: it was a good idea to try out your nve7, because the thing is wrong there currently
10:32 mupuf: karolherbst: always a good idea to test
10:32 karolherbst: yeah
10:32 karolherbst: but your nve7 has really high coefficients
10:32 karolherbst: a little error and the voltage changes a lot
10:33 karolherbst: -10229 and 20200 as c0 and c1
10:51 karolherbst: mhhh
10:51 karolherbst: it still makes sense though
10:51 karolherbst: the speedo value highly correlates with the internal factor used with the coefficients from the table
10:53 karolherbst: it is the right reg alright...
10:53 karolherbst: 0x756/0x68a (speedo nve7/speedo mine): 1.1218637992831542
10:54 karolherbst: 189/168 (factor nve7/factor mine): 1.125
10:55 karolherbst: huh, 188 also works on yours
10:55 karolherbst: 188/168: 1.119
10:55 karolherbst: so yeah....
11:09 karolherbst: okay, I am sure the formular is right for the c1 coefficient
11:11 karolherbst: huh
11:11 karolherbst: and also right for c2?
11:11 karolherbst: maybe my code just sucks
11:12 karolherbst: mupuf: any idea how to put "c2 * S^2 / 10^5" into kernel code without loosing precision through overflows and also not using any SSE2 registers?
11:13 karolherbst: well the hard part would be "c5 * S^2 * T^2 / 43112739.8" anyway...
11:13 mwk: karolherbst: what's the range of all these things?
11:13 karolherbst: mwk: usually unknown
11:13 mwk: ugh
11:13 karolherbst: but on this nve7 c1 is -10229
11:13 karolherbst: and c2 is 20200
11:14 karolherbst: I doubt there will be much higher values
11:14 karolherbst: but
11:14 karolherbst: c0 is usually something like this: 22007850
11:14 karolherbst: 20200 for c2 is unusually high already
11:14 karolherbst: so I would go for 100.000 for c1-c5
11:15 karolherbst: in the bios these are signed 32 bit values
11:15 karolherbst: and the output is a µV value
11:17 karolherbst: ohh and S is between 0x600 and 0x800 I would say
11:18 karolherbst: the c5 thing is just insane in this regard
11:18 karolherbst: c5 is usually something like 100
11:19 karolherbst: 100 * 0x800^2 * 90^2 : 4194304000000
11:19 karolherbst: ...
11:19 karolherbst: but this should be fine for a s64 value shouldn't it?
11:21 karolherbst: maybe I just have to add some casts so that the compiler doesn't do something stupid
11:23 karolherbst: ohh wait, I messed up
11:24 karolherbst: ahhh
11:24 karolherbst: 99% with loosing precision
11:24 karolherbst: mupuf: k, wrong alarm, it works :D
11:25 mupuf: great!
11:26 mupuf: yeah, s64, m°C and uV should be Ok for wrap arounds
11:26 karolherbst: yeah
11:26 karolherbst: I just added a bunch of (s64) cast to the first number (cause it is s32)
11:26 karolherbst: and fixed my / 16.75 => /168 things
11:26 karolherbst: ...
11:26 karolherbst: should have been / 17
11:27 karolherbst: well
11:27 karolherbst: mupuf: the thing is now, we are slightly below what nvidia volts to, because we will volt higher anyway
11:27 karolherbst: but we could add 2% in general just to be sure
11:28 karolherbst: currently I am at 99.8% bevause the temperature raised and nvidia dropped the voltage
11:28 mupuf: adding 5% to the voltage sounds like a reasonable safety precaution
11:29 karolherbst: the biggest error on your nve7: 1.4%@ 44°C
11:29 karolherbst: 0.4%@50°C :)
11:29 mupuf: is it +1.4% or -1.4%
11:29 karolherbst: mupuf: yeah, but you have to take into account, that we always volt higher than what we calculate
11:30 karolherbst: mupuf: it will be always -
11:30 karolherbst: if we have the same formular
11:30 mupuf: Ah, right
11:30 karolherbst: I would go for 2%
11:30 karolherbst: 5% is a bit much
11:30 mupuf: right
11:30 karolherbst: instead of 1V that would be 1.05V
11:30 karolherbst: :)
11:31 karolherbst: maybe even 1% is enough
11:31 mupuf: well, let's just gather data on more cards
11:31 karolherbst: yeah
11:31 karolherbst: and I fix my code :)
11:31 karolherbst: also I am pretty sure that the 0x10 table is just mode 0 with c0-c2
11:32 karolherbst: but I couldn't test on my fermi, cause nouveau messed something up with the cstates
11:32 karolherbst: so I couldn't map the clock to the cstates we have :/
11:34 martm: well the documention says that notify is part pgraph engine, and it can be used only if channel is inactive
11:37 karolherbst: anyway, on my GPU the calculated voltage is a little too low
11:38 karolherbst: 978959, but nvidia 981250
11:38 karolherbst: nouveau should be above 980000 :)
11:41 mupuf: karolherbst: wrong constants?
11:41 karolherbst: mupuf: yeah
11:41 karolherbst: the funny ones
11:41 karolherbst: well not so funny
11:42 karolherbst: mode 1, c0 and c2 being used
11:42 karolherbst: c0 / 16.75 + c2 * T * 15.3
11:42 karolherbst: I am sure mode0 looks good, because of the /10 being used and it looks rather clean
11:43 mupuf: What about the 16.75 and 15.3 constants?
11:43 mupuf: are they also found on the tegra code?
11:43 karolherbst: no
11:44 karolherbst: the tegras code sucks to be honest. I don't want to rely on it, no offense meant, but it looks more hacked up then carefully coded
11:44 karolherbst: they always pass -1 as the temperature
11:44 karolherbst: so...
11:45 mupuf: for nouveau or the nvgpu?
11:45 karolherbst: nouveau
11:45 karolherbst: ohh you meant for nvgpu
11:45 mupuf: yes
11:45 karolherbst: I could check there, right
11:45 karolherbst: but I never find the source...
11:46 mupuf: https://android.googlesource.com/kernel/tegra/+/b445e5296764d18861a6450f6851f25b9ca59dee/drivers/video/tegra/host/gk20a
11:46 karolherbst: thanks
11:50 karolherbst: huh
11:51 karolherbst: I think I am getting blind, I don't find anything voltage related...
11:51 mupuf: the code may not be in there
11:51 mupuf: but in the cpu part
11:54 RSpliet:pokes karolherbsts eye sockets
11:54 RSpliet: nope, eyes still there!
11:56 karolherbst: mupuf: nope, no magic values there
11:57 karolherbst: but then again, the voltage stuff is much simplier on the tegras for whatever reasons
12:02 mupuf: karolherbst: ack
12:02 karolherbst: I will just try to get a better accuracy with the constants on my GPU
12:02 karolherbst: now that I know that there are those speedo values, it might be easier to get cleaner values
12:02 mupuf: :)
12:07 martm: https://media.readthedocs.org/pdf/envytools/latest/envytools.pdf 169 page, that is better one, i am close to parsing the info, still yet a bit vague
12:27 martm: now if understand it right, there is a bit logic fault in the documentation, the pgraph channel can be accessed anytime while channel is busy, but is processed when idle right?
12:28 martm: is processed by pfifo when being idle, is that so mwk?
12:33 martm: it should then squeeze all the contexts into one channel as i understand, can't parse what is per-context pushbufs though
12:37 martm: yeah all is good...it says on subchannel switches, yeah it really switches in round robin fashion, yeah correct according to docs
12:37 karolherbst: mupuf: should I take the lowest factor with the expected value?
12:37 martm: subcontext_ID would do on the same channel
12:37 martm: notify_valid would switch to a new channel indeed
12:37 karolherbst: mupuf: like when 16.75 and 16.74 result in the same voltage set, I prefer 16.74?
12:40 karolherbst: 16.666 for mode1 c0
12:40 karolherbst: ...
12:41 martm: hakzsam: can you talk with me, mwk does not, do you think this PGRAPH per object state engine for notify interrupt can be accessed when pfifo channel is active, and it adds it to the end right and proccesses when channel becomes idle?
12:46 karolherbst: mhhh mupuf: 16.66084444444444444....
12:47 karolherbst: (166608+4/9)/10000
12:48 karolherbst: but, what is this number
12:49 martm: The notifiers are 16-byte memory structures accessed via DMA objects, used for synchronization. Notifiers are written by PGRAPH when certain operations are completed. Software can poll on the memory structure, waiting for it to be written by PGRAPH. The notifier structure is:
12:50 martm: i think it's time to try to patch my mesa, is that certain operation when a context has finnished for instance?
12:51 martm: as the relocations are allready long since removed, that leaves only scheduler to be implemented if that patch works
12:54 martm: i am not sure if there are some hazards possible in gallium which make makes it not working..however i have not yet patched my sources
13:05 martm: minorly have to yet read, i am doing sleeping and reading one after another, docs seem to be good again, will control the code with another readthrough and then try
13:08 martm: i am just wondering, if there never appears to be more then one channel active, what is the friggin point of having multiple channels then?
13:23 martm: anyways it seems that active is not what i mean, so probably the channel cah prepare itself before becoming active, and that probably is done in parallel, and the notify switches among executable channels which are ready
13:23 martm: i.e according to documentation when the channel becomes idle, it fetches a new context to execute from pgraph?
13:31 martm: dunno so how to detect if channel has some contents and is not yet executing
13:37 martm: i can not understand why would one need 127channels:D do you have like 127core cpu's?
13:38 martm: aaah right the context can be saved and restored too...
13:40 martm: over one hundred channels is still a terrible amount though:D
13:51 martm: imirkin: you'd forgive today too right, hopefully this is the last pollusion/polluting of the channel?
13:51 martm: logs
13:52 mupuf: karolherbst: well, do not try to round the values
13:52 mupuf: and we'll see
13:52 karolherbst: yeah
13:52 karolherbst: I am done now anyway
13:52 mupuf: this is already much better than what we have
13:52 karolherbst: new vlaues: https://gist.github.com/karolherbst/2c298b2cdb6eebe5a24e2e34ea8d37b2
13:52 mupuf: did you check how close do the new numbvers get us to the blob?
13:53 karolherbst: I only set one of those c values and see which gets me to the one I want
13:53 karolherbst: like if c5 0xe4cd48 is 0.9V, but 0xe4cd47 is 0.8975V
13:53 karolherbst: then I use the factor of the former one
13:53 karolherbst: when I wanted 0.9V
13:58 karolherbst: mhh
13:58 karolherbst: the difference is still too big on my GPU
14:03 karolherbst: mupuf: somewhere nvidia rounds unexpected :/
14:03 karolherbst: mupuf: well currently it is 0.3% close on my gpu
14:03 karolherbst: 0.25% even
14:03 karolherbst: but this is too much
14:04 mupuf: please tell me how you test the difference
14:04 karolherbst: nvidia uses +1 PWM what nouveau would set with rounding up
14:04 karolherbst: mupuf: read out what nvidia set in the PWM reg and calculate what nouveau would set for same cstate+temperature
14:04 mupuf: ack
14:05 karolherbst: but it is 978819 vs 981250
14:05 karolherbst: nouveau should be above 980000 and below 981250
14:05 karolherbst: I am sure nvidia has a weird rounding somewhere which only occurs when combining all those coefficients
14:06 mupuf: sounds like a lot of fun :s
14:06 karolherbst: like round_up(c0 / 10) + round_up(c1 * S / 10)
14:06 mupuf: can you reproduce on other how?
14:06 karolherbst: yeah I will check on your nve7 again
14:06 mupuf: sounds really possible
14:06 mupuf: my e7 only has a few voltages, how do you check?
14:07 karolherbst: with my tool. it basically calls nvkm_volt_get
14:07 karolherbst: and reads the clocks out with nouveaus stuff
14:07 mupuf: ack, but how do you get such good errors :D
14:07 mupuf: when 1 step would bring something like 5% error
14:07 karolherbst: what do you mean?
14:07 karolherbst: yeah well, I put a lot of time REing those factors :D
14:08 karolherbst: I find the exact values, where nvidia changed the voltage one step higher
14:08 karolherbst: and those coefficients are usually 0x5000 high
14:08 karolherbst: or something like that
14:08 karolherbst: so there is a big accuracy already
14:09 karolherbst: or what did you mean?
14:10 mupuf: I understand this, but I meant, how many voltage steps are there on my e7?
14:10 mupuf: on the maxwell, an error of 1 step is almost nothing
14:11 mupuf: 1 step on my e6 or e7, there are something like 30 steps. right?
14:11 karolherbst: ohh
14:11 karolherbst: wait
14:11 mupuf: so, that's 3% error if we have an off by one
14:11 karolherbst: on your nve7 one step is 12500 µV
14:13 mupuf: so, an off-by-one is 1% at best, then
14:13 karolherbst: yeah
14:13 mupuf: 1.5 at worst
14:14 karolherbst: biggest error on your nve7: 1000000, 987450, -12550, 98.745000, 15, 1, 43
14:14 karolherbst: 44 nvidia volted to 987500
14:14 karolherbst: and on 42°C we have an absolute error of -12012
14:14 karolherbst: so the only difference would be at 43°C by one step
14:15 karolherbst: and with 42°C we would 987988 -> 1000000 because of uprounding in the volt_set_id function
14:16 karolherbst: this looks so good :) https://gist.github.com/karolherbst/f4f79e24fbc7bf45c042c49ec0426e52
14:16 martm: http://dpaste.com/3TRVGH9
14:16 martm: needs to be all done manually:D so many failures
14:17 karolherbst: mupuf: so I would say, we just ad 0.2% voltage
14:17 karolherbst: *add
14:17 karolherbst: or maybe 0.5%
14:17 karolherbst: this should be enough
14:17 mupuf: karolherbst: what about this: take care of the rounding errors by always using the next step?
14:17 karolherbst: if it is terribly wrong somewhere, we are screwed anyway
14:17 karolherbst: mupuf: then we volt higher
14:17 mupuf: yes
14:17 karolherbst: but we don't want to volt higher :D
14:17 mupuf: we want stuff to work for sure
14:17 karolherbst: yeah
14:17 mupuf: and 1.5% higher is really no big deal
14:18 karolherbst: well in the end this decreases performance
14:18 mupuf: right, it lowers the max clock
14:18 karolherbst: yes
14:18 mupuf: well, you know what, we are talking about boost anyway
14:18 karolherbst: right
14:19 mupuf: let's not be too aggressive with the voltage yet
14:19 mupuf: so, I would vote for a +1 until we have enough data points
14:19 karolherbst: I think adding 0.5% is fine and if somebody complaints it crashes, we investigate why it did
14:19 mupuf: well, +0.5% won;t take care of the issue for sure
14:19 mupuf: only going to the next voltage would
14:20 karolherbst: well if we are in avarage 99.25% close
14:20 karolherbst: then adding 0.5% gives us a high enough voltage to get to the next step if we would set it too low
14:20 mupuf: but no guarantees :D
14:20 karolherbst: no, but then something is wrong anyway
14:21 mupuf: well, to be fair, I am sure nvidia already added safety margins
14:21 karolherbst: yeah
14:21 mupuf: but ... I feel un-easy forcing that to our users
14:21 karolherbst: I can undervolt my gpu my more then 5%
14:21 mupuf: but it we are talking about the temperature-related volting, this is really no big deal
14:21 karolherbst: usually 10% works
14:22 mupuf: well, how about have a knob for this?
14:22 karolherbst: yeah
14:22 karolherbst: I though about this
14:22 karolherbst: config=NvVoltOffset
14:22 karolherbst: and you can specify a mV value
14:22 mupuf: factor, not offset
14:22 karolherbst: mhh a factor won't do really
14:22 mupuf: why?
14:22 karolherbst: and then we would parse string floats and stuff
14:23 karolherbst: because the volting stuff jumps linear
14:23 mupuf: ok, so offsets can actually make sense
14:23 karolherbst: 1% on low voltage behaves differently than 1% on high
14:23 mupuf: yes
14:23 mupuf: ok, let's go for offset in mV
14:24 mupuf: or uV, to be future proof
14:24 karolherbst: mhhh
14:24 karolherbst: more future proof than PWM?
14:24 mupuf: PWM with 16 bits, yeah!
14:24 karolherbst: I really don't think anybody cares about such a tiny difference, because it won't matter much
14:25 karolherbst: it just means, instead of downclock at 46°C it will at 45°C ! wuhu
14:25 mupuf: ok, this is bikeshedding, go for whatever you want
14:25 mupuf: but the offset is good for debugging voltage issues
14:25 karolherbst: yes
14:26 karolherbst: and I am sure users will get a uV value more often wrong than a mV value
14:26 mupuf: we can force +500mV to be sure we do the right thing :D
14:26 karolherbst: :D
14:26 karolherbst: or
14:26 karolherbst: if the gpu crashes for a user, he can always add a value himself
14:26 karolherbst: and he will also maybe report it at the same time
14:26 mupuf: hopefully
14:26 karolherbst: thing with forcing a higher votlage is, that nobody will bother us
14:26 mupuf: amd overclockers can do their things
14:27 mupuf: and*
14:27 karolherbst: yeah
14:27 karolherbst: this is nice for overclocking
14:27 karolherbst: we just have to allow negative values
14:27 mupuf: yep
14:27 mupuf: ok, sounds like a plan
14:27 mupuf: let's test my other keplers tonight
14:28 karolherbst: yeah
14:28 mupuf: and fermis, if needed
14:28 karolherbst: mhh right
14:28 karolherbst: on fermi I have to check why my tool doesn't work
14:30 karolherbst: mupuf: also nvidia has an option for a voltage offset, but there is no real GPU where you can actually use it...
14:30 karolherbst: and I have no idea what it does
14:30 karolherbst: maybe it increases the software max voltage?
14:30 karolherbst: no clue
14:31 karolherbst: I can set a value between 0-0 for it, so....
14:36 karolherbst: uhhh
14:36 karolherbst: the pstates have no cstates?
14:37 karolherbst: ohhh
14:37 karolherbst: the cstate list isn't filled
14:37 karolherbst: just pstate->base
14:37 karolherbst: yeah, that explains a lot
14:39 karolherbst: ohh no cstep table
14:47 karolherbst: mupuf: on 0f nouveau reads out a memory clock of 8613000 on your gf116 :/
14:47 karolherbst: and the pstate has it set to 2150000
14:48 mupuf: more clock tree issues, yeepee :p
14:53 karolherbst: awesome
14:53 karolherbst: and abs() was missing in my tool
14:53 karolherbst: nouveau now: 9% volting error
14:53 karolherbst: let's check with my stuff
14:58 karolherbst: ohh close enough
15:00 karolherbst: mupuf: with my code on your gf116: 1112500, 1105466, -7034, 99.367730, 15, 0, 63, 8613000
15:02 mupuf: not bad at all!
15:02 karolherbst: yeah
15:02 mupuf: do we *ever* return something higher than what nvidia sets?
15:02 karolherbst: mhhhh
15:02 karolherbst: didn't see anything with the new factors
15:02 karolherbst: well
15:03 karolherbst: sometimes we get 100%
15:03 karolherbst: but thats because max==min
15:03 karolherbst: :D
15:04 mupuf: hehe
15:04 mupuf: otherwise, we always get less?
15:04 karolherbst: well only on those three cards tested
15:04 karolherbst: and not every temperature
15:05 mupuf: ok, so we sometimes have more
15:05 mupuf: which again may be due to rounding errors
15:05 karolherbst: maybe
15:05 karolherbst: right
15:06 karolherbst: but your nve7 doesn't have many cstates anyway, so no fun testing on it
15:07 mupuf: the maxwell v2 would be great ... but we have this bug in the clock tree
15:07 karolherbst: yeah
15:07 mupuf: will be nice to see when it is ironed out
15:07 mupuf: I will have a look at your patches this week end
15:07 karolherbst: ohh
15:07 mupuf: I mean, the ones on the ML
15:07 karolherbst: k, then I have to clean the stuff up again :D
15:07 karolherbst: ahh okay
15:07 mupuf: the v3
15:07 karolherbst: yeah the new stuff won't differ much anyway
15:08 karolherbst: yeah, then I will also take care of those issues in v4 then
15:08 karolherbst: but now everything looks really good
15:09 karolherbst: nvidia volts a little slow...
15:10 karolherbst: ....
15:10 karolherbst: mupuf: I think the network issues are getting worse
15:10 mupuf: hakzsam said the same
15:11 karolherbst: now I had like 5 lags in 10 seconds
15:11 karolherbst: and 1 second long ones
15:11 mupuf: I see that
15:11 martm: i am trying to build raw mlankhorst branch, but even this one fails during compilarion
15:11 martm: nv30/nv30_screen.c: In function 'nv30_screen_fence_emit':
15:11 martm: nv30/nv30_screen.c:334:23: error: 'struct nouveau_screen' has no member named 'pushbuf'
15:12 mupuf: I should write a tool that finds these spikes and check locally and remotely
15:12 mupuf: because it is also an issue locally
15:12 mupuf: the modem is out of the waranty
15:12 mupuf: I will test the bridge mode
15:12 mupuf: on my main machine
15:12 mupuf: and install a dhcp server there
15:13 mupuf: and see if it works better
15:13 karolherbst: mupuf: the problem with getting those factors is, is that all coefficients from the bios can be positive or negative, so I went for the absolute smallest value
15:13 mupuf: and if it does, either I will buy a new router or just setup my own system on my main machine
15:13 karolherbst: your nve7 is awesome by the way
15:13 mupuf: why?
15:13 karolherbst: https://gist.github.com/karolherbst/6ff11ff95725acaa0684a0ff158db0d5
15:13 karolherbst: because the entire range from min to max is used
15:13 karolherbst: and this gives such a nice scale
15:14 mupuf: so glad you took the time to write this tool
15:14 karolherbst: :D
15:17 karolherbst: well I will play something with spiky load on my gpu and cycle between some temperatures, lets check what this gives us
15:18 mupuf: add a notify-send when you get over 2% difference
15:20 karolherbst: mupuf: there ya go: 862500, 862575, 75, 100.008696, 15, 19, 41
15:20 karolherbst: ohh even 1.7% above once
15:20 karolherbst: ohh
15:20 karolherbst: that was while reclocking
15:21 karolherbst: ahh no, temperature jumped
15:28 mupuf: I think I got how how will handle those subtest for piglit in ezbench
15:31 karolherbst: stupid nvidia... it doesn't want to drop the cstate too low
15:39 karolherbst: mupuf: biggest relative difference on mine: 893750, 885527, -8223, 99.079944, 15, 22, 26
15:40 karolherbst: https://gist.github.com/karolherbst/19ae59a23fc2aa659a6d9321c7ff0153
15:52 karolherbst: mupuf: the function pointer handling in volt/gk104.c is a bit tricky, I need a new function pointer for the speedo and it will be different for gf100, gk104 and gm107
15:57 karolherbst: mhh maybe I make two structs out of the gpio/pwm thing
15:58 karolherbst: and then we do volt->func.volt->get or volt->func.pwm->get
15:58 karolherbst: ...
15:58 karolherbst: still messy
15:58 karolherbst: vid/vold
16:02 martm: imirkin_: well sadly mlankhorst patch does not run Warthunder too
16:02 martm: patch/branch
16:16 celes: hello everyone
16:16 celes: i have read that nouveau is ok on Wayland. There is some documentation on it?
16:17 mupuf: ah ah
16:17 karolherbst: ...
16:17 karolherbst: really?
16:17 mupuf: the guy was quicl
16:17 mupuf: anyway
16:18 mupuf: my code to aggregate subtests in one go worked!
16:18 karolherbst: awesome
16:18 mupuf: so well that I now get: OSError: [Errno 7] Argument list too long
16:18 mupuf: :D
16:18 karolherbst: yeah well
16:18 mupuf: apparently, the command line is too long now
16:18 karolherbst: yeah
16:18 mupuf: I checked and the limit was supposed to be 2M
16:18 karolherbst: there is a limit
16:18 karolherbst: 65500 something chars I think?
16:18 mupuf: at least on arch
16:19 martm: nouveau: kernel rejected pushbuf: Invalid argument
16:19 martm: nouveau: ch0: krec 0 pushes 1 bufs 0 relocs 0
16:19 martm: that is what i am getting with maartens branch
16:19 karolherbst: xargs --show-limits
16:19 mupuf: Maximum length of command we could actually use: 2091602
16:19 celes: sorry for my connection :s
16:19 mupuf: celes: ah ah, we wondered how impatient you would have been :D
16:19 mupuf: no documentation, just start wayland like you would normally do
16:20 mupuf: it works the same way on nouveau and intel
16:20 karolherbst: mupuf: or getconf ARG_MAX
16:20 mupuf: karolherbst: yeah, but it still does not explain why I reached 2M that quickly
16:20 karolherbst: right
16:20 celes: okay, but inforutnatly i'm on a laptop
16:21 karolherbst: celes: you want to use wayland on your main gpu
16:21 celes: so Optimus
16:21 karolherbst: and just offload rendering on your nvidia gpu
16:21 karolherbst: the same on X with DRI3 basically
16:21 celes: but xrandr --listproviders give me 0
16:21 mupuf: karolherbst: I am at 157k, far from 2M
16:22 karolherbst: mupuf: odd
16:22 celes: i have done something wrong?
16:22 karolherbst: celes: depends
16:22 karolherbst: celes: is nouveau loaded?
16:22 karolherbst: but
16:22 mupuf: celes: why do you check xrandr if you want to run with wayland?
16:22 karolherbst: on wayland you don*t use X tools
16:22 mupuf: there is nothing like prime on wayland, AFAIK
16:22 celes: mupuf : because i didn't find the way to do it on wayland
16:22 karolherbst: mupuf: huh?
16:23 karolherbst: DRI_PRIME=1 glxinfo
16:23 karolherbst: this should work on wayland
16:23 mupuf: karolherbst: because it uses xwayland :D
16:23 karolherbst: yeah
16:23 karolherbst: right
16:23 mupuf: you cannot start your compositor on nouveau
16:23 mupuf: or, maybe you can, but it depends on the configuration of your compositor
16:23 karolherbst: but in a wayland shell you should be able to just use DRI_PRIME
16:23 mupuf: and every compositor can do what it wants
16:24 karolherbst: starting a compositor on the dedicated gpu is insane anyway
16:24 mupuf: if you want to run an X app, yes
16:24 mupuf: but what about SDL apps?
16:24 karolherbst: sure that it doesn't work with egl apps?
16:24 mupuf: how would it work?
16:25 karolherbst: :O
16:25 karolherbst: really?
16:25 karolherbst: this is still planned,r ight?
16:25 celes: so i won't be able to use my nvidia whitout xwayland?
16:25 karolherbst: because if this won't work ever, then what the heck?
16:25 mupuf: celes: yep, at least for now
16:25 mupuf: karolherbst: vulkan allows the app to choose the GPU
16:25 karolherbst: ....
16:25 celes: mupf : okay, i'll try the xwayland way thanks
16:25 mupuf: and I guess we'll need a way to tell the libgl which driver we want to use
16:25 karolherbst: yeah
16:26 mupuf: (to cover gl)
16:26 celes: nouveau support wayland? i didn't see anything on google
16:26 celes: *vulkan
16:26 mupuf: celes: nope, it does not :D
16:27 mupuf: and so far, no plans for it either
16:27 mupuf: this will come, for sure
16:27 celes: mupuf : that was to be sure ^^
16:27 mupuf: but first, gl 4.5 and performance tweaks
16:27 karolherbst: yeah well, when the GL stuff is worked out
16:27 karolherbst: celes: currently the benefit is too small and more important things are on the list
16:28 mupuf: hopefully, by then, we will have a good SPIR-V frontend
16:28 mupuf: yep, and the environment is very unstable anyway
16:28 karolherbst: right
16:28 mupuf: and let's wait for intel's vulkan driver to land too
16:29 celes: karolherbst : yeah i see that, just too impatient to work on it
16:29 karolherbst: celes: well use intel for now
16:29 celes: karolherbst : i'm not sure i can, i'll check that
16:30 karolherbst: mupuf: you have no idea which would be a good way to improve the volt/gk104.c function pointer situation?
16:30 karolherbst: celes: you should be
16:30 mupuf: karolherbst: not now, I have to go
16:30 karolherbst: mupuf: k
16:30 karolherbst: celes: if your setup is sane, Intel is your main GPU anyway, so everything runs on Intel by default
16:31 karolherbst: celes: and so you should be able to use vulkan on intel without any problems
16:31 karolherbst: celes: you just need to compile mesa yourself I think, because it isn't merged yet, there is a vulkan branch
16:31 celes: karolherbst : any intel gpu is able to run vulkan?
16:31 karolherbst: celes: no idea, I think it is done for haswell and newer? but no idea
16:32 karolherbst: there are also some gen6 related things
16:32 karolherbst: gen6 is sandybridge I think
16:33 celes: karolherbst : yep i wil check but i don't think that my 3rd gen will be okay x)
16:33 karolherbst: 3rd gen?
16:33 karolherbst: isn'tr this like before optimus ever existed
16:33 karolherbst: or do you mean 3rd HD gen?
16:34 karolherbst: aka ivy bridge
16:34 celes: karolherbst : GTX 675MX, i don't see hd, just Intel Corporation 3rd Gen Core processr Graphics Controller (rev 09)
16:34 karolherbst: ahh
16:34 karolherbst: uname -a
16:35 karolherbst: or just
16:35 karolherbst: uname -p
16:35 celes: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz
16:35 karolherbst: ivybridge it is
16:35 karolherbst: should be fine I guess
16:35 karolherbst: ask in #intel-gfx
16:36 celes: okay ^^ thanks
16:36 celes: if i'm able to work on vulkan with that, i'll venerate you
16:37 karolherbst: why me? the intel guys did all the work :D
16:37 celes: them too :)
16:58 martm: 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
16:58 martm: that kernel is probably a bit old too
17:06 mupuf: karolherbst: ivy bridge is not supported for vulkan
17:06 karolherbst: ahh okay
17:06 mupuf: hsw+
17:06 karolherbst: didn't know that
17:06 karolherbst: but only currently or not planned at all?
17:07 karolherbst: nvd7 has no volt subdev, is this intentionally?
17:07 karolherbst: *intentional
17:10 karolherbst: mhh I should work on my commit messages
17:10 karolherbst: uhh
17:10 karolherbst: mlankhorst: you have a nice nvd7 :)
17:11 karolherbst: ohh wait, maybe not
17:11 karolherbst: this is weird
17:19 martm: i am sorry for the spam all that patchset spammed seems to be step backwards from master, for some totally odd reason, it does not get a bo at all
17:27 karolherbst: uhh somebody asked me if there is anything new to test, but I forgot who it was...
17:27 karolherbst: now I have something :)
17:52 karolherbst: mhhh
17:56 Rigoletto: karlmag, me :D
17:56 Rigoletto: karolherbst, me!!!
17:56 karolherbst: ahh okay
17:56 karolherbst: what gpu do you have?
17:56 Rigoletto: gk106
17:57 karolherbst: awesome
17:57 karolherbst: you built nouveau from my branch out of tree?
17:57 karolherbst: mhh doesn't matter
17:57 karolherbst: Rigoletto: are you using nvidia currently?
17:58 Rigoletto: karolherbst, i am Misanthropos.. just on a different pc. i use nouveau
17:58 karolherbst: ohhh
17:59 karolherbst: okay
17:59 karolherbst: then please switch to nvidia for a test :D
17:59 Rigoletto: ok
18:01 imirkin_: karolherbst: pretty sure nvd7 is just accidentally missing the volt subdev
18:01 karolherbst: imirkin_: yeah, it seems that way
18:01 karolherbst: imirkin_: I've already added it in my patch
18:01 karolherbst: not that it matters much
18:01 karolherbst: ...
18:01 karolherbst: uhhh
18:01 karolherbst: gr fuc code uses mov
18:02 karolherbst: shouldn't be a big problem, but still
18:02 Misanthropos: karolherbst, kernel 4.4.0 with nvidia up and running
18:02 karolherbst: Misanthropos: k, update the repository you got from me
18:03 karolherbst: git fetch origin; git reset --hard origin/stable_reclocking_kepler_v2
18:03 karolherbst: and run make in the top dir of it
18:04 Misanthropos: and use nv_cmp_volt?
18:04 karolherbst: yeah
18:05 Misanthropos: current voltage (µV), expected voltage (µV), abs diff (µV),rel diff nouveau/nvidia (%), pstate, cstate, temperature(°C)
18:05 Misanthropos: 862500, 852008, -10492, 98.783536, 7, 0, 33
18:07 karolherbst: yeah, for a while longer
18:07 karolherbst: play someting or so. I would like to see the output of around 1 or 2 hours
18:07 Misanthropos: 1087500, 1077264, -10236, 99.058759, 15, 2, 35
18:07 Misanthropos: ok
18:08 martm: i updated my kernel to 4.4
18:13 karolherbst: Misanthropos: mhh after a look at your vbios, maybe it is okay now there isn't that much and I think most of it is already covered by now
18:19 Misanthropos: karolherbst, so you have a kernel for me to test?
18:20 Misanthropos: btw. the nvidia driver performs worse than nouveau
18:20 karolherbst: Misanthropos: first the output :p
18:20 karolherbst: but I will try to create a new kernel tree after the weekend
18:20 Misanthropos: 1087500, 1074126, -13374, 98.770207, 15, 2, 42
18:20 karolherbst: nothing more?
18:20 karolherbst: usually I expect like hundreds of lines :D
18:21 Misanthropos: oh.. sure
18:21 Yoshimo: pastebin it
18:23 Misanthropos: strange.. it stopped printing values...
18:23 karolherbst: yeah
18:24 karolherbst: at some point it stops when nothing changes
18:24 Misanthropos: https://bpaste.net/show/4584f781406a
18:24 karolherbst: thanks
18:25 karolherbst: Misanthropos: can you execute nvaforcetemp 45 and give me the last line?
18:27 Misanthropos: last line from nv_cmp_volt?
18:27 Misanthropos: 1075000, 1072622, -2378, 99.778791, 15, 2, 45
18:27 karolherbst: okay
18:28 karolherbst: mupuf: as it seems the newest formular is the same good on every tested card so far :)
18:29 karolherbst: so we might get away with just add the missing voltage in the worst case, which seems to be something like 2 or 3 mV
18:29 karolherbst: more like 2mV though
18:30 mupuf: ah ah
18:31 Misanthropos: that means progress? ;D
18:31 karolherbst: yeah we can't help it in the end
18:31 mupuf: karolherbst: want another card?
18:31 karolherbst: mupuf: yeah
18:31 karolherbst: your nve6 again and another fermi :)
18:32 mupuf: ok
18:32 mupuf: can you shut reator down?
18:32 karolherbst: hakzsam: did it
18:32 karolherbst: ...
18:32 karolherbst: hakzsam did it
18:32 karolherbst: :D
18:32 mupuf: karolherbst: ? you mean he is using it?
18:32 karolherbst: mupuf: well in the end we would have to fake the VID table and get a much higher accuracy
18:33 karolherbst: mupuf: I think so
18:33 karolherbst: he turned it on 5 hours ago
18:33 mupuf: hakzsam: tell me when you are done
18:34 karolherbst: but I think faking the VID table can upset nvidia in multiple ways :/
18:46 hakzsam: mupuf, no I don't use it :)
18:46 hakzsam: I was just making a MMT
19:00 mlankhorst: karolherbst: I no longer have access to the nvd7 :(
19:01 karolherbst: mlankhorst: ohh well
19:02 mupuf: karolherbst: c8 and e6 plugged!
19:02 karolherbst: mupuf: thanks
19:09 mlankhorst: only have a c0 right now which runs the blob
19:13 karolherbst: mupuf: on your nve6 I am above one voltage step at any time
19:14 karolherbst: but there isn't much going on though
19:14 mupuf: karolherbst: hmm
19:14 mupuf: so there is still something going on
19:14 karolherbst: ohh
19:14 mupuf: ping me when you need a new card
19:14 karolherbst: wait
19:14 karolherbst: no
19:14 karolherbst: I meant something else :D
19:15 karolherbst: I meant the absolute error is smaller than a voltage step
19:15 mupuf: nice!!!
19:15 karolherbst: I will cycle through cstates now
19:16 karolherbst: k
19:16 karolherbst: never above nvidia and never error bigger than one voltage step
19:17 karolherbst: now the fermi
19:17 Yoshimo: is it feasible to bring the difference to 0?
19:18 karolherbst: no
19:18 karolherbst: a voltage step is 12.5mV on GPIO based cards
19:18 karolherbst: that's not much
19:19 karolherbst: nvidia just doesn't tell us what voltage they try to set, so this is a bit messy to get
19:20 karolherbst: mupuf: same with your gf110.
19:20 karolherbst: mupuf: done with both cards :)
19:21 karolherbst: sample 6 and on all this is quite good
19:21 karolherbst: now we are getting somewhere
19:23 karolherbst: mupuf: can you plug another fermi and one kepler2 (if you don't have any kepler1 left)
19:57 karolherbst: mupuf: will you have still time to change the cards today or will we continue tomorrow?
19:57 mupuf: sorry
19:57 mupuf: I can change them now
19:57 karolherbst: k, thanks
19:59 mupuf: d9 and c1
19:59 karolherbst: thanks
19:59 mupuf: and I have at ce, c1 and c0 for you afterwards
20:00 karolherbst: awesome
20:00 karolherbst: mhhh
20:00 karolherbst: the d9 is useless by the way
20:00 karolherbst: only c0 set
20:00 karolherbst: and min==max
20:01 karolherbst: huh
20:02 karolherbst: ohhh
20:03 karolherbst: nv180
20:03 karolherbst: okay
20:03 karolherbst: this one is usefull
20:04 karolherbst: mupuf: skip the c1, it has a broken table
20:06 mupuf: karolherbst: ping me when you want me to plug the c0 and ce then
20:09 karolherbst: yeah, I am off by a few mV
20:09 karolherbst: not more than 10mV
20:09 karolherbst: I mean 1.0mV
20:12 karolherbst: mupuf: k, you can plug those two now :)
20:12 mupuf: karolherbst: ok!
20:12 karolherbst: but it looks good
20:13 karolherbst: when I look at this it means we are really good now: https://gist.github.com/karolherbst/e9fbcbec309e82dc37f2e29eff052984
20:13 karolherbst: and I am sure we are just off my 1mv
20:14 karolherbst: maybe 2
20:14 mupuf: karolherbst: can't plug the two at the same time, I lack PCIe power sockets
20:14 karolherbst: uhh
20:15 karolherbst: low power maxwell maybe?
20:15 karolherbst: I could at least verify lower cstates
20:15 karolherbst: and I think the issue is only there on faster maxwells
20:15 karolherbst: well
20:15 karolherbst: higher clocked ones
20:15 mupuf: hmm, did not work
20:15 mupuf: let me try again
20:16 karolherbst: I know that you had a fancy card which didn't like a slot
20:18 karolherbst: mupuf: if the maxwell doesn't want, I can just check the fermi
20:25 mupuf: karolherbst: the nvc0 works now
20:25 mupuf: have fun, I will plug the maxwell 1 and ce afterwards
21:01 pmoreau: ZanQdo: System should still boot even if Nouveau is blacklisted. Maybe try booting to lvl3 with nomodeset=1 on the kernel command line, log in and remove the blacklist.
21:09 karolherbst: hakzsam: do you do something on reator now? I was away for a brief moment
21:10 hakzsam: karolherbst, yep, making mmt traces
21:10 karolherbst: ahh okay
21:13 karolherbst: hakzsam: how long do you need?
21:13 hakzsam: karolherbst, give me one minute :)à
21:15 hakzsam: karolherbst, feel free to reboot or wtvr
21:18 hakzsam: karolherbst, can I take another trace very quickly? :)
21:18 karolherbst: hakzsam: yeah
21:18 hakzsam: cool
21:20 hakzsam: done thanks
21:33 pmoreau: karolherbst: Do you still have a pre-2.23 glibc version?
21:33 karolherbst: pmoreau: yes
21:34 pmoreau: Great! Could you test a little patch in a few minutes (about `std::isinf()`)?
21:34 karolherbst: pmoreau: k
21:35 karolherbst: pmoreau: patch against what?
21:35 pmoreau: Against Mesa
21:35 pmoreau: The isinf in nv50_ir_ra.cpp which breaks when building with C++11
21:35 karolherbst: ahh okay
21:35 karolherbst: so just a build test?
21:37 pmoreau: Yup
21:37 karolherbst: k
21:39 pmoreau: karolherbst: Here it is: https://phabricator.pmoreau.org/P96
21:40 karolherbst: mupuf: your maxwell is fine
21:48 karolherbst: pmoreau: just on top of mesa master?
21:49 pmoreau: Exactly
21:58 karolherbst: pmoreau: it compiles at it seems
22:06 mupuf: karolherbst, hakzsam: what do I plug next?
22:07 hakzsam: one fermi?
22:10 karolherbst: mupuf: mhhh wait a second, I'll explain later
22:10 hakzsam: mupuf, maybe the maxwell2 to test compute shaders, I have never tried :)
22:11 pmoreau: karolherbst: Ok. And if you remove the two glibc checks inside the patch?
22:14 karolherbst: mupuf: k, I am done for today
22:14 karolherbst: the maxwell still behaves a bit odd without the right clock reading
22:14 karolherbst: the fermi was good though
22:17 mupuf: karolherbst: I plugged another fermi along with the maxwell
22:17 mupuf: 2
22:45 hakzsam: imirkin_, mupuf awesome! compute shaders on GM206 work like a charm :)
22:46 hakzsam: except one minor thing that I'm going to send
22:46 imirkin_: nice
22:46 hakzsam: I have exactly the same fails as other kepler+ chips
22:48 hakzsam: imirkin_, just for fun, I'll trace the blob to see what it does for images :)
22:48 imirkin_: hakzsam: on GM20x?
22:48 hakzsam: yup?
22:48 hakzsam: we cant?
22:48 imirkin_: hakzsam: could you also tests whether ASTC is supported on there?
22:49 hakzsam: mmh yeah but later (tomorrow or so) because it's late here
22:49 imirkin_: k
22:51 hakzsam: uhu, suatom
22:51 hakzsam: cool
22:51 imirkin_: heh
22:51 imirkin_: that's like cheating
22:51 hakzsam: http://hastebin.com/povovukayu.pl
22:51 imirkin_: they made all the annoying stuff no-longer-annoying
22:51 hakzsam: how long it takes to check for ASTC?
22:52 imirkin_: i dunno... like 3 minutes?
22:52 hakzsam: what are the instructions?
22:52 imirkin_: run
22:53 hakzsam: run what? :)
22:53 imirkin_: MESA_EXTENSION_OVERRIDE=GL_KHR_texture_compression_astc_ldr bin/khr_compressed_astc-miptree_gl -fbo -auto
22:53 imirkin_: it will complain
22:53 imirkin_: and tell you that you forgot a few things
22:53 imirkin_: but i don't remember what they are
22:53 hakzsam: do you want a MMT of this?
22:53 imirkin_: no
22:53 imirkin_: i want to know if you get stuff in dmesg or not
22:54 hakzsam: Test requires GL_KHR_texture_compression_astc_ldr
22:54 hakzsam: PIGLIT: {"result": "skip" }
22:54 imirkin_: and what it prints to stdout
22:54 imirkin_: you forgot the ext override
22:54 hakzsam: I didn't
22:54 imirkin_: gr
22:54 imirkin_: ok, then edit this code:
22:54 imirkin_: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c#n76
22:55 hakzsam: err, what? I thought it was with the blob
22:55 hakzsam: let me reboot
22:56 imirkin_: that's why the override didn't work
22:56 hakzsam: yeah
22:56 imirkin_: although the fact that blob doesn't expose it doesn't fill me with hope
22:56 hakzsam: hehe
22:58 hakzsam: piglit: error: env var PIGLIT_SOURCE_DIR is undefined
22:58 hakzsam: PIGLIT: {"result": "fail" }
22:58 hakzsam: weird
22:58 imirkin_: set PIGLIT_SORUCE_DIR
22:58 imirkin_: to the top of the piglit tree
22:59 imirkin_: (it needs it for the sample data)
22:59 hakzsam: oops http://hastebin.com/cuyidehopa.sm
22:59 imirkin_: cool beans.
22:59 imirkin_: GM20x doesn't have ASTC either
22:59 imirkin_: and by that logic i'm going to assume it doesn't have ETC2 either
23:00 imirkin_: thanks for confirming
23:00 airlied: seems that only mobile targetted devices are getting etc2
23:00 imirkin_: and astc
23:00 airlied: I do wonder what is causing the differentation
23:00 airlied:guesses some patent license
23:00 hakzsam: imirkin_, np
23:00 imirkin_:doesn't care to think about the reasons
23:01 imirkin_: i guess we'll have to implement some suitably horrid workaround when we want to expose GLES 3.2
23:01 imirkin_: (which wants GL_OES_copy_image which wants to work with the originally-uploaded data)
23:36 karolherbst: mupuf: I guess you aren't there anymore?
23:37 karolherbst: pmoreau: oh sorry, that I didn't saw your comment
23:40 karolherbst: imirkin: does anybody care about GLES 3.2 on the desktop in the next 1 or 2 years?
23:43 imirkin: me, because there are deqp tests
23:43 imirkin: :)
23:49 karolherbst: imirkin: I see :D
23:55 imirkin: meanwhile the khoronos cts tests are behind closed doors that i'm not willing to pay $15k to open
23:56 airlied: they also don't generally get close to deqp
23:59 karolherbst: imirkin: at least the vulkan ones are open :D
23:59 imirkin: airlied: but they exist for desktop GL