00:02 karolherbst: airlied: yeah.. I guess I don't want clover to use the API differently :D
00:02 karolherbst: the issue is that clover just unbinds
00:02 karolherbst: and I think we can probably just remove all of that
00:06 airlied: karolherbst: I'm not 100% sure how defined the api is, it kinda evolved
00:07 airlied: I'll see if I can make image-read-2d.cl pas
00:07 airlied: pass
00:08 karolherbst: nice
00:08 karolherbst: got my first inline sampler to run :)
00:08 karolherbst: it's a bit hacky though
00:09 jekstrand: karolherbst: \o/
00:09 karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/5c2b953ad7667a098dc7285295aede9e033aa202
00:09 karolherbst: it's more an experiment on how to actually implement it
00:09 karolherbst: but that's roughly the idea
00:09 karolherbst: now I just have to store the data from nir and set the proper values when launching the kernel
00:09 karolherbst: but that's more or less the idea
00:20 airlied: uggh one of those how to I count samplers in NIR problems :-P
00:20 airlied: when all the uniform delcs are gone
00:22 karolherbst: huh?
00:22 karolherbst: the problem is something slighly different though :p
00:22 airlied: the way the nir->tgsi layer counts certain things for llvmpipe relies on nir info in a bit of a messy way
00:22 karolherbst: ahh
00:24 airlied: https://paste.centos.org/view/aa799375 "fixes" image-read-2d.cl
00:25 karolherbst: "uff"
01:29 airlied: karolherbst: https://gitlab.freedesktop.org/airlied/mesa/-/commits/llvmpipe-cl-img-wip
01:42 airlied: just image attributes to fix up
01:45 airlied: bleh order/format
02:09 airlied: jekstrand, karolherbst, jenatali : how does real hw do image order/format
02:09 airlied: some sort of hw -> CL convesrion table in shader?
02:10 jenatali:shrugs
02:10 jenatali: I stuff it in the kernel args buffer
02:11 airlied: jenatali: indeed, might have to do that for hw
02:19 jekstrand: airlied: Probably a side-band buffer
02:19 jekstrand: airlied: We don't have messages to query for that stuff.
02:20 jekstrand: airlied: We could read the surface state and get the format and do a bunch of conversion, but it's way easier to pass it in as "hidden" inputs.
02:20 jekstrand: airlied: I could ask our opencl folks if you'd like
02:20 jekstrand: There's no secrets there; the driver is open-source. I just don't know how to find anything in that code-base. :-)
02:23 airlied: jekstrand: no hurry, seems likely it's all done lookaside
02:24 airlied: I'm just going to fix llvmpipe to make it work
02:24 jekstrand: airlied: You're not going to wait for karolherbst to make a generic lookaside thing for all of clover?
02:26 airlied: jekstrand: indeed I could, I suppose clover could just lower it all to a const lookup
02:27 airlied: might be nicer than infecting my drivers with CL defines
02:27 jekstrand: airlied: I guess if you're re-compiling based on formats anyway....
02:29 jekstrand: If you're not, I wouldn't bother.
02:29 airlied:just wants to pass the test for now :-P
02:29 airlied: buty eah compile on format changes
02:31 jenatali: airlied: For when you eventually notice, the SPIR-V enum values for channel order/format are 0-based, and the SPIRV-LLVM-Translator embeds a hardcoded add to get them back to the CL-spec'd values
02:31 jenatali: See https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#_a_id_image_channel_order_a_image_channel_order
02:31 jenatali: I still don't get why...
02:35 jekstrand: Yeah...
02:37 jekstrand: karolherbst: First off, you need a new nick, kar<tab> isn't even guaranteed. :-P
02:38 jekstrand: karolherbst: One thing we might want to do is to push the CLC value and subtract in the shader in the hopes that NIR will see the add and subtract and delete them.
02:38 jenatali: Oh that's a good idea
02:38 jekstrand: Not that a single add matters....
02:38 jekstrand: But it'd be less noise in the shader
02:39 airlied: jenatali: oh hadn't noticed the spirv inconsistency yet
02:39 airlied: I wonder do we need nir enums to match the spirv ones
03:47 airlied: karolherbst, jenatali, jekstrand : so for order/format we probably need texture accessors as well
03:47 airlied: as image accessors
03:47 airlied: for readonly images
03:47 airlied: maybe just with clover
03:53 airlied: hmm not too sure how best to handle that yet
04:09 airlied: jekstrand: how to you intend to make image size work, if we are passing read only image down the texutre path
04:19 airlied: ah me kinda works it out
04:56 airlied: jenatali, jekstrand, karolherbst : okay my llvmpipe-cl-img-wip has tex op for the cl queries added
04:56 airlied: the piglit attributes test now passes with all of that mess on llvmpipe
06:28 jekstrand: airlied: For writeable images, you get image_size. For read-only, you should get tex_op_txs
06:30 jekstrand: airlied: On iris, we can't use txs for read-write or image_size for write-only for stupid binding-table segregation reasons. They map to the same HW op under the hood.
06:31 airlied: jekstrand: yeah so we have those other CL queries
06:31 airlied: which aren't size, but they need texture handling as well
06:31 airlied: at least if clover doesn't lower them all in advance
06:31 jekstrand: Yeah....
06:31 jekstrand: IMO, clover should lower them unless you really badly want them in the back-end for LLVMpipe
06:32 airlied: well they are there in a branch now, just so I can say I pass the test :-P
06:33 jekstrand: :P
06:33 airlied: but I'm happy for clover to take care of it, the extra overhead isn't goint o matter
06:33 jekstrand: Yeah, clover already has the plumbing to do this; we just need to add the params to the NIR and wire them through.
06:36 jekstrand: It also has plumbing to pass image sizes side-band but meh
08:16 DPA: Does anyone have an idea what could cause soemthing like this? https://gitlab.freedesktop.org/xorg/xserver/-/issues/1083
08:24 MrCooper: anholt: apt is C++, it depends on libstdc++6
08:25 MrCooper: for next time, adding "apt+" to the command line should show why it can't be kept
08:31 emersion: DPA: atomic is disabled in-kernel for Xorg
08:31 emersion: ie. `Option "Atomic" "On"` is a no-op
08:32 emersion: but you seem to have uncovered that already
08:53 DPA: emersion: Yes. It's just, I don't know why atomic makes it work on the external screen (dcss), nor why it doesn't for the lcd (mxsfb).
08:53 DPA: I'm not even sure if atomic has anything to do with it at all, or if it's something else entirely and it just makes it happen in that one case by chance...
08:53 DPA: And I don't know what to look for/at to figure out what's going on.
10:02 danvet_: sravn, btw does that dsi kmb driver look in any way familiar?
10:02 danvet_: I wouldn't be surprised if it's just a rewrapped ip block ...
10:02 danvet_:doesn't know unfortunately :-/
12:18 jenatali: airlied, jekstrand: Yeah we lower them to kernel arg accessors at the same time as we swap read-only image reads/size queries to tex ops, I suspect clover will want to do the same
12:26 daniels: anholt: try launching apt with -o "Debug::pkgProblemResolver=true"
12:27 daniels: MrCooper: oh, TIL 'apt+'
12:27 daniels: that's cute
12:27 MrCooper: yeah, there's correspondingly <package>-/_ for remove/purge
12:28 MrCooper: with the install command
12:29 MrCooper: I suspect apt got these from aptitude
12:46 daniels: yeah, I just didn't think of forcing apt to remain installed so you made the resolver explain itself
13:00 mareko: tarceri: have you thought of optimizing this data flow? uniform -> VS output -> FS input ===> uniform moved to FS and used directly
13:02 mareko: tarceri: if this is not something you want to do, can you please describe step-by-step how you would implement it?
14:07 karolherbst: nice :) local samplers work
14:07 jenatali: karolherbst: Nice :)
14:08 karolherbst: the patch is just ugly :D
14:08 karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/36a27d88fa95f83e54e0d6180533d039a98eca88
14:13 karolherbst: mhh.. linear is slightly broken
14:13 karolherbst: \o/
14:14 karolherbst: luxmark: Kernel compilation time: 5932ms :D
14:14 karolherbst: now it still segfaults, but that's my fault
14:14 jenatali: Only 6 seconds, not bad
14:14 karolherbst: "ERROR: unknown nir_op b2i8" :D
14:16 karolherbst: it works :O
14:16 jenatali: Awesome!
14:17 karolherbst: I just don't know if the output is correct
14:17 karolherbst: :D
14:18 karolherbst: https://i.imgur.com/PFP75Rk.png
14:18 karolherbst: doesn't look that bad though
14:18 karolherbst: ehh
14:18 karolherbst: Image validation: Failed (460652 different pixels, 71.98%) :D
14:22 karolherbst: ahh.. it can also render on CPU
14:22 karolherbst: let's see
14:22 karolherbst: ohh hey
14:22 karolherbst: it looks completely different :D
14:22 jenatali: That'll be fun to debug
14:23 karolherbst: I don't think so
14:23 jenatali:was being sarcastic :)
14:23 karolherbst: it should look like this: https://i.imgur.com/W3nyXgh.png
14:23 karolherbst: :D
14:23 karolherbst: not sure, but I think something is missing
14:23 jenatali: Heh you got the background right at least
14:24 karolherbst: lol
14:24 karolherbst: might be a static image
14:24 karolherbst: :D
14:25 karolherbst: I guess passing all image tests first is the goal :D
14:25 danvet_: robclark, do you want me to take a look at your dma_resv conversion?
14:25 jekstrand: karolherbst: You got luxmark to run???
14:25 karolherbst: luxmark 3, yes
14:25 robclark: danvet_: yeah, if you have time
14:26 karolherbst: jekstrand: pushed all I need into the MR
14:26 karolherbst: the inline sampler patch needs some real rework though I think...
14:30 karolherbst: mhhh
14:30 karolherbst: copy images is quite broken
14:30 karolherbst: FAILED 259 of 407 sub-tests.
14:32 karolherbst: mhh
14:32 karolherbst: seems like image arrays are a bit busted
14:40 danvet_: robclark, at a very high level (i.e. I didn't check the details, just the common trapdoors and stuff): lgtm
14:41 danvet_: replied on two that maybe justify a bit more discussion
14:45 danvet_: tzimmermann, https://paste.debian.net/1166837/ <- this is what you had in mind
14:45 tzimmermann: danvet, yes
14:45 tzimmermann: danvet_ ^
14:51 tzimmermann: IMHO at some point we should consider changing the default to cached mappings
14:54 danvet_: melissawen, thx for taking a look at my vkms patches
14:55 danvet_: melissawen, can you perhaps give them a spin when I send out v2 with cached mappings?
14:55 danvet_: iirc you had quite some luck with hitting corner cases in timings with the various tests
14:55 danvet_: so making sure that all still works on your machine would be good
14:55 danvet_: tzimmermann, thx
14:55 tzimmermann: sure
14:56 danvet_: tzimmermann, the more I'm looking at dma-api/coherency/caching topics
14:56 tzimmermann: i found that diffstat very motivating :)
14:56 danvet_: the more I like the approach of "a good pair of running shoes"
14:56 danvet_: yeah the helpers we have are epic nowadays
14:56 daniels: at last you won't run out of stuff to do
14:56 danvet_: it's reaaaaaaallllly nice
14:57 tzimmermann: "a good pair of running shoes"? i don't get the metaphor, sry lol
14:58 danvet_: for getting away really fast, really far
14:58 tzimmermann: :D
15:24 melissawen: danvet_, sure :)
16:09 jenatali: karolherbst: I can compile the kernels, but I just get black rendering for luxmark :(
16:09 jenatali: (For v3)
16:09 karolherbst: :/
16:15 karolherbst: ehh.. image array copuies break here :D
16:18 jenatali: I think this is going to have to wait until after I get back from vacation to really dig into
16:23 karolherbst: imirkin: is there a difference between copying 1darray textures vs 2d textures?
16:23 imirkin: define copying
16:23 karolherbst: ehhhh
16:24 imirkin: the layout in memory is different of course
16:24 karolherbst: "width0 = 652, height0 = 1, depth0 = 1, array_size = 1, format = PIPE_FORMAT_R8_SNORM, target = PIPE_TEXTURE_1D_ARRAY"
16:24 karolherbst: ...
16:24 karolherbst: but it wants to copy 48 array entries :)
16:24 imirkin: this is a 1d-array texture with array size 1
16:24 imirkin: so ... yeah. that won't work *too* well
16:24 karolherbst: :)
16:24 karolherbst: but it's fine if ny is 48, right?
16:24 karolherbst: (once the array_size is fixed)
16:24 imirkin: ny?
16:24 karolherbst: in the m2mf path
16:25 karolherbst: nvc0->m2mf_copy_rect(nvc0, &drect, &srect, nx, ny)
16:25 imirkin: oh. mmmm ... maybe.
16:25 imirkin: this is the sort of thing i hit randomly with values until the piglit passes.
16:25 karolherbst: well.. I'l see
16:25 karolherbst: yeah..
16:25 karolherbst: anyway.. first I should fix this array_size thing :)
16:26 imirkin: can't be helping
16:29 karolherbst: yeah.. I guess not
16:29 karolherbst: mhh
16:31 karolherbst: wondering if for arrays we need to copy each element?
16:32 imirkin: normally that's the approach, yea
16:32 karolherbst: okay
16:32 imirkin: but with 1d arrays perhaps we can cheat
16:32 karolherbst: maybe
16:32 imirkin: i forget precisely how they're laid out
16:32 karolherbst: no idea really
16:32 imirkin: but it should be achievable by setting an appropriate stride
16:33 karolherbst: trying to figure out what st/mesa does
16:33 karolherbst: depth = src->array_size;
16:33 karolherbst: so...
16:33 karolherbst: and then for (i = face; i < face + depth; i++) {
16:33 karolherbst: :)
16:33 karolherbst: so yeah, exactly like 3d
16:33 imirkin: at the mesa level, you can't cheat
16:33 imirkin: but at the driver level, you can
16:33 karolherbst: ahh sure
16:34 karolherbst: but at this point I am focusing on fixing clover
16:34 karolherbst: not nouveau
16:34 imirkin: oh ok. yes, you have to do it one slice at a time
16:34 jekstrand: layered rendering!
16:35 karolherbst: mhhh
16:35 karolherbst: clover just makes it very hard to fix
16:35 karolherbst: it doesn't layer at all :/
16:36 karolherbst: mhhh
16:57 karolherbst: imirkin: you know we have this depth handling in our nouveau code? I doubt gallium ever hits this :D
16:57 karolherbst: well.. except for clover
16:57 imirkin: dunno.
16:57 imirkin: the logic has also changed over time.
16:57 imirkin: (the logic in st/mesa)
16:57 karolherbst: st_texture_image_copy loops itself eg
16:57 imirkin: yeah, but there's other ways for this stuff to happen
16:58 karolherbst: I guess
16:59 imirkin: i forget exactly at this point
16:59 imirkin: but i also think there have been some changes to this logic from a st/mesa perspective over the eons
16:59 karolherbst: probably
16:59 karolherbst: anyway.. the 1d array still crashed my context :/
16:59 karolherbst: something is odd
17:00 imirkin: there's frequently confusion with 1d arrays about whether the array should go as "y" or "z"
17:00 karolherbst: yeah...
17:00 karolherbst: but I think for drivers it goes into z... maybe I need to read more code
17:00 imirkin: it should.
17:01 imirkin: but it didn't for a long time :)
17:01 karolherbst: ahh
17:01 imirkin: so clover could be broken
17:01 karolherbst: maybe something with the slices went wrong as well...
17:01 karolherbst: clover doesn't even support array images yet :p
17:01 imirkin: oh
17:01 imirkin: well then.
17:01 karolherbst: just trying to figure out what I have to fix
17:01 imirkin: does CL have them? (it must if you're talking about them...)
17:01 karolherbst: yeah
17:02 karolherbst: in 1.2
17:02 karolherbst: even 1D images are CL 1.2+
17:03 karolherbst: would be cool if we could ignore CL 1.2, but that's more or less the baseline most applications expect
17:03 imirkin: yeah, there's basically zero upside to 1D images
17:03 imirkin: in the presence of buffer-backed textures
17:04 karolherbst: ahh, sure
17:04 karolherbst: but CL has IMAGE1D_BUFFER :p
17:04 imirkin: i guess you get filtering, but is that really something you want with a 1D texture?
17:04 karolherbst: also 1.2
17:04 karolherbst: mhh
17:04 karolherbst: no clue?
17:04 karolherbst: the CTS tests that though
17:04 karolherbst: I think
17:04 karolherbst: but yeah.. fells a bit pointless
17:04 karolherbst: *feels
17:05 karolherbst: ehhh broke nouveau, now I need to reboot :/
17:36 jekstrand: dschuermann, bnieuwenhuizen: I think you've already found this out experimentally, but don't bother with Wave32.
17:36 jekstrand: I ran some statics today. It provably doesn't matter.
17:36 jekstrand: I'm planning to write a blog post explaining why.
17:51 dschuermann: jekstrand: what are you referring to? performance of wave32 vs 64?
17:51 jekstrand: dschuermann: yeah
18:10 anholt: MrCooper: one non-dev stashed in all the -devs. thanks!
20:19 pinchartl: opengl newbie question: do I understand correctly that GL_RGB has the same components order as DRM_FORMAT_BGR888 ?
20:21 imirkin: pinchartl: opengl does not specify component order
20:22 imirkin: at least not in the "format". it can be semi-specified in internal formats, iirc
20:22 jekstrand: It's always a bit loose in GL
20:23 jekstrand: With texture view, it might be observable, though
20:23 pinchartl: what about when creating a texture with glTexImage2D() ?
20:23 pinchartl: surely the component order for textures needs to be defined
20:24 pinchartl: (I forgot to mention this was related to textures, sorry)
20:25 jekstrand: pinchartl: old-school OpenGL is very careful to not specify basically anything about memory layout at all.
20:25 pinchartl: jekstrand: how can you load a texture from a file if you don't know in which order the components need to be presented ?
20:26 jekstrand: pinchartl: The order is well specified for CPU data in glTexImage2D etc. but not for how it's stored in the actual GPU-visible memory in the texture.
20:26 pinchartl: ok, makes sense
20:26 jekstrand: The driver is allowed to re-arrange it however they see fit on upload.
20:26 jekstrand: With DRM_FORMATs, however, that's supposed to be describing how the memory is layed out in a shared buffer.
20:27 jekstrand: What are you trying to do with DRM_FORMAT?
20:27 pinchartl: so to rephrase my question, if I set the format parameter to GL_RGB in glTexImage2D(), do I need to store R, G, B in that order as bytes (thus matching DRM_FORMAT_BGR888), or B, G, R (DRM_FORMAT_RGB888) ?
20:28 jekstrand: who is "I" here? Are you working on a driver or an app?
20:28 pinchartl: an app
20:28 jekstrand: If an app, how are you associating the texture with the GEM bo?
20:28 imirkin: pinchartl: glTexImage2D takes a format + type
20:28 pinchartl: it's not a GEM bo, it's a buffer coming from V4L2, I just happen to use DRM 4CCs in userspace
20:28 imirkin: which specifies the way the data is to be interpreted
20:28 imirkin: along with the packing
20:28 imirkin: and swap bytes modes.
20:29 jekstrand: pinchartl: Ok, then what API are you using to import the buffer?
20:29 imirkin: so you could e.g. have a GL_RGB + GL_UNSIGNED_INT format/type
20:29 jekstrand: pinchartl: Or are you just mapping it and passing that as the data parameter to glTexImage2D?
20:29 imirkin: and then each pixel better be 32 bits
20:29 pinchartl: I've read the glTexImage2D() documentation, and didn't find it clear on whether it expects GL_RGB to mean R byte at offset 0, G byte at offset 1, and B byte at offset 2, or 24-bit "RGB" integer stored in memory in CPU-endian :-S
20:29 imirkin: laid out as a packed integer, red in lowest bits iirc.
20:30 imirkin: pinchartl: it's all dependent on the format/type that are passed in
20:30 imirkin: as well as some other "global" settings
20:30 pinchartl: imirkin: GL_RGB + GL_UNSIGNED_BYTE
20:30 pinchartl: (if I understand you correctly)
20:30 imirkin: ok, so then i think it expects R, G, B as a sequence of bytes.
20:30 jekstrand: pinchartl: glTexImage2D with GL_RGB + GL_UNSIGNED_BYTE interprets the data as a uint8_t[]
20:31 pinchartl: I'm only referring to DRM_FORMAT_* as that's a well-defined memory order, what I'm really after is figuring out the order in my texture in memory
20:31 jekstrand: So R at byte i*3+0, G at i*3+1 and B at i*3+2
20:31 pinchartl: ok, thanks
20:31 imirkin: DRM_FORMAT_ are packed integer formats, so not compatible with GL_UNSIGNED_BYTE formats
20:31 pinchartl: that's exactly the answer I was looking for :-)
20:31 imirkin: (at least not directly compatible)
20:31 jekstrand: Yeah, the ancient question of packed vs. array formats. :-)
20:31 pinchartl: sorry for asking the question in a confusing way
20:31 Lyude: anyone know if james jones from nvidia is on IRC?
20:32 jekstrand: pinchartl: No worries. The moment someone says DRM_FORMAT, I assume they're importing a bo. :)
20:32 jekstrand: Lyude: jamesjones
20:32 jekstrand: Lyude: He doesn't typically hang around here but I think he's usually on freenode if you PM him
20:32 Lyude: ah cool, thanks!
20:33 pinchartl: jekstrand: that's the next step. at the moment I'm going through a CPU mapping, next I'll import a buffer through dmabuf (coming from V4L2)
20:34 jekstrand: pinchartl: Depending on your video device, that may or may not actually help anything. :-/ I suspect most capture devices are going to involve a CPU copy anyway.
20:34 jekstrand: Unless it's a decoder built into your GPU
20:38 airlied: danvet_, sravn : keembay dsi is in-house propreitary, not an ip block
20:42 pinchartl: jekstrand: even if the GPU uses system memory ?
20:42 jekstrand: pinchartl: That ones more interesting.
20:42 jekstrand: pinchartl: Depending on your usage, it may be faster to do a copy and get tiling.
20:42 jekstrand: Or it may be faster to use the in-memory thing.
20:43 jekstrand: pinchartl: Are you doing a lot of sampling from it or are you basically just sampling every pixel once?
20:43 pinchartl: I'm sampling every pixel once
20:43 pinchartl: with a shader to convert $camera_format to RGB
20:43 jekstrand: Ok, then using the original buffer directly on an integrated GPU should be faster
20:44 pinchartl: well, maybe that's lots of sampling if the image is then scaled, I'm not sure
20:44 pinchartl:is an opengl newbie
20:44 pinchartl: took me a day to write the shader to convert packed YUYV to RGB, as I had to sample manually in the shader
21:02 airlied: whomever is drm-misc-next-fixes can we get the igenic fix to me
21:02 airlied: asap
21:03 airlied: it's going to be mlankhost who isn't on irc right now isn't it :-P
21:40 Lyude:is resolving the current drm-tip conflict
21:40 Lyude: wait, no it's on drm-misc-next
21:41 Lyude: or no, drm-tip, misread oop
21:44 Lyude: but it doesn't look it was from my patch. mripard, could you take a look
22:08 tarceri: mareko: yes that has crossed my mind although I think I found it wasn't all that common. I believe it shouldn't be too difficult, you should be able to extend nir_link_opt_varyings() to do what you need
22:56 karolherbst: "std::string texture_data; " oh boy
22:58 Sachiel: ascii textures!
23:01 airlied:tries to get radeonsi nir cl path going again
23:03 karolherbst: &texture_data[0] on a std::vector.. alright...
23:03 karolherbst: or std::string
23:04 karolherbst: mhh
23:04 karolherbst: still something going wrong
23:04 airlied: of course radeonsi/llvm would really like to recreate the function, but we've lowered things to load_kernel_input
23:04 karolherbst: huh?
23:05 airlied: you have to build the llvm IR that the amdgpu compute kernel backends expects
23:05 airlied: so getting the calling convention right
23:07 karolherbst: ahh...
23:07 airlied: I suppose I can ask clover not to lower that for now
23:07 karolherbst: would be too easy if we could just control all of that :p
23:08 karolherbst: airlied: wait... llvm itself creates the wrapper stuff and everything?
23:08 airlied:controls it with a hammer
23:08 airlied: pretty much, they have a calling convention for the driver to put a bunch of stuff into a dispatch table
23:09 airlied: I may be able to workaround it and avoid some of it
23:10 airlied: just have to page it all back in
23:10 karolherbst: ehhh.. sounds terribly annoying
23:10 karolherbst: no idea why any of that is inside llvm :p
23:10 karolherbst: for me that sounds like belonging inside the runtime
23:11 jekstrand: airlied: Can you kick TheWearyGamer?
23:11 jekstrand: IRC is hard to read today. :)
23:12 Lyude: maybe he's just weary ;)
23:13 airlied: lets see if that works, I suck at irc
23:13 jekstrand:knows nothing about IRC
23:14 HdkR: That'll work
23:14 HdkR: Will prevent them from joining the channel. Just need to remember to remove it later
23:15 airlied: yeah it's a pity irc doesn't have timed or self removable bans
23:15 Lyude: it does
23:15 HdkR: irssi has the /knockout command but you need them to stay in the channel long enough to invoke it on the user :/
23:15 Lyude: freenode's ircd should support it via the akick command on chanserv
23:17 airlied: okay I've done that
23:18 airlied: let's see if it works or just makes more noise
23:19 Lyude: you can also add reasons btw
23:21 airlied: okay this time for sure :-P
23:27 karolherbst: ohhh
23:27 karolherbst: image fill works
23:27 karolherbst: just not for random region/origins
23:27 karolherbst: mhhh
23:27 karolherbst: the CTS is really terrible at reporting errors