03:42 martestan: what's up trollducks and parrotapes?
03:45 martestan: Lyude: still paying taxes , we have some additional ones for you i.e for behaving like an ape thrashing scientist reputation, you gonna be taxed more until you understand that apes do not pay taxes and will be booted off from trolling on those channels
03:45 martestan: ?
03:45 Lyude: this is the third time
03:45 Lyude: chill
03:46 Lyude: mupuf, karolherbst:
03:46 Lyude: it's that dude again
03:47 martestan: i could be billionaire if all the trolls who violated payd their caused ....
03:47 Lyude: imirkin??
03:49 martestan: local apes can not be sanctioned my taxes also for screwing my knee and hand up intentionally, guess what apes do not have any money to tax from!
03:56 martestan: it is as simple as my knee and hand cost more then those "rich" men have assets or money in their wallets
03:57 martestan: yet theyd have to be made to pay for this, so what are the options?
03:57 martestan: it will be goodbye to them, justifyngly
04:00 martestan: right after they had screwd my leg and with 10year another hard work to kill me with no success following the last ten, one doctor managed to defend itself saying
04:01 martestan: sportsmen were on practice when good give brains to humans, bragging how they screwd up intentionally, well guess what , thinking is the area where it is even tougher to compete with me than in sports
04:02 martestan: no matter what will be you approval on this internal affair here, debts have to be paid, and terror to terror exchange will be actual
09:00 pmoreau: karolherbst: So, I gave your patches a try (along with Lyude’s ones), and it no longer hangs when I reclock while the GPU is suspended (I need to check that it really was suspended).
09:02 pmoreau: However, when I reclocked to 0f (GPU was off), it seems like reclocking woke the GPU up and kind of left it up: power consumption jumped from ~24W to ~38W after reclocking, and it stayed that way, but when cat’ing the pstate file, it was returning zeroes for the current clocks, as if the GPU was off.
09:03 pmoreau: And it stayed for several minutes at 38W, until I reclocked it to 07 which made it drop back to 24W.
09:04 pmoreau: I’ll try to test it again without Lyude’s patches, and check that the GPU really goes to sleep when I think it should.
09:40 karolherbst: pmoreau: yeah, waking up is the new thing, because detecting the correct runpm status isn't really a 100% safe game
09:40 karolherbst: pmoreau: but it might be, that the kernel isn't able to put your GPU to sleep
09:40 karolherbst: 24W is quite a lot if you think about it
09:40 pmoreau: It is!
09:41 karolherbst: yeah, I think your GPU doesn't go to sleep
09:42 pmoreau: I was a bit surprised to see the card wake up when I reclocked, but on the other hand, that is the behaviour I would have desired. ;-)
09:44 karolherbst: well
09:44 karolherbst: manual reclock is a hack anyway
09:44 karolherbst: but I doubt we will ever get rid of it
09:44 pmoreau: I’ll do some more testing with debugging info on, cause I think Ben moved all the suspend/resume messages to debug (which makes sense as it was quite spammy otherwise, and you did not care about it if it was working); I don’t think that he removed them completely.
10:04 karolherbst: pmoreau: by the way, I need to deal with local memory already :/
10:05 karolherbst: or maybe I skip fixing those until the end...
11:30 pmoreau: karolherbst: local memory, i.e. shared memory in CUDA terminology (on-chip memory), or that part of global memory where you spill to (local memory in OpenCL terminology)?
11:31 karolherbst: that part used for spilling
11:31 pmoreau: s/local memory in OpenCL/private memory in OpenCL
11:31 karolherbst: well, the "l[]" space
11:32 pmoreau: Yup
11:32 karolherbst: maybe it could be moved somewhere else, but this is about arrays
11:32 karolherbst: and index based on uniform value
13:57 zukunf: hei
13:57 zukunf: is it possible to reset nouveau state?
13:58 zukunf: I noticed after playing some games and running some other apps that use the card that it became slow and started to appear boxed glitches on the monitor.
13:58 zukunf: like blotches
13:59 zukunf: shutting down X and restarting make the game go smoothly again.
13:59 imirkin: sounds like a leak somewhere
13:59 zukunf: but I am not sure if that's a hard reset
14:00 zukunf: normally PPSSPP ui is smooth as no game is loaded. I noticed the symptom becasue ppsspp UI was slow as hell which immediaetly rang alarm bells.
14:01 zukunf: imirkin: how to track that down? I also notice some noticeable difference between qemu's virgl under radeon and novuau.
14:01 zukunf: I wish I knew how to track these sorta things
14:02 imirkin: well, there are a few things to note
14:02 imirkin: one is that radeon is developed by full-time (and highly competent) engineers with access to documentation and hardware. nouveau is not.
14:02 imirkin: another is that virgl will expose a lower GL feature level than you'll get on direct hardware (maybe)
14:05 imirkin: none of this explains why restarting the application wouldn't clear out some bit of "i'm going slow now" state
14:06 imirkin: perhaps mention which hw this is?
14:13 zukunf: gk104 or gk103
14:14 imirkin: no such thing as gk103, so GK104 by process of elimination :)
14:14 zukunf: well, too scared that complete freeze was comming I didn't even try a game, I killed and X and re-started in the hopes that this way would things would get fixed.
14:15 imirkin: anything fun in dmesg?
14:15 zukunf: yeah, I don't have it at hand.
14:15 imirkin: could indicate what went wrong
14:15 zukunf: already checked both, dmesg and Xorg.0.log.
14:17 zukunf: virgl works alright double checked on the vm and says gl acceleration on. qemu reports 'gl_version 43 - core profile enabled'
14:18 imirkin: looks like ppsspp doesn't use anything above GL 3.3 anyways (from a very quick glance)
14:18 imirkin: wow really? i didn't know that compute was piped through. surprising.
14:20 karolherbst: imirkin: yeah, I was aware that I need to use local memory for that array thing
14:21 karolherbst: this might be a painful part though and I skip it for now... well, dynamic array access I mean. the static stuff based on constants is fine, but if it is based on uniforms, then it might get complicated
14:22 imirkin: the constant stuff should be figured-out by MemoryOpt anyways
14:22 karolherbst: well
14:22 imirkin: although i got some improvement from cleaning it up up-front in from_tgsi
14:22 karolherbst: there are some things codegen could optimise here
14:22 imirkin: since memoryopt runs so late
14:22 karolherbst: like l[0x0 + $r4]
14:22 imirkin: well, nothing you can do there
14:22 karolherbst: I can
14:22 karolherbst: if $r4 is an immediate
14:23 imirkin: oh. yeah.
14:23 imirkin: i thought i made that opt
14:23 imirkin: something must be weird.
14:23 karolherbst: yeah
14:23 karolherbst: might be
14:23 imirkin: you could be doing something illegal
14:23 karolherbst: I ended up with l[$r255 + 0x4] things
14:23 imirkin: like using l[] outside of an OP_LOAD
14:23 imirkin: (or OP_STORE)
14:23 karolherbst: yeah
14:24 imirkin: in which case the optimizer won't look for it.
14:24 karolherbst: I might use them with MOVs... not 100% sure I got that part correct
14:24 karolherbst: I know I saw those with loads
14:24 karolherbst: but I can't say if they never happen with mov
14:25 karolherbst: but my first goal is to get piglit tests passing, then to clean up those ugly bits
14:25 imirkin: if it's not a register, always use mov
14:25 imirkin: gr
14:25 imirkin: if it's not a register, always use load
14:25 karolherbst: ;)
14:25 karolherbst: yeah
14:25 karolherbst: anyway. Nir is a bit annoying regarding constant values
14:25 karolherbst: puts them at the top of the function
14:26 imirkin: ah yeah, that'll destroy our RA :)
14:26 karolherbst: :)
14:26 karolherbst: thinking about to let nir fold them in and unfold it inside the converter
14:26 karolherbst: should make RA more happy
14:27 karolherbst: well
14:27 karolherbst: if I see immediates, I need to use load anyway
14:27 imirkin: or move immediates closer to use.
14:27 imirkin: or stop worrying about this shit which is unrelated to what you're doing and focus on the task at hand.
14:27 karolherbst: right, but that is an op which might not be always enabled
14:27 karolherbst: yeah
14:28 karolherbst: I usually only care about this when I have a piglit test failing because of such issues
14:28 imirkin: this should have taken ... an afternoon :p
14:28 karolherbst: ;)
14:28 imirkin: anyways, gtg. good luck.
14:28 karolherbst: well
14:28 karolherbst: 700 tests passing from the 1.10 execution ones
14:28 imirkin: almost done.
14:28 karolherbst: out of 1600
14:28 karolherbst: but yeah
14:29 karolherbst: getting those tiny bits right is annoying, like interpolation and so on
14:35 karolherbst: okay, I have to correct myself: 1300 passing now :)
16:50 Lyude: pmoreau: my clockgating patches helped with your reclocking? o-o
16:50 karolherbst: Lyude: my patches did
16:50 Lyude: Ah, OK
16:50 Lyude: that makes more sense :P
16:51 pmoreau: Yeaj, sorry Lyude :-(
16:51 Lyude: hehe, np
16:52 pmoreau: I’ll need to recompile a kernel without your patches to measure the difference in term of power consumption from your patches.
16:52 karolherbst: pmoreau: you don't
16:52 karolherbst: there are module options for that
16:52 karolherbst: ohh wait
16:52 karolherbst: I think there was a bug with those...
16:52 karolherbst: Lyude: did I tell you about it?
16:53 Lyude: karolherbst: hm?
16:53 pmoreau: Are there module options for enabling/disabling power/clock gating?
16:53 Lyude: yes
16:53 pmoreau: Oh!
16:53 karolherbst: Lyude: there was something wrong with those options
16:53 Lyude: config=NvPmEnableGating=0-3
16:53 Lyude: oh?
16:54 karolherbst: Lyude: would need to check my other laptop, but I think there was a bug to detect 0 or something
16:54 pmoreau: It seemed to me that ~24W was the usual power consumption on that laptop, but since I was seeing the same with your patches, I thought I was misremembering. :-)
16:54 karolherbst: naybe you reworked it already and you fixed it
16:54 pmoreau: Now, if it isn’t enabled by default, that would make sense :-)
16:54 Lyude: I may have, I know for a while I accidentally had it set so that clockgating was getting enabled on every single chipset past fermi
16:55 Lyude: pmoreau: yeah, it will say in dmesg when it's getting enabled!
16:56 pmoreau: I guess 0 is off, but what is the difference between 1,2 and 3. Different “levels”?
16:57 Lyude: Yeah. 1 is CG, 2 is BLCG, 3 is SLCG (SLCG is only a thing >= kepler2)
16:57 karolherbst: Lyude: how much of a difference does SLCG make?
16:57 Lyude: karolherbst: i'm honestly not entirely sure, I need to do more closer measurements
16:57 pmoreau: OK, I need to reboot to try those out! ;-)
16:59 Lyude: let me know if anything breaks!
16:59 Lyude: you might get one untraced mmio write btw, I think I have a bogus slcg register there somewhere
16:59 Lyude: (it's weird though, only happens the first time you bring the card up...)
17:23 pmoreau: Lyude: So, overall going from 0 -> 1, and 1 -> 2, each step saves about 1W, when the laptop is idling (and when running glxspheres; unigine was being annoying)
17:24 pmoreau: When idling it’s a bit more than 1W, since it’s almost a 3W difference between 0 and 2.
17:24 pmoreau: And yeah, I’m quite sure that GPU isn’t fully going to sleep as I told it to. :-/
17:43 Lyude: pmoreau: what gpu is this btw?
17:43 pmoreau: GK107
17:43 Lyude: ah, cool
17:43 pmoreau: A 750m
17:43 Lyude: 3W is a lot just for idle dang
17:44 pmoreau: Yes, but I won’t complain about that :-D
17:44 Lyude: no I meant that's a good thing
19:59 AndrewR: so ... there was new pcem (v13), I installed it under wine, set up voodoo2 emulation, loaded my 2.4 based livecd, compiled mesa (6.2.1) + glide3, and got this: https://ibin.co/3kZOz577UHWK.png (glblur screensaver). kinda ..inverted! But surprizingly mplayer -vo gl2 show normal picture, and same for few glide2 tests I tried. So, if anyone likes to try voodoo1/2 under linux - today s/he can, in emulation :}
21:12 Walther: Hello folks! Getting a black screen with gtx970 4gb edition with Nouveau installed. Specifying nomodeset lets me into a tty so I can debug. Running kernel 4.14, and according to this thread it should've already been fixed by 4.12 https://bugs.freedesktop.org/show_bug.cgi?id=94990
21:14 karolherbst: Walther: maybe it broke again, did it work with 4.13?
21:14 karolherbst: skeggsb: ^^
21:16 Walther: karolherbst: good question. I upgraded straight from like 4.8 or something, haven't touched this setup since the 970 hiccups began
21:16 Walther: let's try installing a 4.12 or 4.13...
21:17 Walther: (well, easier said than done, though)
21:21 Walther: but yeah, i don't think i've had a working setup since 4.6 or somewhere when that issue began
21:25 Walther: (oh wow, it's been almost two years of no desktop linux then.. just VMs on my laptop)
21:33 Walther: looking at journalctl -b -1, i can see "DRM: DDC responded, but no EDID for DVI-I-1"
21:34 Walther: existing bug report seems to be here https://bugs.freedesktop.org/show_bug.cgi?id=102913
21:37 Walther: i'm running 4.14.5-1 on arch, and xf86-video-nouveau 1.0.15-2
21:43 Walther: is there anything else I could do to help you help me help us all? :)
21:53 Walther: right, there's also a "bus: MMIO write of 80000140 FAULT at 10eb14 [ IBUS ]"
21:55 karolherbst: Walther: well, trying out 4.13 would help
21:55 karolherbst: ohhh wait, let me check something
21:55 karolherbst: Walther: do you have linux-firmware installed?
21:56 karolherbst: but that shouldn't cause a black screen if missing
21:56 karolherbst: weird
21:59 Walther: https://walther.guru/temp/kernel-log-2017-12-13.txt
21:59 Walther: karolherbst: linux-firmware is installed and up to date
22:02 karolherbst: mhh "DVI-I-1: EDID is invalid:"
22:02 karolherbst: that might explain it
22:02 karolherbst: Walther: do you have a different cable you can plug your display?
22:02 Walther: the display works perfectly on my windows install though and the same display and same cable have worked in the past
22:02 karolherbst: sometimes there are displays with broken EDIDs
22:02 karolherbst: and driver whitelist them
22:03 karolherbst: I know where some displays reuse the same for all connecter types
22:03 karolherbst: but change some bits without updating the checksum
22:03 karolherbst: and then the edid is broken
22:03 karolherbst: and if it works with VGA or HDMI or whatever, then you could create a buf report and I think this could be added to some whitelist
22:05 Walther: hah, that sounds "lovely". trying with hdmi now
22:08 Walther: excellent, i do get to X with the HDMI, 4.14 kernel and nouveau 1.0.15-2
22:10 karolherbst: ...
22:10 karolherbst: as I said ;)
22:10 karolherbst: well, please open a bug regarding this
22:10 karolherbst: I am sure the other drivers might have the same issue?
22:10 karolherbst: or other users, don't know
22:10 karolherbst: somebody will know what to do with it
22:14 Walther: this seems like a relevant, existing bug report on that https://bugs.freedesktop.org/show_bug.cgi?id=31943
22:15 Walther: whoops, probably not
23:03 karolherbst: imirkin: I don't quite get how loops are handled. Are prebreak and precont used to setup "jump" positions when break/cont are invoked? Does it mean that at the end of the loop there has to be a break/cont/ret or do we have to insert it there if there is non given by the IR?
23:05 karolherbst: I mean, there is still the nir_loop_terminator thing in nir I could use for all kind of things, just wondering how it has to look like for nvir
23:41 karolherbst: imirkin: mhh, we could clean up all prebreaks/preconts if no conts/breaks are called against those BBs, right?
23:42 karolherbst: post RA I mean
23:42 karolherbst: like here: https://gist.githubusercontent.com/karolherbst/addca37ea760333779775d8b00f593fa/raw/695612d603d036c3dbc6bf0c5e6ea3f310aca8d3/gistfile1.txt