00:03 karolherbst: imirkin: where are the GL_ARB_buffer_storage implemented in nouveau?
00:03 imirkin: look for PERSISTENT and COHERENT
00:03 karolherbst: k
00:04 imirkin: those all get allocated in gart
00:04 imirkin: and then when someone does a glMemoryBarrier(), persistent buffers should get flushed
00:05 imirkin: and at draw time, we look at coherent buffers that are bound, and if there are any, flush some caches
00:06 karolherbst: mhhh
00:06 karolherbst: it might make sense to test it on tesla
00:07 imirkin: test what?
00:08 karolherbst: if the issues is also there
00:15 imirkin: go for it
00:24 Celti: karolherbst: Interesting. Absolutely no errors with pstate 0 and boost 2 at +150mV — but the reported frequency doesn't go above 940MHz
00:25 karolherbst: Celti: right
00:25 karolherbst: this is stupid. I think we miss something on nve7
00:25 karolherbst: which only is important on nve7
00:35 Celti: Well
00:35 Celti: Troubleshooting this has been fun
00:36 Celti: fun enough that it's kept me awake to the thirty-hour mark, so I'm going to go crash
00:36 imirkin: along with your gpu :)
00:37 Celti: Indeed!
00:44 karolherbst: :D
00:53 karolherbst: imirkin: any ideas regarding this issue? Currently I am rather in the "I am lost" state here. I think the broken use case is where the client is updating anything in the coherent buffer, but it isn't flushed on the nouveau side
00:54 imirkin: what buffer is coherent? index? vbo? texture?
00:54 imirkin: something even more creative i'm not thinking of?
00:56 karolherbst: well I would say textures, at least the stuff which is messed up in my screenshots
00:57 imirkin: dunno... those textures look fine
00:57 imirkin: just in the wrong place :)
00:57 karolherbst: well
00:57 karolherbst: maybe something was written into the buffer
00:57 karolherbst: used
00:57 imirkin: so anyways, long story short, you haven't even tried to debug it
00:57 karolherbst: something new was written
00:57 karolherbst: and used elsewhere
00:58 karolherbst: no, I am lost as I said :D
00:58 karolherbst: thing is
00:58 imirkin: if you had, you'd know what was bound at the time, and which thing was coherent
00:58 karolherbst: apitrace won't help
00:58 imirkin: yeah, that's a huge bitch
01:07 Riastradh: [ 406.386] (EE) NOUVEAU(0): [COPY] failed to allocate class.
01:08 Riastradh: Likely to indicate a real problem on an NV84 device?
01:08 imirkin: nope, just an error that's no longer printed with the latest code
01:08 imirkin: copy engine only became a thing on GT215
01:08 Riastradh: Heh, OK, thanks, that'll save me some time!
01:09 imirkin: if you grab xf86-video-nouveau 1.0.12 that should be gone
01:09 Riastradh: Great, OK.
01:09 imirkin: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=02c1aee91ae22b58e777716ffd38397f9df0a087
01:09 imirkin: but it's perfectly harmless
01:10 imirkin: you're trying to get it going on netbsd right?
01:13 karolherbst: imirkin: is there some code related to buffer_storage inside libdrm_nouveau ?
01:14 imirkin: no
01:14 imirkin: my guess is we're not flushing enough
01:15 imirkin: just throw some unconditional flushes of stuff in the nvc0_draw_vbo()
01:15 imirkin: if that's not enough, throw in a SERIALIZE
01:15 imirkin: if that's not enough, then ... cry loudly.
01:15 imirkin: that should destroy perf, but will hopefully identify what's missing
01:16 Riastradh: imirkin: That's correct. Just fixed a long-standing mistake on my part that had broken nouveau for <NVC4 or so on 64-bit systems.
01:17 imirkin: doh!
01:17 karolherbst: imirkin: so just nvc0->dirty_3d |= some_flag;
01:17 Riastradh: https://mail-index.netbsd.org/source-changes/2016/04/12/msg074022.html
01:17 karolherbst: and fine the flag which changes something
01:17 karolherbst: right?
01:17 imirkin: karolherbst: no screw that, just emit the methods
01:17 karolherbst: ahh
01:17 karolherbst: I see
01:18 imirkin: karolherbst: you're not making something that's pushable, you're shotgun debugging
01:18 imirkin: fire until something works
01:18 imirkin: ;)
01:18 karolherbst: right
01:18 karolherbst: I think I got it now
01:18 imirkin: Riastradh: ouch =/
01:18 karolherbst: like "if (nvc0->cb_dirty) {" -> if (true)
01:19 imirkin: karolherbst: sure, start with that
01:19 imirkin: karolherbst: but... it's probably a vertex or index buffer that's being used here
01:19 karolherbst: right
01:20 imirkin: so make sure we do that array flush thing
01:20 karolherbst: if (something) continue; away with that ! :D
01:20 karolherbst: nvc0_draw_arrays?
01:21 imirkin: the function that calls that... nvc0_draw_vbo i think
01:21 karolherbst: ahh
01:21 karolherbst: no
01:21 imirkin: that has the VERTEX_ARRAY_FLUSH
01:21 karolherbst: IMMED_NVC0(push, NVC0_3D(VERTEX_ARRAY_FLUSH), 0);
01:21 imirkin: or... something
01:21 imirkin: yes
01:21 karolherbst: crash... :/ meh :D
01:21 Riastradh: imirkin: Quick question about fifo channels: for nv<c0, are the fifo control registers always inside the BAR0 MMIO region mapped by the nouveau device subdev constructor?
01:21 imirkin: you might need to up the PUSH_SPACE's?
01:22 imirkin: Riastradh: i'm less knowledgeable about the kernel end of things. afaik yes though, PFIFO is always accessible via BAR0
01:22 karolherbst: the VERTEX_ARRAY_FLUSH didn't crash, it was something else
01:22 Riastradh: That is, does the ioremap for a fifo channel's control registers map a subregion of the region of the BAR0 MMIO registers that was ioremapped in the subdev constructor?
01:22 karolherbst: but it didn't help either
01:22 imirkin: Riastradh: the idea is that there's an IB ring
01:23 imirkin: Riastradh: point the code out?
01:24 Riastradh: imirkin: drivers/gpu/drm/nouveau/nvkm/engine/device/base.c, nvkm_devobj_ctor, second call to ioremap
01:25 imirkin: mmmmm.... nothing of that name in my kernel 4.5 tree
01:25 Riastradh: Hmm, fifo channel code changed a lot more, it looks like, but in drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c, I think _nvkm_fifo_channel_rd/wr32 are what correspond here.
01:25 Riastradh: Oh, I'm apparently looking at a 4.2 tree here.
01:25 Riastradh: Let me see what's in 4.5.
01:26 imirkin: ok, found it... hold on
01:26 imirkin: (git show v4.2:....)
01:26 imirkin: so... which ioremap line do you mean?
01:26 imirkin: map = ioremap(mmio_base, 0x102000);
01:26 Riastradh: Anyway, the reason I ask is that in NetBSD, if device registers are already mapped, you can't map them again -- it's a different operation to get at a subregion of an existing map.
01:26 imirkin: this one?
01:26 Riastradh: imirkin: No, second one.
01:26 Riastradh: That one's a temporary mapping.
01:27 Riastradh: Goes away when the function is done.
01:27 Riastradh: The second one maps the MMIO registers for the lifetime of the driver, pretty much.
01:27 imirkin: the first one is unmapped
01:27 imirkin: right
01:27 imirkin: so what's the issue again?
01:27 Riastradh: Do the fifo channel control registers always lie in that region, for nv<c0?
01:27 imirkin: that just maps BAR0 so that nvkm_rd32/wr32 can access it
01:28 imirkin: "fifo channel control registers"?
01:28 Riastradh: (For nv>=c0, the fifo channel control registers live in BAR 1, not BAR 0, so it's moot.)
01:28 imirkin: specifics please :)
01:28 Riastradh: Just a moment.
01:28 imirkin: oh i see.
01:28 imirkin: chan->user = ioremap(chan->addr, chan->size);
01:29 imirkin: this guy?
01:29 Riastradh: See what nvkm_fifo_channel_create_ sets chan->addr to, which is used (lazily in 4.2, but mapped eagerly in 3.15) by _nvkm_fifo_channel_rd/wr32.
01:29 Riastradh: Right.
01:29 imirkin: i see.
01:29 imirkin: now the question is wtf that is...
01:29 Riastradh: Is [chan->addr, chan->addr + chan->size) always a subregion of [mmio_base, mmio_base + mmio_size)?
01:29 Riastradh: (for nv<c0)
01:30 Riastradh: I hypothesize that it is, but I'd like to confirm that before I commit the assumption to NetBSD and break half of all the devices out there.
01:30 imirkin: yeah, looks like it should be inside of bar0
01:30 imirkin: but there's nothing requiring a single mapping
01:30 imirkin: so it's convenient
01:31 imirkin: i'm almost sure that it is.
01:31 imirkin: you can throw an assert type thing in just in case
01:31 Riastradh: Right... First I decided to try just mapping BAR 0 up to 0x800000 in engine/base.c, so that it excludes the fifo registers and allows those to be mapped separately.
01:31 imirkin: there's lots of weirdness, esp as you move to earlier devices
01:31 Riastradh: But it turns out that breaks nve4 for reasons I don't understand.
01:31 Riastradh: (https://gnats.netbsd.org/51065)
01:32 imirkin: does accel and mesa work fine on netbsd btw?
01:32 Riastradh: More or less. I haven't hammered on it. glxgears reports 1000 fps on my nv84 device.
01:33 imirkin: cool
01:33 Riastradh: On the other hand, it would be *nice* if the general BAR 0 mapping could be limited to 0x800000, because it eats KVA, which on 32-bit systems is scarce, and 0x800000 is already 2 MB of KVA.
01:33 imirkin: try something a little more ambitious perhaps :p
01:34 Riastradh: Yeah, I will once I sort out some other things. Just got at least nouveau to suspend/resume OK, now trying to fix the problem I caused on nve4.
01:35 Riastradh: Does anything else use mmio registers >=0x800000 on nve4?
01:35 imirkin: and as you're providing another set of eyes on the nouveau code, please don't hesitate to contribute fixes back to ben :)
01:36 Riastradh: I've been meaning to upstream some things, but most of the bugs have been my fault so far, and I'm slow enough that it's well past time for me to update from upstream now.
01:36 Riastradh: (Next update should be easier than the first now that I have a handle on things.)
01:37 imirkin: well, things have been rewritten yet-again in 4.3
01:37 imirkin: now with more type safety
01:37 imirkin: but don't worry, i'm sure yet another rewrite is coming soon!
01:37 Riastradh: Heh. Type safety is nice. I've spent far more time than I want to admit lost and staring at stacks of objects and classes.
01:41 Riastradh: https://envytools.readthedocs.org/en/latest/hw/mmio.html suggests that >=0x800000 is only fifo channels and vram, so I wouldn't expect anything to try using anything >=0x800000 as mmio registers.
01:43 karolherbst: imirkin: nothing seems to work :/ but I guess I also do something wrong
01:43 karolherbst: imirkin: this is what I messed around so far https://gist.github.com/karolherbst/724b72b3ca94e52b92face811e419674
01:44 imirkin: Riastradh: try to catch skeggsb_ when he's around, he'll know much much more - he's in australia, around during weekday daytime.
01:54 karolherbst: I give up for today. It doesn't matter how much I mess with that function, nothing changes somehow :/
02:01 Riastradh: imirkin: OK, thanks.
02:02 Riastradh: Looks like the fifo channel register mapping moved to fifo/chan.c.
02:34 Riastradh: imirkin: Did you mean to turn [COPY] into [COPY} in that commit?
02:35 imirkin: i think you have it backwards
02:35 imirkin: or we're thinking of different commits
02:35 Riastradh: ...heh, whoops, right.
02:36 imirkin: btw, if you want, we can put up a netbsd page over at nouveau.freedesktop.org, if you supply the content (or get your own wiki editing credentials)
02:37 imirkin: dunno if there are special steps
02:37 imirkin: or maybe just a "p.s. nouveau is a thing in netbsd version x"
02:37 Riastradh: Hmm. I'll think about that. Preparing to write a blog post to announce it a little more publicly once I fix <https://gnats.netbsd.org/51065>.
02:38 Riastradh: Shouldn't require any manual steps -- everything should jfw, although it is mildly annoying and sometimes error-prone that we have to wait for the file system to be available for firmware images before we can start the driver.
02:48 imirkin: you're keeping the fuc separate?
02:48 Riastradh: ?
02:49 imirkin: what firmware images?
02:49 Riastradh: I don't remember the details -- I didn't set it up for nouveau.
02:49 Riastradh: Maybe someone was confused.
02:49 Riastradh: (We certainly need that for radeon, though.)
02:49 imirkin: right
02:50 imirkin: for nouveau, assuming you're doing the same thing as on linux, all that stuff should be compiled into the driver
02:51 Riastradh: Said someone reported: drm kern error: nouveau E[ PGRAPH][nouveau0] failed to load fuc409c
02:52 Riastradh: Dunno what's up with that, will investigate after dinner.
02:53 imirkin: did they have NvGrUseFW=1 or whatever set?
03:08 Riastradh: Maybe the microcode image just didn't get included in the build, dunno.
03:08 Riastradh: I'm fuzzy on how nouveau ucode images work, obviously!
03:10 imirkin: for nvc0+, we have a preassembled fuc blob we use
03:10 imirkin: (with source, that we wrote, but we don't want to force people to have envyas to build the kernel)
03:11 imirkin: it comes in a few iterations, too
03:11 imirkin: on linux, those are built along with the module
03:11 imirkin: there's also an option to load them off the fs
03:15 Riastradh: How onerous is envyas? Simple self-contained C program? Python/C++ program that brings in boost and half the world and its dog?
03:16 imirkin: heh
03:16 imirkin: well it's part of envytools
03:16 Riastradh: envytools/easm?
03:17 imirkin: envytools/envydis
03:17 Riastradh: Quick glance suggests that should be pretty easy to adopt as a tool.
03:31 imirkin: Riastradh: or just import the .fuc.h files
03:31 Riastradh: We did, but they don't appear to be included for nvc0?
03:33 Riastradh: Linux master suggests for gf100 (`nvc0'?), the fecs_inst/fecs_data/gpccs_inst/gpccs_data ucode images are always loaded separately.
03:33 Riastradh: gf100_gr_new_
03:34 imirkin: not quite
03:34 imirkin: it's complicated :)
03:34 imirkin: there's an option to load them off the filesystem
03:34 Riastradh: How are they loaded if not from the file system?
03:34 imirkin: which is required for GK20A and GM20x
03:34 imirkin: which is what you're seeing... that request_firmware stuff
03:35 imirkin: give me a minute to locate some links...
03:36 imirkin: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/gr/gf100.c#L1919
03:36 imirkin: which comes from the .fuc.h files here: https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/nvkm/engine/gr/fuc
03:36 imirkin: note that this is the post-4.3 organization
03:36 imirkin: however pre-4.3 it also looked semi-similar
03:37 Riastradh: Ah, I see.
03:37 Riastradh: Hmm, no, I still don't quite see.
03:37 Riastradh: Oh, there it is --
03:37 Riastradh: use_ext_fw = nouveau_boolopt(device->cfgopt, "NvGrUseFW",
03:37 Riastradh: oclass->fecs.ucode == NULL);
03:38 Riastradh: oclass is statically initialized; oclass->fecs.ucode comes from the .h.
03:38 Riastradh: (old code -- 3.15)
03:38 imirkin: right
03:38 imirkin: except for newer chips
03:38 imirkin: i think in 3.15 "newer" may have meant GK110 and GK208? dunno
03:39 imirkin: it was a long time ago :)
03:39 Riastradh: So `newer chips' do require a separate ucode image? (Can that be backported easily?)
03:39 imirkin: yes and no
03:39 imirkin: the ucode can easily be ported
03:39 imirkin: just a sequence of bytes :)
03:39 imirkin: however the code to interact with the ucode has been improved too
03:39 Riastradh: Also, can the ucode image be loaded after boot, e.g. just before starting X or trying to use libdrm_nouveau?
03:40 imirkin: ucode is necessary to operate the gr unit
03:40 imirkin: at least the way nouveau uses it
03:40 imirkin: one could also operate it without ucode, but it's a bit of a hassle, and not supported by nouveau
03:40 Riastradh: OK.
03:40 imirkin: (and it's mega-slow)
03:41 imirkin: basically doing all the stuff the ucode would be doing from the cpu
03:41 Riastradh: Will pick this up later -- gotta run now. Thanks!
03:41 imirkin: k, see ya
06:54 un23: Hello
07:13 un23: Hello
07:14 un23: I have a GTX 750 NV117 (GM107) here and I am wondering how to get the Firmware.
07:15 un23: I googled around but didn'find anything useful
07:16 un23: The Firmware supported by extract_Firmware.py seems to be too old, that Version des not support the GTX 750
10:46 mupuf: public announcement: Reator is down while I am making experiments on how to solve the frame drops
10:48 hakzsam: :)
10:49 mupuf: so far, no packet loss in bridge mode, which means I would need to buy a new router
10:50 mupuf: yep, 0 packet loss so far from mupuf.org to my house
10:51 mupuf: as opposed to 1-4% packet loss in my local network
10:51 mupuf: yes, I said local
11:12 mupuf: ok, 20 minutes, 0 packet loss
11:13 mupuf: well, time to go get a new router then
12:06 karolherbst: mupuf: ... those routers :D
12:22 un23: Hello, has anyone an idea where to get the firmware file for a GTX 750 (NV117)?
12:22 Misanthropos: karolherbst, is there a way to enable dynamical pstate setting?
12:23 un23: The python script I found seems to support only older drivers that do not support it
12:32 karolherbst: Misanthropos: like that you don't ahve to reclock yourself?
12:32 karolherbst: un23: that's for VP6 right?
12:33 karolherbst: un23: well VP6 and VP7 aren't supported anyway, so by just having the firmware files you get nothing
12:33 karolherbst: un23: you can help to RE it though
12:34 un23: Hmm, I thought the nv117 was on the nouveau website as supported.
12:35 karolherbst: ohh
12:35 karolherbst: the firmware is only needed for video decoding
12:35 karolherbst: you don't need to for OpenGL or anything else
12:36 un23: Ok, then maybe I have a different problem altogether.
12:36 un23: The X server does not use the nouveau driver and currently runs on vesa :-(
12:37 karolherbst: un23: you need modesetting on maxwell
12:37 karolherbst: un23: please paste the X log somewhere
12:38 un23: I think the critical parts are
12:38 un23: [ 14.596] (EE) open /dev/dri/card0: No such file or directory
12:38 un23: [ 14.682] (EE) open /dev/fb0: No such file or directory
12:38 karolherbst: the full X log please
12:40 karolherbst: mupuf: anything you want for hwmon besides what we have now?
12:40 un23: A moment please
12:40 karolherbst: mupuf: I could add fancy stuff like in0_min and so on :D
12:41 karolherbst: mhh yeah, why not
12:44 un23: http://www.shark-linux.de/Xorg.0.log
12:45 un23: The open errors lead me to thinking the kernel had a problem
12:47 karolherbst: "KMS not enabled"
12:47 karolherbst: this is the error
12:49 un23: Sorry ...
12:51 un23: Speeking of kernel: I currently do not see any hint that nouveau is in the kernel at all.
12:51 un23: It was there in 3.16, now I have 4.4
12:52 karolherbst: then please provide your full dmesg
12:58 un23: http://www.shark-linux.de/dmesg
13:00 un23: I will try to get the module into the kernel and come back here when I know some more, ok?
13:00 karolherbst: yeah, seems like there is no nouveau
13:00 karolherbst: yep
13:00 un23: Thanks
13:00 karolherbst: un23: ohh
13:00 karolherbst: un23: maybe it is something else
13:00 karolherbst: ....
13:16 un23: Hello again. Kernel module loaded, logfiles updated.
13:16 un23: Now the nouveau driver is used.
13:16 karolherbst: un23: please update your nouveau ddx or remove it :)
13:17 karolherbst: the modesetting DDX will give you a much more stable experience than the nouveau one
13:17 karolherbst: both are using glamor anyway on maxwell
13:17 karolherbst: and the glamor integration is better on the mdoesetting one
13:17 karolherbst: the kernel module still stays nouveau
13:18 un23: Ah, ok.
13:18 un23: Not quite sure how to do that?
13:19 karolherbst: there should be a package called xorg-driver-nouveau or
13:19 karolherbst: something like that
13:19 un23: xserver-xorg-video-nouveau
13:19 karolherbst: yeah
13:19 karolherbst: that's the one
13:19 un23: Ok, I will try.
13:19 karolherbst: ohh wait
13:19 karolherbst: X is just 1.16.4
13:19 karolherbst: mhhh
13:20 karolherbst: maybe then it doesn't matter anyway
13:20 un23: Debian jessie ;-)
13:20 karolherbst: yeah, old stuff ...
13:20 karolherbst: you may encounter graphical issue or poor 2D performance
13:20 karolherbst: so in this case I wouldn't bother too much about removing the nouveau ddx
13:20 un23: Currently I see a server crash as soon as I start the web browser
13:20 karolherbst: I think with X 1.17 the glamor stuff is usable enough
13:20 karolherbst: mhhh
13:21 un23: or exit the glxgears..
13:21 karolherbst: un23: well then try to remove xserver-xorg-video-nouveau
13:21 karolherbst: you have the modesetting ddx installed
13:21 karolherbst: so it may be fine
13:21 un23: Ok, just a second
13:26 karolherbst: un23: did anything change?
13:27 un23: package reamoved, now modsetting is grabbing the card
13:27 un23: The crashes are gone
13:27 karolherbst: awesome
13:27 vita_cell: karolherbst
13:27 vita_cell: hi
13:28 un23: I still have the impression that the graphics where much better with the propriatary drivers. Especially the fonts look ugly
13:29 karolherbst: un23: that might be just because glamor is really old
13:29 karolherbst: un23: but it could be also that just fontconfig is misconfigured
13:29 karolherbst: vita_cell: hi
13:30 vita_cell: hi
13:30 karolherbst: un23: but in which way are the fonts ugly?
13:30 vita_cell: here is still some performace issues when playing games
13:30 vita_cell: on 4.4 gtx770
13:33 un23: Like antialiasing is not working
13:33 vita_cell: when I play Counter-Strike:GO, or Left4Dead, games runs very very flawless, much fps, I play with 144hz monitor, but when I shoot much bullets or see some enemies shooting, game's fps drops too much, the game stutters, but only with that intense moments,
13:33 karolherbst: Tom^ has the same issue
13:33 un23: Hard corners, irregular thickness of the lines
13:33 vita_cell: including when I lowest settings, "LOWEST"
13:33 karolherbst: un23: k, which desktop are you running?
13:34 un23: xfce
13:34 karolherbst: vita_cell: yeah well, it is a known issue somewhat, but currently we are not really focusing on performance, because there are more important things to do :/
13:35 vita_cell: i7-2600 (non K) gtx770 4gb, 144hz monitor on DVI dual, ddr3 4gbx2 dual channel, Mint 17.3 xfce4 + compton, linux 4.4 gneric
13:35 karolherbst: un23: mhh, maybe there is a settings for the window manager to anti alias fonts or somewhere else
13:36 vita_cell: lowering the resolution, for example, I tested with CRT monitor (cuz crts monitors have not native resolution), at 1024x768, and game almost doesn't stutter
13:36 vita_cell: so, lowering the resolution hepls, but the problemis, that if I lower the resolution, everything look like crap, because LCD monitor
13:38 vita_cell: games at lowest resolutions, including something like 800x600, run very very well, no stutter
13:40 un23: It has. Actually disabling antialiasing makes it a bit better. !? I will experiment some..
13:40 vita_cell: thanks karolherbst, I will try, at the moment, only lowering the resolution /antialising/SSAA, helps, (not lowering other settings)
13:40 karolherbst: un23: I am sure some kind of config is just borked
13:41 un23: Probably.
13:41 vita_cell: lowering resolution, helps
13:41 un23: I have set "Hinting" to "slight" and it looks a lot better. Whatever that means..
13:42 vita_cell: I using compton in GNU+Linux, with xfce, compton has not any antialising setting,
13:48 kugel: karolherbst: hi
13:50 kugel: I tried your dynamic_reclocking branch. changing pstate didn't work
14:01 karolherbst: kugel: yeah, there is something broken currently
14:01 karolherbst: I will work on that after I finished all the other reclocking stuff first
14:04 Misanthropos: karolherbst, exactly... like a dynamic pstate?
14:05 karolherbst: Misanthropos: yeah, I was working on it a bit, but nothing production ready yet
14:05 karolherbst: it's on the list though
14:12 karolherbst: vita_cell: is it possible to script stuff in csgo and start the script from start?
14:12 karolherbst: vita_cell: like a script which spawns 20 bots which will fire non stop at each other for some seconds?
14:22 vita_cell: I do not know how to do that
14:23 karolherbst: me neither
14:23 vita_cell: but you can start the game with aparameters
15:38 martm: hello guys , i wast visit my friend during the weekend, but got back prettu quick
15:38 martm: *pretty
15:39 martm: than i was betting on solving the multithreading issue, and like two days was reading the reports
15:39 martm: there were too many ways too
15:39 martm: but later i filtered stuff, wether the need is solving in code or assembly
15:40 martm: MFCI, does make the memory accesses all atomic though still
15:43 martm: if you know about kernel land, then there are kinda three issues in higher language levels
15:44 martm: its all memory accesses in assembly level, but..it's structs , pointers and global variables in c
15:44 martm: rather static variables too though
15:48 SaveTheRobots: karolherbst: which is the best branch of your repo to use for kepler atm ?
15:49 karolherbst: SaveTheRobots: depends, but usually my stable_reclocking_kepler_v2
15:52 SaveTheRobots: ah, i read the phoronix article where michael used a completely different one, so i thought i'd check :)
15:52 SaveTheRobots: thanks
15:56 karolherbst: SaveTheRobots: it is a kernel tree
16:01 SaveTheRobots: ahh ok
16:01 karolherbst: and outdated :D
16:02 SaveTheRobots: i presume stable_reclocking_kepler_v2 will work against 4.5.1 ?
16:02 karolherbst: mupuf_: was it the nve7 you didn't have or a different one?
16:02 karolherbst: SaveTheRobots: yeah
16:02 SaveTheRobots: cool
16:07 karolherbst: mupuf_: ohh it was the nve4 one
16:07 karolherbst: ...
16:07 karolherbst: Celti: did you ever used bumblebee on your machine?
16:29 SaveTheRobots: karolherbst: nouveau/drm/nouveau/include/nvif/os.h:34:28: fatal error: soc/tegra/fuse.h: No such file or directory .. any ideas?
16:29 karolherbst: SaveTheRobots: famouns ARCH issue
16:29 karolherbst: *famous
16:29 karolherbst: remove that include
16:29 kugel: karolherbst: you asked me to do something on the binary driver with envytools. I have a bit of time now
16:30 karolherbst: arch doesn't install all linux header files
16:30 SaveTheRobots: karolherbst: aaah, thanks
16:31 karolherbst: kugel: depends. If you don't have any issues with my current branch, then I am fine I think
16:31 kugel: karolherbst: can't go to higher pstate, that's an issue
16:31 karolherbst: kugel: with my current branch?
16:32 kugel: your dynamic_reclocking branch. should I use another one?
16:32 Yoshimo: karolherbst: you said that my x log and dmesg look good, how do you explain this error? https://imgur.com/nTZQP5n
16:32 karolherbst: kugel: when you want to reclock yourself, stable_reclocking_kepler_v2
16:32 karolherbst: get me those information :D
16:33 kugel: oh does dynamic_reclocking enable automatic pstate switching, somehow?
16:33 karolherbst: kugel: yeah, and currently it is a bit broken
16:33 karolherbst: Yoshimo: well did you try with a new user?
16:33 kugel: i see, so it's excepted that echo 0f > .../pstate has no effect?
16:33 karolherbst: kugel: kind of yeah
16:34 Yoshimo: i did and my new "graphicbug" user didn't get any further
16:34 karolherbst: Yoshimo: then start X session, not plasma
16:34 karolherbst: Yoshimo: and just execute glxinfo
16:34 kugel: alright. trying stable_reclocking_kepler_v2 now
16:34 karolherbst: or start X as root from a tty
16:35 kugel: if you ask for issues, there's still the issue that I need the hacky patch to ramp the voltage or the highest pstate would freeze
16:36 karolherbst: you shouldn't need it with the branch anymore
16:36 kugel: okay. so I'll try stable_reclocking_kepler_v2 without that patch
16:37 karolherbst: right
16:38 kugel: i also still have the issue with blinking cursor in dota2 when I enable prime with "xrandr --setprovideroutputsource Intel nouveau", not sure if that's kepler or even nouveau specific
16:39 karolherbst: no idea
16:39 karolherbst: I never had such issues
16:39 karolherbst: maybe it is dri2 related
16:40 kugel: karolherbst: my dmesg is full of [ 2882.422608] nouveau 0000:04:00.0: clk: error setting cstate 160: -22
16:40 kugel: [ 2883.422815] nouveau 0000:04:00.0: clk: failed to set cstate 160
16:40 karolherbst: uhhh
16:40 karolherbst: I thought I fixed that already
16:41 karolherbst: it isn't that critical though
16:41 karolherbst: let me check
16:41 kugel: still on the dynamic_reclocking branch, i just saw this prior to rebooting
16:41 kugel: I'll reboot now
16:42 karolherbst: ahh okay
16:49 kugel: karolherbst: no such problem on stable_reclocking_kepler_v2. and 0f pstate seems to works fine without the voltage patch
16:50 karolherbst: kugel: good
16:50 karolherbst: kugel: the error setting cstate error was just a mistake on my side and comes from the therm daemon
16:50 karolherbst: kugel: I can show you something, then you see what I mean
16:50 karolherbst: orr maybe nt
16:50 karolherbst: mhh
16:50 karolherbst: well you only have three cstates
16:51 karolherbst: but a temperature adjustment, nice
16:51 karolherbst: kugel: do you have sensors?
16:52 kugel: yea
16:52 karolherbst: allthough doesn't matter that much. Nouveau just changes the voltage/clocks depending on the temperature
16:52 karolherbst: more the voltage
16:52 karolherbst: but due to the changed voltage, a reclock could happen
16:52 karolherbst: but not on your gpu
16:53 karolherbst: kugel: while the gpu is on, you could do this: nvaforcetemp 1; sleep 1.2; sensors; nvaforcetemp 95; sleep 1.2; sensors; nvaforcetemp 0
16:53 karolherbst: and the voltage should be a bit different
16:54 kugel: what do you mean with "while the gpu is on"?
16:54 karolherbst: ohh
16:54 karolherbst: kugel: I thought you hade two gpus
16:54 kugel: i do
16:54 karolherbst: ahh but nvidia is main?
16:54 karolherbst: right
16:55 kugel: yea, i'm the guy with the awkward external gpu setup :p
16:55 karolherbst: and you want to plug a monitor on your board and offload it or something like that
16:55 karolherbst: right
16:55 karolherbst: yeah, well then you can just execute it
16:57 kugel: is nvaforcetemp in envytools?
17:00 Yoshimo: karolherbst: root has the same issue starting x
17:00 karolherbst: Yoshimo: meh :/
17:00 kugel: karolherbst: yea, voltage changed. from 1.09V, then 1.10V, then 1.06V. now it's back to 1.09V
17:00 karolherbst: Yoshimo: but can you just start X without anything except maybe twm/xterm?
17:01 karolherbst: kugel: good :)
17:01 Yoshimo: i had a bash on top of the basic graphic ui via startx bash but glxinfo returned nothing there
17:01 Yoshimo: fbconfig missing or so
17:02 karolherbst: mhh
17:02 karolherbst: Yoshimo: then your last X log please
17:02 karolherbst: there should be something wrong
17:03 karolherbst: or maybe it is just failing to load the right libraries or something stupid as this
17:04 kugel: karolherbst: I think I'd like to try your boost patches also (those which phoronix makes fuss about). do i need the full kernel like the article suggests or can i use one of your nouveau.git branches?
17:04 Yoshimo: i guess it is a missing file, that is why my first attempt to fix it was re-installing all packages that had nouveau in their package names
17:05 karolherbst: kugel: it is the branch you are on
17:06 karolherbst: kugel: you have a boost file where pstate is
17:06 karolherbst: kugel: but your vbios has no boosting
17:06 karolherbst: like the 680 in the article
17:07 Yoshimo: why do the results for boost2 on phoronix sometimes show lower numbers as boost1?
17:07 karolherbst: Yoshimo: you mean those two tests of the 760?
17:07 karolherbst: no idea
17:07 karolherbst: bad timing in the pipeline?
17:07 karolherbst: no idea
17:07 kugel: i see, I guess I'm out of luck :-)
17:07 karolherbst: kugel: right
17:07 Yoshimo: is it just measurement variation and it was unlucky coincidence?
17:07 karolherbst: kugel: allthough your tables in the vbios are big enough, if you are up to, you can just tinker with it :D
17:08 karolherbst: Yoshimo: unlucky concidence or something else
17:08 karolherbst: Yoshimo: I think his results are sampled by 3 runs by default
17:08 kugel: btw, the dota2 performance is at about 50% of windows. i havent tried the binary driver on linux in a while but a few months ago it was also noticeably faster in this game
17:08 karolherbst: kugel: 50% compared to windows is really good though :)
17:09 karolherbst: if nouveau can get at least 50% compared to any game compared to nvidia, we are quite happy already
17:09 Yoshimo: if it is above 30fps though
17:09 karolherbst: well 50% isn't "much" of a difference in general
17:09 kugel: wait, 50% isnt actually true. I have also deselected some graphic options to achieve 50%, so i guess it's more like ~30
17:10 karolherbst: kugel: with my current branch?
17:10 karolherbst: and full reclocked?
17:10 kugel: interestingly, the high quality water option is a heavy hit on performance
17:10 karolherbst: ohh
17:10 karolherbst: yeah stuff like that might happen
17:10 karolherbst: the shooting animation in csgo also has a big hit on performance
17:11 kugel: I'm talking about pstate 0f on your kepler_stable_reclocking_v2 branch, yes
17:11 Yoshimo: you wanted to figure that one out earlier karol, didn't you?
17:11 karolherbst: okay, well anybody is free to look where the bottleneck is, but currently it is mostly a waste of time because we don't have all perf counters yet
17:13 kugel: I'm afraid this is not my area of expertise :/ but I can live with the curret nouveau performance
17:13 kugel: indefinitely better than constanty dualbooting
17:14 karolherbst: well
17:14 karolherbst: we will need more devs in the end which can code on the mesa bits
17:14 karolherbst: I think
17:14 karolherbst: that's the place where most perf issues will be fixed in the end
17:15 karolherbst: kugel: but as long as you are above 15% you are better of than me :D
17:15 karolherbst: or other who want to play saints rwo the third
17:39 pmoreau: imirkin: I’m trying to get it to work using ida, but I’m having some trouble initialising it.
17:39 imirkin: pmoreau: ida_init() i think
17:39 pmoreau: Since I need to have it cross device, I declared it as a static inside nouveau_blacklight.c
17:39 imirkin: in some only-ever-called-once function
17:39 imirkin: you still need to init it
17:40 pmoreau: Right, but since it *could* but accessed from multiple threads, I added a static mutex. And here is the problem, how do I init that mutex without adding an additional mutex?
17:40 imirkin: or perhaps it has a static initializer you can use?
17:40 pmoreau: https://github.com/pierremoreau/nouveau/blob/fix_bl_names/drm/nouveau/nouveau_backlight.c
17:40 pmoreau: ^ This is what I currently have
17:41 imirkin: yeah so that's HUGELY unnecessary
17:41 imirkin: just add a nouveau_backlight_ctor()
17:41 imirkin: which is called once by the nouveau module before all the other stuff
17:41 imirkin: which does the ida_init() junk
17:41 pmoreau: And a dtor for the ida_destroy…
17:41 imirkin: sure, why not
17:42 pmoreau: Hum, yeah, completely forgot about those… --"
17:42 imirkin: that's the general naming convention btw... ctor is called once, init is called "often"
17:42 pmoreau: I should hack more slightly more often in the kernel
17:42 imirkin: [not actually often, but you get the point]
17:42 pmoreau: Yup :-)
17:43 karolherbst: pmoreau: at least in c++11 static is thread safe by default
17:43 pmoreau: Oh, and second question while I’m at it: how should I empty the bl_connectors list I introduced? By looping over the elements and calling list_del?
17:43 karolherbst: pmoreau: I guess there should be something similiar in C11 :/
17:44 karolherbst: mhh but linux uses C99, well doesn't matter that much anyway cause there are most of the time better solutions like the ctor thing
17:44 karolherbst: pmoreau: there is also once_init
17:45 pmoreau: karolherbst: But I think the kernel is still C99? And anyway, the init function is something like `void (object*)`, so it still wouldn’t work.
17:45 imirkin: karolherbst: pthread_once only works if you have pthread. no such thing in the kernel.
17:45 karolherbst: imirkin: ahh right...
17:45 karolherbst: oneinit was it
17:45 imirkin: C11 doesn't magically make things work, it just introduces some libraries.
17:45 karolherbst: pmoreau: the pain with ctor is, that you don't have all subdevs yet
17:46 karolherbst: imirkin: yeah I know. I just forgot that they use a threading API for that
17:46 pmoreau: imirkin: Errr, wait, isn’t ctor still called per device?
17:46 imirkin: pmoreau: you can define it however you want
17:46 imirkin: pmoreau: call it just once at module init
17:46 karolherbst: pmoreau: so to sum it up: ctor used for subdev initialization, oneinit is ran after every subdev is "ready" and init is called everytime the device needs to be initialized again
17:47 karolherbst: pmoreau: like each suspend-resume cycle also calls fini/init
17:47 imirkin: pmoreau: it's an explicit function
17:47 karolherbst: pmoreau: right
17:47 imirkin: karolherbst: he's not dealing with the core stuff, so none of those rules apply explicitly.
17:47 karolherbst: the backlight issue, right?
17:48 pmoreau: Yes
17:49 karolherbst: stupid ISP, I can't acces fdo anymore because their routing is messed up again :/
17:50 pmoreau: Ah right, I had completely forgotten `nouveau_drm_init()` and `nouveau_drm_exit()` :-D
17:57 karolherbst: the hell... I am currently looking at the vbios of the one with the ram issue on the nve7
17:57 karolherbst: and the vbios just looks odd
18:01 Yoshimo: https://pastee.org/6fsv6 , karolherbst.
18:02 karolherbst: Yoshimo: there is nomodeset again
18:02 Yoshimo: where does it come from again, either i am drunk or i copy the wrong log from the wrong place ;)
18:04 karolherbst: but thanks to the nve7 vbios, I have the right coefficient now for mode 1 :D
18:05 Yoshimo: how many formulars are you dealing with by now?
18:05 karolherbst: Yoshimo: two
18:05 karolherbst: 1677721.636363636
18:06 karolherbst: https://gist.github.com/karolherbst/d18f3c511e66d8cffd6f09cbcc62edc6
18:07 karolherbst: can't be wrong I assume :D
18:09 karolherbst: yeah, this is so right now
18:11 karolherbst: stupid lenovo guys, making it easy to get nvidia secrets...
18:11 karolherbst: "secrets"
18:13 Yoshimo: did they violate codes of secrecy or could have any other card with more data to your formula finding have done it as well?
18:14 karolherbst: could be any other card as well
18:14 karolherbst: but they just did something which they hadn't to do
18:14 karolherbst: well, it makes it easier
18:14 karolherbst: (1677721 + 63/99) / 100000
18:14 karolherbst: looks still odd
18:14 karolherbst: 1677721 is 0x199999
18:14 karolherbst: ....
18:15 karolherbst: and 63 is 0x3f
18:15 Yoshimo: not always is the assumption from my math class correct: if the result is ugly, it is wrong
18:15 karolherbst: yeah, but this is engineering
18:16 karolherbst: where usually all numbers are odd :D
18:17 Yoshimo: 0x200000 looks way better, lets round it a bit
18:19 karolherbst: :D
18:21 mupuf_: karolherbst: what the heck happened?
18:21 karolherbst: mupuf_: lenovo used mode 1 for constant voltage...
18:21 karolherbst: leaking the coefficient for mode 1, c0
18:21 karolherbst: :D
18:21 karolherbst: now I get this: https://gist.github.com/karolherbst/d18f3c511e66d8cffd6f09cbcc62edc6
18:21 pmoreau: imirkin: Thanks! That did the trick. :-)
18:22 mupuf_: karolherbst: that is great!
18:22 karolherbst: :D
18:22 karolherbst: yeah I had 16.66 before
18:22 mupuf_: how far were you from the truth?
18:22 karolherbst: but it is more close to 16.777
18:22 karolherbst: but if I would go the other way I would have goten 16.85 or something
18:22 mupuf_: well, you will need to adjust the other one now
18:22 karolherbst: so it is pretty much in the middle of both values
18:23 mupuf_: great news!
18:23 karolherbst: mupuf_: right I can just increase it by the difference
18:25 karolherbst: mhh 0.7%
18:25 karolherbst: pretty close
18:39 karolherbst: mupuf_: wow, it makes more sense now!
18:39 karolherbst: 16.7772163, 15.472735253
18:39 karolherbst: then
18:39 karolherbst: those each ^2: 67386.67
18:39 karolherbst: but my other coefficient is 68738.15231
18:39 karolherbst: it is getting closer
18:40 mupuf_: why do they make more sense?
18:40 Yoshimo: nomodeset is part of the recoverymode, i was lazy when you said "try startx as root"
18:40 karolherbst: just easier to get from those to the other ones
18:40 karolherbst: mupuf_: I think that the other both coefficients are somewhat calculated out of those two
18:41 karolherbst: Yoshimo: :D
18:41 Yoshimo: well part 1: user fail, maybe the rest is as simple as that too
18:42 mupuf_: karolherbst: well, if you know for sure what one value is, you can increase the accuracy of the others
18:42 karolherbst: mupuf_: I already did
18:43 mupuf_: karolherbst: reator should not be lagguy anymore
18:43 karolherbst: but it is really messy to RE them, because of the inaccuracy of the set voltage :/
18:43 karolherbst: mupuf_: ! awesome
18:43 karolherbst: mupuf_: but half of those coefficients should be 100% right now and the other might be off by 1% or less
18:43 karolherbst: so this is okay I guess
18:43 mupuf_: I bit the bullet and went to buy a new router when I saw that putting my modem into bridge mode got me to 0% packet loss
18:44 mupuf_: getting there, indeed!
18:44 mupuf_: maybe nvidia would be OK giving the exact coefficients
18:44 karolherbst: yeah
18:44 karolherbst: we just tell them what we found out and they say: okay, close enough :D
18:45 Yoshimo: mupuf_: if they are, it would have been quite some time that has been wasted
18:46 karolherbst: mupuf_: https://github.com/Gnurou/nouveau/issues/13
18:47 mupuf_: karolherbst: :)
18:47 mupuf_: you can also again say you got closer :p
18:48 karolherbst: I just did with the last comment
18:49 karolherbst: imagine that other information might be "leaked by accident" in the vbios :)
18:50 Yoshimo: https://pastee.org/eapge , ok next one for the hall of shame
18:50 karolherbst: Yoshimo: your headset :D
18:51 karolherbst: but I have no clue why it crashes X :/
18:51 Yoshimo: who cares, it doesn't even work with it attached
18:51 karolherbst: well you should still report it somewhere, that it crashes X
18:51 karolherbst: Yoshimo: yeah, but the log is different
18:52 Yoshimo: in the past both sound and X worked with the same constellation of hardware, so it is weird
18:52 Yoshimo: somewhere, mhmm suggestions?
18:53 karolherbst: Yoshimo: yeah, log without the headset :)
18:54 Yoshimo: i was referring to "report it somewhere"
18:54 karolherbst: ahh okay
18:54 karolherbst: mhh
18:54 karolherbst: evdev
18:55 karolherbst: but in the end glamor won't initialized
18:55 karolherbst: Yoshimo: you could try to start weston from a tty
18:55 karolherbst: and see if you get EGL working
18:56 karolherbst: but in the end it should be something related to your mesa installation
18:56 Yoshimo: i would say it is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/1502796
18:56 karolherbst: and plasma should fallback to Xrender
18:56 karolherbst: yeah, sounds about right
19:06 karolherbst: mupuf_: time to look over three simple patches of mine where one is already rb by you? (it also contains one of patch of the reclocking series and could be pushed earler in this context) https://github.com/karolherbst/nouveau/commits/hwmon
19:12 mupuf_: karolherbst: sure, I can have a look
19:12 mupuf_: karolherbst, hakzsam: can you check that wtrpm is back up and working?
19:12 mupuf_: my mobile provider does not have the new IP address set
19:12 hakzsam: mupuf_, it is not
19:13 hakzsam: same for reator through ssh
19:13 mupuf_: ok, so you also have the wrong ip address
19:13 mupuf_: so you need to wait a little
19:13 hakzsam: np
19:13 karolherbst: mupuf_: thanks, and ignore the NULL pointer check patch, it is useless
19:14 karolherbst: I am in
19:15 karolherbst: hakzsam: empty your dns cache :p
19:15 karolherbst: ohh well
19:15 karolherbst: wtrpm isn't here still
19:17 karolherbst: mupuf_: I get a connection refused though
19:17 karolherbst: mupuf_: maybe you forgot the port rule or something?
19:20 mupuf_: karolherbst: well, yeah, I did write it
19:20 mupuf_: can you try connecting to reator?
19:20 mupuf_: because that at least worked for me
19:21 karolherbst: yeah I can connect to reator
19:21 karolherbst: or I could 8 mintues ago
19:21 karolherbst: still working
19:21 mupuf_: oh, fixed!
19:21 mupuf_: try again!
19:21 mupuf_: I put the wrong IP
19:21 karolherbst: :D
19:21 karolherbst: yep
19:21 karolherbst: works
19:21 mupuf_: yeepee
19:22 mupuf_: I need to fix this pesky timeout for the ping
19:23 mupuf_: ok, hopefully, you will not have any lag with this
19:23 karolherbst: :)
19:23 karolherbst: we will see
19:25 mupuf_: http://www.speedtest.net/result/5258392519.png <-- the network does not seem to be slower than before at least
19:26 karolherbst: :D
19:26 mupuf_: I don;t remember it being that fast though :D
19:26 karolherbst: your ping though
19:26 mupuf_: this is cable...
19:26 mupuf_: so yeah, there is some latency
19:26 karolherbst: k
19:26 mupuf_: but short of an optic fiber, I do not think it will get any better
19:27 mupuf_: what is your ping?
19:27 karolherbst: 4ms
19:27 karolherbst: but I am using wifi, so...
19:27 mupuf_: :o
19:27 mupuf_: DSL?
19:28 karolherbst: not really, it is some kind of ISP with direct T3 access I think and I kind of am in a network before that
19:28 karolherbst: 10 hops to google
19:32 Yoshimo: https://pastee.org/vxzas
19:33 karolherbst: mhh "couldn't get display device"
19:34 imirkin: Yoshimo: you need mesa 11.2.0+ to get working accel on GM20x
19:34 imirkin: (and kernel 4.6-rc1+)
19:35 Yoshimo: imirkin: as we said already i a have karols out of tree module, which should be fine here and oibafs repo with 11.3 git
19:35 imirkin: Yoshimo: pastebin dmesg
19:35 imirkin: [given the frequency of your mistakes, i'm inclined to believe PEBKAC]
19:36 Yoshimo: i don't doubt it, still i need help figuring it out
19:39 hakzsam: karolherbst, are you on reator?
19:39 karolherbst: hakzsam: no
19:52 Yoshimo: https://pastee.org/727ta dmesg from a few minutes ago
19:52 karolherbst: Yoshimo: yeah, I think your userspace is just borked
19:53 Yoshimo: any reccomendations on how to fix it, packages involved maybe?
19:55 karolherbst: Yoshimo: is weston installed?
19:55 karolherbst: you could try to start weston, this at least removes X from the game
19:58 yoshimo_: weston claims a missing backend or so
19:59 imirkin: yoshimo_: is there a /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
20:04 pmoreau: imirkin: Ping for my U64/S64 conversion patch. How should we proceed?
20:05 imirkin: you should definitely ping it coz i haven't the faintest recollection of it
20:08 pmoreau: We ended up discussing where those should happen: Nouveau vs backends, but never reached an agreement
20:09 imirkin: "conversions"?
20:09 imirkin: ohhhh
20:09 imirkin: like CVT conversions
20:09 imirkin: i remember now.
20:09 pmoreau: Right
20:09 imirkin: and your complaint is that it's a bit asymmetrical
20:10 imirkin: in that you can go u32 -> u64
20:10 imirkin: but not u64 -> u32?
20:10 imirkin: (or vice-versa?)
20:11 pmoreau: Let’s see… Yes, the card didn’t complained for one of them, but did for the other.
20:11 imirkin: so then i think the right thing is to have the lowering code take care of it... either pre-ssa or post-ssa... i think post-ssa might be easier.
20:11 pmoreau: But looking at NVIDIA generated code, they do not use a CVT in neither direction, only from/to u32 to lower
20:11 imirkin: i.e. NVC0LegalizeSSA
20:12 imirkin: i see
20:12 imirkin: you did it at a lowering stage.
20:12 imirkin: er, pre-ssa.
20:16 pmoreau: Should I move it to NVC0LegalizeSSA then? Or is pre-SSA good enough?
20:17 imirkin: i think what you have is probably fine.
20:17 pmoreau: K
21:56 martm: llvm had round about 15 or so projects to digest, which were against winning the threading issues, or race condition detection
23:40 karolherbst: meh, stupid cross-origins stuff :/ Why does it have to be such a big pain to load some JSON data from elsewhere in html...
23:46 imirkin: jsonp
23:47 karolherbst: yeah well
23:47 karolherbst: you need server side support for this
23:48 karolherbst: I am really thinking about writing some node.js crap and let it run somewhere...
23:55 imirkin: ahaha
23:56 karolherbst: and parsing json data in php is most likely a completly insane thing to do :/
23:56 imirkin: should be easy
23:56 karolherbst: and all I wanted is a local html file parsing some json data
23:56 karolherbst: ...
23:56 imirkin: i'm sure there are helpers
23:57 imirkin: last time i did php was back when php 4.0 was just coming out
23:57 karolherbst: :D
23:57 karolherbst: but php
23:57 imirkin: the move from 3 to 4 was cool