03:02 imirkin: karolherbst: fyi, worked out the lowering for shared int64
05:06 imirkin: or not...
05:06 imirkin: HdkR: what am i doing wrong? https://hastebin.com/ecuhoduway.scss
05:06 imirkin: it goes into an infinite loop, it would seem
05:09 imirkin: OH
05:09 imirkin: f me.
05:09 imirkin: nevermind
05:09 imirkin: just kidding.
05:09 imirkin: apparently the id of the register matters
05:09 imirkin: it doesn't just know what you want
05:11 HdkR: what's all this then
05:12 imirkin: phi fail
05:12 HdkR: ah
05:13 imirkin: oh ... the stupid loop detect thing?
05:13 imirkin: how did that work....
15:39 emersion: i did more investigations wrt. my modifiers issue, here are my findings: https://gitlab.freedesktop.org/drm/nouveau/-/issues/36#note_765017
15:41 imirkin: emersion: that high bit on pitch was "pitch" (vs blocklinear) i thought. did i get that wrong?
15:41 emersion: yea sorry just fixed it
15:42 emersion: PITCH is actually 0x01a
15:42 imirkin: right
15:42 imirkin: afaik the only requirement is that it's aligned to 256
15:43 imirkin: but there could well be things i don't know ;)
15:43 emersion: eh, that would explain it
15:43 emersion: 6912 is divisible by 256, but not 6784
15:44 imirkin: oh, so 0x1a iss actually not 6784?
15:44 imirkin: it's 6656. heh
15:44 emersion: oh
15:44 imirkin: so yeah, then i'm guessing it gets mad that the pitch is lower than the width
15:44 emersion: eh
15:44 emersion: i'm very thankful to hw devs to raise INVALID_STATE on this :)
15:45 emersion: where is the pitch chosen? libdrm? mesa?
15:45 emersion: kernel?
15:45 imirkin: no clue.
15:45 imirkin: depends how you create the buffer
15:45 emersion: GBM
15:45 imirkin: yeah, but more precisely?
15:46 emersion: it goes GBM → DRI interface → Gallium → nouveau in mesa
15:46 emersion: then → libdrm
15:46 emersion: it's using gallium's resource_create callback
15:47 imirkin: hm
15:47 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv50/nv50_miptree.c#n238
15:48 imirkin: pitch_align == 128
15:48 imirkin: and 6784 is aligned to 128. so the system works.
15:48 imirkin: should make it say if scanout, then use 256
15:49 imirkin: (this is called from nvc0_miptree as well, for linear layout)
15:50 emersion: was looking at this :P
15:50 emersion: makes sense, let's try it
15:51 karolherbst: imirkin: btw.. I find very interesting races now that I've enabled tsan in libdrm as well :/
15:52 karolherbst: so apparently we can start a nouveau_bo_wait while the bo has no pushbuf bound, but another thread sets it via pushbuf_validate :/
15:52 karolherbst: which.. feels wrong
15:53 karolherbst: or rather annoying to fix
16:22 imirkin: emersion: oh, and iirc we only allocate linear surfaces when PIPE_BIND_SCANOUT is set
16:23 emersion: hm, i'm now hitting an assertion failure in nvc0_user_vbuf_range
16:23 imirkin: modifiers were kinda bolted onto nouveau, not properly integrated
16:23 imirkin: i thought i fixed that
16:23 imirkin: did you pull something semi-recent?
16:23 emersion: yeah, do you have a commit hash?
16:23 imirkin: and are you using instancing on client-side vbo's?
16:24 emersion: hm, i don't know what that is
16:24 emersion: i'm only doing extremely simple GL stuff
16:24 imirkin: instancing = glDrawInstanced
16:24 emersion: no, nothing like this
16:24 imirkin: client-side vbo's == ... client side vbos...
16:24 emersion: i don't use vbos
16:24 imirkin: ok, then that's a yes.
16:24 imirkin: you just pass a pointer to CPU-side data with vertices right?
16:25 emersion: yeah
16:25 imirkin: aka "client-side"
16:25 emersion: oh
16:25 imirkin: do you do instancing?
16:25 imirkin: https://cgit.freedesktop.org/mesa/mesa/commit/?id=f763d0f1952151e0fcae596e85600e7f391ea442
16:25 imirkin: oh crap
16:25 imirkin: that was on nv50
16:26 imirkin: you're on nvc0, so won't matter
16:26 emersion: https://github.com/swaywm/wlroots/blob/master/render/gles2/renderer.c#L299
16:26 emersion: just glDrawArrays
16:26 imirkin: yeah, so no instancing
16:26 imirkin: instancing == glDrawArraysInstanced or something
16:26 emersion: yea\
16:26 imirkin: so not affected by that bug on two separate counts
16:26 imirkin: (a) different hw, (b) not using the affected feature
16:27 emersion: right
16:27 imirkin: what's the assertion?
16:28 imirkin: assert(nvc0->vb_elt_limit != ~0);
16:28 imirkin: that guy?
16:28 emersion: i think that's the one yeah, but gdb only indicates the function lineno
16:28 emersion: :202
16:28 emersion: it's clearly an abort though, and there's only one
16:29 imirkin: hmmm
16:29 imirkin: that really shouldn't happen
16:29 imirkin: with client-side buffers, there should always be limits...
16:29 imirkin: perhaps something changed in mesa core
16:37 imirkin: unfortunately i can't look into it right now
16:38 imirkin: emersion: btw, the whole client side is from the idea of a client/server, where the client is sending GLX calls to a remote X server, and then the X server has a GL impl to do the rendering
16:39 imirkin: but nowadays you can think of it a "client=CPU" "server=GPU"
16:39 emersion: ok!
16:43 emersion: hm, so i checked out mesa 20.3.2 and tried to reproduce
16:43 emersion: and got a different INVALID_STATE error
16:44 emersion: oh wait it's still using align=128
16:44 emersion: my PIPE_SCANOUT check is wrong
16:47 emersion: oh, right, PIPE_SCANOUT is missing when modifiers are supplied
16:47 emersion: i mean: oh, right, usage flags is missing when modifiers are supplied
16:49 emersion: "DRM: core notifier timeout" means i should reboot, right?
16:51 emersion: fwiw, i don't hit the assert with 20.3.2
16:51 emersion: i could bisect if that helps
16:55 emersion: oh eh, weston uses a BLOCK_LINEAR_2D layout and it works fine
16:56 emersion: pitch=6720
16:58 imirkin: so with blocklinear, there is no pitch
16:58 imirkin: there are "gobs"
16:58 imirkin: which are of various sizes, as specified by the tile mode
17:03 emersion: ok, so with the patch and with 20.3.2 it doesn't crash, but just displays a black screen with some gray lines at the top
17:05 imirkin: yay!
17:05 imirkin: mission accomplished
17:05 emersion: lol
17:06 imirkin: don't worry about the bisect, mareko said he changed it
17:06 imirkin: so i need to poke around to figure out how to adapt
17:07 emersion: ah, i understand why wlroots picks LINEAR now
17:07 emersion: opengl tells us only LINEAR is supported
17:07 imirkin: hehe
17:07 emersion: ah, no
17:07 emersion: hmmmm
17:12 emersion: ok
17:13 emersion: it's because the modifiers exposed by the gl impl don't intersect those exposed by kms
17:13 emersion: opengl exposes 0x300…0010 through 15
17:13 emersion: none of these support scanout
17:15 imirkin: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3724
17:15 emersion: aaand everything works fine if i don't intersect with the gl modifiers
17:15 emersion: ah
17:16 emersion: well, in any case, there's a bug when using LINEAR for the primary plane
17:16 imirkin: due to the lack of layout right?
17:16 imirkin: i mean, due to the 128-alignment
17:17 imirkin: we should just align to 256 for PIPE_BIND_SCANOUT
17:17 imirkin: (&& linear)
17:17 emersion: well, that was one issue. the other is that i still get a black screen with gray lines
17:17 imirkin: oh
17:17 imirkin: right
17:17 imirkin: you're trying to render to this buffer, right?
17:17 imirkin: and then display it?
17:17 emersion: hm, yeah, but maybe there's a sync issue
17:18 emersion: because i'm importing the buffer as a dmabuf, rendering to it, then calling glFinish()
17:18 emersion: err, glFlush()
17:18 imirkin: ah yeah
17:18 imirkin: that doesn't do anything
17:18 emersion: let's try to see if glFinish() improves things
17:18 imirkin: glFinish should wait on a fence
17:19 emersion: well it's supposed to
17:19 imirkin: no
17:19 imirkin: glFlush is "send out the commands you have queued up"
17:19 imirkin: http://docs.gl/gl4/glFlush
17:19 imirkin: vs http://docs.gl/gl4/glFinish
17:20 emersion: glFlush is also a barrier
17:20 emersion: see e.g. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7384
17:20 imirkin: yes, it's a barrier
17:20 emersion: then with implicit sync the kernel should wait for the barrier to complete
17:20 imirkin: but it still says nothing about when the flushed commands complete executing
17:20 imirkin: mmmm
17:20 imirkin: yeah i don't think we have anything like that for the display pipeline
17:20 imirkin: perhaps we should :)
17:20 emersion: at least that's what daniels explained
17:21 imirkin: implicit sync is whatever the driver wants it to be
17:21 emersion: hm
17:21 imirkin: in nouveau's case, when you submit commands to be executed, it will wait for stuff potentially
17:21 emersion: well i'm open to suggestions wrt. rendering to a dmabuf
17:21 imirkin: but here you're not submitting commands to be executed
17:21 imirkin: you're just saying "flip to this buffer"
17:21 emersion: how can i say to the driver that i want it to Do The Thing?
17:21 imirkin: well, i think you're right - nouveau probably SHOULD Wait
17:22 imirkin: but it totally doesn't :)
17:22 emersion: ok :P
17:22 imirkin: and adding such a wait could have various implications
17:22 imirkin: like ... what does that mean for e.g. front-buffer rendering
17:22 emersion: all other drivers i know of are doing it
17:23 imirkin: i think there's another thing to go with dma-buf
17:23 imirkin: i forget what it's called
17:23 emersion: maybe explicit sync helps with it?
17:23 imirkin: oh yeah -- syncfd
17:23 imirkin: (i think?)
17:23 emersion: sync files
17:23 imirkin: which addresses this in some way
17:23 imirkin: that's the extent of my knowledge though
17:23 imirkin: so ... limited :)
17:24 emersion: alright, so glFinish() fixes it
17:24 daniels: imirkin: you don't execute flips in front-buffer rendering
17:24 emersion: i'll submit the pitch align fix
17:25 daniels: you provide DirtyFB if you like, but otherwise you just wait for scanout to catch up to whatever it is you haphazardly threw into the buffer
17:25 imirkin: daniels: yeah, but how does the driver know what you want?
17:25 daniels: hm?
17:25 imirkin: e.g. the first time you try flipping to it
17:26 daniels: in the implicit sync model, it waits for the completion of any pending ops flushed to the kernel at the time a flip was requested
17:26 imirkin: so if you're front-buffer rendering, it's not guaranteed to ever display :)
17:26 imirkin: oh, i see. at the time it was requested.
17:26 daniels: _at the time a flip was requested_
17:26 imirkin: fair enough
17:26 daniels: yep
17:26 imirkin: so yeah. i'm pretty sure nouveau has none of that, but it totally makes sense that it should.
17:26 daniels: then beyond that you don't repeatedly flip, you just call DirtyFB as a courtesy to let the kernel know of the damage region
17:26 imirkin: right
17:27 daniels: used e.g. if you have 'smart' (i.e. caching-sink) displays
17:27 emersion: is the explicit sync stuff completely in DRM core, or are there things the driver needs to implement?
17:27 imirkin: daniels: or command-mode panels?
17:27 daniels: imirkin: exactement
17:27 daniels: emersion: the core has helpers for it
17:27 imirkin: emersion: i'd say it's completely in the driver :)
17:27 emersion: ok, rip
17:28 imirkin: both kernel- and driver-side
17:28 imirkin: er, both kernel- and user-side
17:28 daniels: drm_gem_fb_prepare_fb() is the generic helper, but I would assume nouveau rolls its own everything so would need to insert its own wait
17:28 imirkin: like you can't just remove it from nouveau and expect things to work -- we assume it's there, it's an active part of the synchronizaton strategy
17:29 emersion: for some reason i thought DRM_CAP_SYNCOBJ only depended on a recent enough kernel, but indeed nouveau doesn't have it
17:30 imirkin: you need a kernel so recent, the patches to support it haven't been written yet :)
17:30 imirkin: i do think skeggsb was looking at it at one point
17:30 imirkin: but i dunno what the results, if any, were
17:31 emersion: would adding the implicit wait be tricky?
17:31 imirkin: SHOULDNT be, but ... could be :)
17:31 imirkin: i dunno what the right way to implement it is, tbh
17:31 emersion: as always :)
17:32 imirkin: the display core has all this "interlock" logic
17:32 imirkin: perhaps you can just wait on the fence that way directly
17:32 imirkin: if not, you have to get more creative and do the wait somewhere else
17:33 imirkin: lol
17:33 imirkin: #define NV827D_UPDATE_NOT_DRIVER_FRIENDLY 31:31
17:33 imirkin: #define NV827D_UPDATE_NOT_DRIVER_UNFRIENDLY 30:30
17:33 emersion: eh
17:33 imirkin: don't call it "DRIVER_FRIENDLY", just not as unfriendly as the other thing
17:34 imirkin: (i have no clue what those do)
17:34 imirkin: (it was just funny)
17:35 imirkin: emersion: ok, so the display stuff *does* have SET_SEMAPHORE_CONTROL stuff
17:35 imirkin: (which is aka fences)
17:36 emersion: unused right now?
17:36 imirkin: dunno
17:36 emersion: how does it work when *not* using dmabufs, and using just swapBuffers?
17:36 imirkin: drm/nouveau/dispnv50/base507c.c
17:36 imirkin: looks like it does set those
17:41 imirkin: i'm probably blind, but i don't actually see where the semaphore stuff is set, if ever
17:41 imirkin: could be very clever grep-evading macros
17:41 imirkin: but even grepping for 'sema' doesn't reveal it
17:43 daniels: you won't have native semaphores if you're doing presentation from another device
17:43 daniels: so those would only ever be an optimisation, not the sole path
17:44 imirkin: if it's from another device, how can we sync?
17:44 imirkin: (a) i'm pretty sure we can't display from sysmem
17:45 imirkin: i don't think there's a need for others. basically we're copying this stuff to vram first, then displaying. sync is out.
17:45 imirkin: (and this might not work with dma-buf at all, not sure)
18:06 emersion: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8500
18:07 imirkin: emersion: yes - scanout is always 256
18:07 imirkin: nv50 and nvc0
18:07 emersion: ok
18:07 imirkin: and nv30 too i'd imagine
18:07 imirkin: but it might already do that
18:08 emersion: yeah sounds like it checks for that already
18:08 emersion: kind of -- screen->eng3d->oclass >= NV40_3D_CLASS ? 1024 : 256
18:09 imirkin: int pitch_align = MAX2(
18:09 imirkin: screen->eng3d->oclass >= NV40_3D_CLASS ? 1024 : 256,
18:09 imirkin: heh
18:09 imirkin: found it at the same time. anyways, it's covered.
18:19 emersion: pushed with a nv50 patch as well
18:22 emersion: thanks for your help!
18:24 RSpliet: emersion: glad you were able to scratch this itch! feel free to come back if you have more itches ;-)
18:25 emersion: well i'll definitely come back, need to get that implicit sync issue fixed :P
18:32 emersion: opened this for the glFlush issue: https://gitlab.freedesktop.org/drm/nouveau/-/issues/41
18:36 imirkin: you'll have to catch skeggsb for working out how to properly address this
18:36 imirkin: he knows the hardware and kernel driver inside out
18:56 karolherbst: ufff...
18:56 karolherbst: this pcli->kref[bo->handle].push is annoying :/
18:57 imirkin: i think i mentioned my thoughts on libdrm's suitability...
18:57 karolherbst: yeah...
18:59 karolherbst: apparently using bufctx all the way should solve it, but I don't see how it would solve this particular case where waiting on/mapping a bot has this silly data race
18:59 karolherbst: I mean.. I got the pushbuffer race thing all figured out, now it's just those random things
19:03 daniels: imirkin: ‘how do we sync’ - you wait until the notification in the kernel
19:04 daniels: I mean, this has to work, otherwise every dual-GPU case e.g. laptops would need manual app-side detection and glFinish ...
19:04 daniels: (see also non-x86 systems with separate GPU & display)
19:04 imirkin: daniels: PRIME just doesn't have vsync
19:05 imirkin: i mean, i understand how you'd *like* it to work
19:05 imirkin: but currently it's just not a thing with nouveau
19:05 daniels: well yes, X11 is not the poster child for perfect display
19:05 imirkin: ;)
19:05 karolherbst: X11 has tearing? ... so what?
19:05 karolherbst: just remove X11, problem solved
19:05 karolherbst: :p
19:05 HdkR: fbdev, the future of Linux
19:05 imirkin: or learn to stop worrying and love the bomb
19:06 imirkin:doesn't care about tearing
19:06 karolherbst: I'd close all X11 bugs as -EWONTFIX
19:08 karolherbst: ohh, mhh, we shouldn't call pushbuf_validate.. right
19:08 karolherbst: that was the problem
19:09 karolherbst: okay.. so I can ignore that race until I convert to the bufctx stuff
19:09 daniels: imirkin: anyway, long story short, the function I pointed to earlier is what you need to painlessly handle sync whether it's local or foreign
19:09 daniels: you can specialise local into the semaphore pipeline if you like
19:09 imirkin: daniels: ok, but ignoring sync, i don't think we can scanout foreign buffers in the first place
19:09 daniels: but that will only work for nv50(?)+, since it's part of atomic :P
19:10 KungFuJesus: imirkin: have any things for me to try on NV43 BE yet?
19:10 imirkin: for reverse prime, userspace makes copies
19:10 imirkin: KungFuJesus: sorry, no. been looking at other things. i haven't forgotten though
19:10 imirkin: KungFuJesus: unrelated - would you be willing to try some kernel patches which mess with display stuff?
19:11 imirkin: nouveau uses some "legacy" stuff which should be fixable, but i'm also not willing to just do it without testing
19:41 ccr: probably not needed, but I can test at least kernel stuff on my craptop (NV4E, GeForce Go 6150). Mesa also, if needed, but will have to spin few scripts etc. as I can't be assed to actually compile anything on the target itself :P
19:41 ccr: it's not BE of course
19:41 imirkin: yeah, this is for BE things specifically
19:41 ccr:nods
19:42 imirkin: basically the kernel was super-loose about how it handled stuff for BE. this got tightened up, but without fixing the drivers, the "old" thing had to stick around too
19:42 imirkin: i'd like to move nouveau to the "new" thing
19:42 imirkin: but without BE to test it on ... it's a wee tricky
19:43 ccr: understandably. not surprising either that BE stuff hasn't been tested much, probably not many users for it.
19:44 imirkin: my G5 died =/
19:44 imirkin: stupid power supply
19:44 imirkin: and the thing is built in such a way that it's basically impossible to remove
19:45 ccr: :/
19:54 HdkR: Oh jeez, just looked up the ifixit guide for it. That's terrible
19:54 imirkin: basically you just need some dynamite
19:54 HdkR: And of course you'd have to get a donor PSU since it isn't standard so that means ebay to find the correct one
19:54 imirkin: and then maybe...
19:55 imirkin: HdkR: yeah, i tried to follow one of those guides
19:55 imirkin: but was unsuccessful at removing it
19:55 imirkin: i failed at like the first step :)
19:55 HdkR: :D
19:58 imirkin: and i'm not like mechanically incompetent ... it's very tough
20:00 RSpliet: What? IFixit actually *sells* power supplies for a G5?!
20:00 HdkR: Nah, they just have a guide submitted by customer
20:01 HdkR: er, consumer
20:01 RSpliet: No
20:01 RSpliet: https://www.ifixit.com/Store/Mac/iMac-G5-Intel-Power-Supply/IF165-000?o=1
20:01 RSpliet: They sell a power supply
20:02 HdkR: Oh, that's an iMac G5. I was thinking PowerMac G5
20:02 imirkin: i have a powermac g5
20:03 imirkin: PowerMac7,2 iirc
20:03 imirkin: or 7,3
20:03 RSpliet: oh right
20:03 ccr: hmm. now I wonder... we've got 2 or 3 Power Mac G5 machines at work that are going to trash, they've also been stripped of some parts, but I don't know what's left in them. no idea what model they are either.
20:04 imirkin: you can be sure they still have their power supplies! :)
20:04 ccr: heh, probably, but no idea if those work :)
20:04 imirkin: unless someone got a sawzall to rip them out
20:05 ccr: I think the RAM and graphics card and such have been taken out at least.
20:06 ccr: amazingly enough there's at least one, maybe two machines that were actually even in use at least in 2019. no idea if they are now. probably should work, but I can't go and install Linux in them, unfortunately. :P
20:08 ccr: is it possible to boot those things from USB?
20:08 ericonr: I know some macs require you to burn a CD
20:08 ericonr: no idea if that's the case
20:09 imirkin: i did tftpboot
20:09 imirkin: but you have to have an apple keyboard if you want to do that
20:09 imirkin: coz you have to press some sort of key-combo on boot to enter OF
20:10 ccr: I see
20:10 imirkin: i don't remember the other boot options. i'm sure CD works, USB was less common for booting back then
20:10 ccr: yeah. was wondering if live USB linux was a possibility.
20:10 karolherbst: mhh, race on nvc0->screen->cur_ctx :/
20:10 imirkin: you'd need to do some research
20:10 karolherbst: sounds annoying to fix
20:11 karolherbst: macs can boot from USB since forever
20:11 karolherbst: I think
20:11 karolherbst: well
20:11 karolherbst: at least from USB 2.0
20:12 imirkin: yeah, i don't think USB 2.0 was a thing
20:12 ericonr: https://voidlinux-ppc.org/ (if you need a distro)
20:13 ericonr: and folks at #voidlinux-ppc should know about booting the G5
20:13 ericonr: I think someone there even has one
20:14 ccr: USB 2.0 ws circa 2000, though obviously implementations came later
20:14 karolherbst: I know I bought a USB 2.0 PCI card for my G4, but... not sure if I was able to boot from it :D
20:14 ccr: wikipedia lists USB 2.0 for all G5 models there
20:15 imirkin: ok. well i never tried.
20:15 imirkin: i treated it like my other ARM boards
20:15 imirkin: booting from tftp was easiest :)
20:15 imirkin: it was probably about as powerful ;)
20:18 ccr: I once had one of those x86 thin client PCs, a HP thing iirc, that I booted from tftp, then ran the rest from a USB stick because the internal storage in the hardware was not supported by linux. used as a webcam streamer pointed at plants. :P
20:19 ccr: somewhat awkward setup
20:37 KungFuJesus: imirkin: Sure, sorry was stuck in a meeting for work
20:37 KungFuJesus: I'm on kernel 5.7 currently but I can bump it up to 5.10 I believe
20:38 imirkin: KungFuJesus: well, this would be a custom kernel with patches
20:38 imirkin: any semi-recent kernel would be fine
20:38 imirkin: (anything from like ... 4.4 or later)
20:38 KungFuJesus: right, I just meant for what you're targetting
20:38 imirkin: that code doesn't change very often
20:38 KungFuJesus: but yeah, it's not a production machine or anything and backing up the kernel is not a big deal for me
20:38 imirkin: anyways, i think i have some patches, will try to put them together
21:22 emersion: hm, so nouveau uses dma_resv_get_excl_rcu in prepare_fb
21:23 emersion: drm_gem_fb_prepare_fb does the same
21:23 emersion: so sounds like this part is fine
21:37 imirkin: well, we have to make sure we wait on one of our implicit sync fences
21:37 imirkin: i have zero recollection as to how they're tracked
21:37 imirkin: i think there may have been a point in time when i looked at them
21:37 imirkin: but that was at least 5y ago
22:01 imirkin: emersion: some helpful things...
22:01 imirkin: asy = "assembly"
22:01 imirkin: asyw = "assembly wndw", asyh = "assembly head"
22:01 imirkin: wndw = basically, an image. head = basically, an output.
22:02 imirkin: unfortunately there are many generations of display hw, and some of them do some things differently
22:02 imirkin: so it doesn't always map 1:1 to a particular generation
22:04 emersion: what is an assembly?
22:05 imirkin: it's the state that's being built up
22:05 imirkin: by the driver
22:05 imirkin: but hasn't been written out to the hardware
22:06 imirkin: (perhaps not THE best term, but just explaining the var names you might see)
22:06 imirkin: coz it took ben explaining that convention about 3x to me before i actually remembered it :)
22:18 emersion: i see, thanks :)
22:20 emersion: Lyude: btw, feel free to CC me on these nouveau patches
22:21 Lyude: emersion: np, meant to send them out last night but I was distracted by america
22:21 emersion: ahah
22:21 emersion: no worries, take your time