00:01 karolherbst: yeah..
00:01 karolherbst: that gets me to pass the tests
00:02 airlied:has vague memories of rewriting those somewhere, but it was likely on an s390 I ran away from
00:05 karolherbst: airlied: with the x16 and x32 macros fixed: https://gist.github.com/karolherbst/a8843be303dac899ce39b38e295cc4d1
00:06 karolherbst: wondering why r16g16 is broken
00:11 karolherbst: ohhh, I think I know
00:11 karolherbst: some magic elsewhere
00:12 karolherbst: ahhhhh
00:13 karolherbst: imirkin: struct { u16, u16 } + memcpy :/
00:13 karolherbst: that is calling for trouble
00:14 karolherbst: ehh
00:14 karolherbst: and then again for r16g16b16
00:15 karolherbst: but then it's above 32 bit...
00:15 karolherbst: the heck
00:16 imirkin: but you bswap per-element
00:16 imirkin: but actually, hm
00:16 imirkin: ignore that comment
00:16 karolherbst: I removed the swapping
00:16 imirkin: right
00:16 karolherbst: I am wondering why does r16g16 break
00:16 karolherbst: but not the 1,3 or 4 channel variants
00:17 karolherbst: they have the same code, just different struct
00:17 karolherbst: maybe only memcpy up to 32 bit is weird
00:17 imirkin: and probably something else
00:17 karolherbst: and then it's all bytes?
00:17 imirkin: which is the thing causing the problem ;)
00:19 karolherbst: let's see what the gdb says
00:19 karolherbst: *gdb
00:19 karolherbst: the only annoying thing about s390x is, that you can't use gdb inside containers :/
00:19 karolherbst: well
00:19 karolherbst: paired with qemu-user
00:19 imirkin: wtf??
00:19 imirkin: oh
00:19 karolherbst: yeah...
00:20 karolherbst: and the s390x machine I have available is in boston
00:20 imirkin: there's no "gdb-server" type thing?
00:20 karolherbst: which is just annoying over ssh
00:20 karolherbst: imirkin: no ptrace
00:20 imirkin: right, i meant in qemu
00:20 karolherbst: yeah.. would have to start a proper VM
00:20 imirkin: k
00:20 karolherbst: which I have as well, but there things are just sloowwwwwww
00:21 imirkin: i don't know that much about it
00:21 imirkin: ssh could be fater =]
00:21 karolherbst: yeah
00:21 airlied:just used to ssh to the s390, and I've got much worse latency
00:21 karolherbst: it is
00:21 imirkin: airlied: but you're used to it :p
00:21 karolherbst: airlied: sure, that's what I end up doing
00:21 karolherbst: would have been nice to juse use qemu-user though :)
00:21 airlied:did try to install a local s390 vm once, and qemu chokes on boot of the installer
00:21 karolherbst: airlied: it works with fc33
00:22 karolherbst: fc32 had some weird issues when I tried
00:22 karolherbst: but a few reboot cycles made it work as well
00:22 karolherbst: anyway, seems like things slowly start to get in shape
01:02 karolherbst: ehhh.. crap
01:02 karolherbst: imirkin: I found it.. apparently if the block size is in 8/16/32 the struct stuff is skipped for some variants
01:02 karolherbst: so r16g16 does a 32 bit load with manual shifting
01:03 karolherbst: same for r8g8b8a8
01:03 karolherbst: and r8g8
01:03 karolherbst: and with that fixed only z24s8 is left
01:03 karolherbst: but maybe that gets fixed alongside...
01:04 karolherbst: anyway.. it's getting late
01:09 karolherbst: I am though wondering if we need to specify the "block" size in the table
01:09 karolherbst: dunno
05:13 airlied: imirkin, karolherbst : lols no sooner than I say screw BE/LE, someone pops up on twitter doing that https://twitter.com/jhamby/status/1330721179112357889
05:16 ccr: heh
05:19 imirkin: that guy would make more progress in #nouveau probably
05:19 imirkin: i definitely left a bunch of broken on there though ... i didn't have the heart to figure it all out
05:20 imirkin: (or maybe it was attention span? definitely something missing though.)
05:22 ccr: -EDONTCARE ?
05:22 imirkin: i tried. got too confused, esp around the GART vs VRAM data endianness contents
05:23 ccr: is it even possible to test these things without appropriate hardware, e.g. with using Qemu emulating foreign endianess CPU host?
05:25 imirkin: sure - you could set up a qemu instance, and then do pci passthrough with a regular GPU for it
05:25 imirkin: i never subjected myself to such horrors though
05:34 ccr:nods
05:40 i-garrison: imirkin: BE arch testing of x11 was my primary target in improving qemu 15 year back, ppc and sparcv9, how can you miss that opportunity now :)
05:40 imirkin: i-garrison: when you add hardware to the mix ... sorry
05:41 imirkin: i don't even know if the pci passthrough would work
05:41 imirkin: it theoretically should, but ... in practice ... who knows
05:43 i-garrison: imirkin: it would only take a few chats on their #qemu to figure out but looks like it is "yes" https://lists.gnu.org/archive/html/qemu-ppc/2017-03/msg00270.html
05:44 imirkin: i-garrison: that appears to be about native qemu
05:44 imirkin: not soft-mmu
05:45 imirkin: anyways ... unfortunately my time for such esoteric pursuits is fairly low these days =/
07:46 mareko: robclark: what's more important for freedreno right now? improving CPU performance or GPU performance?
07:47 karolherbst: airlied: yeah.. just noticed, but the bugs I saw in firefox are definetly not caused by mesa :p
07:47 karolherbst: or at least... probably note
07:47 karolherbst: *not
07:47 karolherbst: wait....
08:05 mareko: robclark: and Vulkan or GLES?
08:31 tzimmermann: mripard, sravn, may I ask you for a review of https://patchwork.freedesktop.org/series/83918/ and https://patchwork.freedesktop.org/series/83959/ ?
08:52 mripard: tzimmermann: a-b for both
08:53 tzimmermann: mripard, both series?
08:54 tzimmermann: mripard, can you send this to the mailing list for reference?
09:14 MrCooper: karolherbst imirkin: I suspect packed formats generally need both endianness variants, possibly with CPU native order as default
09:14 karolherbst: MrCooper: yeah.. atm I try to fix it all up
09:14 karolherbst: the tests and the code
09:14 karolherbst: I think it's all confused from multiple ends
09:15 MrCooper: probably :)
09:15 karolherbst: nice! my changes don't break x64
09:16 karolherbst: MrCooper: that's what I have atm: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/afcee5dd72be7b7901c2ae97b7e7190126e80ace
09:16 karolherbst: fixes almost all format tests on s390x
09:16 karolherbst: and the change even makes sense
09:20 mripard: tzimmermann: done :)
09:20 tzimmermann: thanks!
13:02 karolherbst: mhhh.. is L8A8 considered to be a "packed" format?
13:03 pq: karolherbst, in what format enumeration?
13:03 karolherbst: PIPE_FORMAT_L8A8_UNORM
13:03 pq: no idea
13:03 karolherbst: yeah..
13:03 karolherbst: it feels like an unpacked one though
13:03 karolherbst: 2 8 bit channels
13:03 karolherbst: atm I considere anything packed with channels not in (8, 16, 32) and having channels of different sizes
13:04 pq: DRM_FORMAT_ does not have a packed/unpacked difference, they are all bits of a word.
13:04 karolherbst: and that works quite well for BE support
13:04 karolherbst: ahh
13:05 pq: karolherbst, maybe cross-check with https://afrantzis.com/pixel-format-guide/ and poke alf if anything seems inconsistent.
13:06 pq: though doesn't seem it has mesa internal format enums
13:06 karolherbst: u_format_test passing on s390x _and_ x86_64 now :)
13:07 karolherbst: pq: my current plan looks like this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7689/diffs
13:08 pq: sorry, I've been told to stay away from anything related pixel formats on BE :-P
13:08 karolherbst: :D
13:08 karolherbst: why though?
13:08 pq: I should have better ways to spend my time
13:09 karolherbst: ah
13:09 karolherbst: I get paid for doing it, so...
13:09 pq: I get paid too, but *not* for that :-)
13:09 karolherbst: but I thought when I do it, I make the life easier for everybody else as well :)
13:09 karolherbst: like removing this silly "be" stuff from the u_format.csv file
13:10 pq: we have this fun problem in Wayland that we don't actually know what the oldest pixel formats defined in the protocol should be on BE
13:11 karolherbst: mhhh
13:11 emersion: do we?
13:11 emersion: isn't it the same as drm_fourcc.h?
13:11 pq: since they were picked as "what does Cairo support", then we went with "just mirror the DRM format list"
13:11 karolherbst: pq: my goal is, that people have to stop thinking about BE format alltogether
13:11 emersion: hm
13:11 karolherbst: because the moment you have to treat BE differently you already lost
13:11 pq: but Cairo uses CPU-endia while DRM uses little-endian encoding
13:11 emersion: didn't know that stemmed from cairo
13:12 karolherbst: pq: ohh, interesting
13:12 pq: emersion, well, it was very convenient I suppose
13:12 karolherbst: so DRM formats are all little endian?
13:12 emersion: yes
13:12 karolherbst: ahhh
13:12 karolherbst: okay, cool
13:12 pq: karolherbst, yes, doesn't it say so on every single line on drm_fourcc.h?
13:12 karolherbst: didn't look into there yet
13:13 karolherbst: but that just means we have to map DRM and GL formats differently on BE and that's essentially it, no?
13:13 pq: I bet many other people didn't realize it either
13:13 emersion: GL is always BE, right?
13:13 karolherbst: GL is nothing
13:13 emersion: ah, as expected
13:13 karolherbst: so I make it all "native"
13:13 karolherbst: makes the code less ugly
13:13 karolherbst: and then we just deal with the differences when it actually matters
13:14 karolherbst: instead of throwing conversions around
13:14 emersion: indeed it seems like opengl is native https://afrantzis.com/pixel-format-guide/opengl.html
13:14 pq: emersion, the problem in Wayland is, if we go by the DRM formats, then on BE Cairo cannot use those two "minimum supported" xrgb/argb formats.
13:14 karolherbst: this optional BE stuff in u_format.csv is just a huge enough hint towards that all of this is just very confused
13:14 emersion: > GL_RGBA with GL_UNSIGNED_BYTE
13:14 emersion: > This combination specifies a pixel format laid out in memory as the bytes R, G, B, A (R at the lowest address, A at the highest)
13:15 emersion: i guess wlroots gets it wrong then
13:15 karolherbst: emersion: nope, this is with BYTE
13:15 karolherbst: so yeah, that's of course LE
13:15 karolherbst: I guess?
13:15 karolherbst: can you do GL_RGBA with GL_UNSIGNED_INT?
13:16 pq: karolherbst, well, rgb565 is going to be interesting to map between GL and DRM...
13:16 emersion: GL_RGBA+GL_UNSIGNED_BYTE maps to DRM_FORMAT_ABGR8888 on LE
13:16 emersion: iirc
13:16 karolherbst: pq: yep....
13:16 karolherbst: pq: guess what triggered me looking into it
13:16 karolherbst: X with 16 bit colors being broken over VNC :)
13:16 pq: karolherbst, all DRM formats are little-endian, unless you bitwise-or with DRM_FORMAT_BIGENDIAN, but no-one ever used that even on BE...
13:17 karolherbst: heh
13:17 karolherbst: but yeah, that stuff behind the link makes a lot of sense
13:18 karolherbst: you specify the "element" size and format of your data and the GL impl has to make it work
13:18 karolherbst: I could imagine that the size stuff also doesn't really work all that well on BE atm
13:19 karolherbst: anyway.. "packed" I think in GL is everything which requires a special "size" type
13:19 karolherbst: like GL_UNSIGNED_INT_2_10_10_10_REV
13:19 pq: weston has a pixel format mapping table between DRM and GL too, and it too has some.... wishful thinking for BE
13:19 karolherbst: or uses GL_UNSIGNED_INT_8_8_8_8
13:20 pq: packed is that, yeah
13:22 karolherbst: the problem starts when you look at a RGBA8888 format
13:22 karolherbst: and you can use it either way
13:22 karolherbst: packed or unpacked
13:22 karolherbst: so when the client provides data we might have to blit into whatever we store the data internally
13:22 karolherbst: but I am not that far yet
13:23 karolherbst: it's just nice that on LE none of that matters
13:25 pq: "nice"... meaning it's totally inconsistent everywhere :-D
13:25 karolherbst: :D
13:25 karolherbst: right
13:25 karolherbst: but I wouldn't care about actual GPU support on BE systems anyway
13:25 pq: from apps through toolkits and libs all the way down to the kernel device drivers
13:26 karolherbst: there is nearly to no support already
13:26 karolherbst: *close to none
13:26 karolherbst: so at this point we really can only get llvmpipe to work correctly
13:26 karolherbst: and everything else is just best effort
13:26 karolherbst: but getting llvmpipe to work should be the main focus
13:26 karolherbst: and if we have to fix drm to make it work with our final solution, so be it
13:27 karolherbst: anyway, the u_format_tests.c file makes finally sense I think :)
13:27 karolherbst: it was very inconsistent
15:26 Venemo: do we have a NIR helper which tells whether an opcode is integer or not?
15:37 MrCooper: emersion: GL_UNSIGNED_BYTE are array formats, endianness has no meaning for those (only for packed formats)
15:37 emersion: MrCooper: ah! my code is fine then :)
15:37 emersion: i guess i haven't read the page in detail
15:38 karolherbst: MrCooper: and what if you use GL_UNSIGNED_SHORT for a format with 8 bit channels?
15:38 MrCooper: emersion: assuming the code doesn't access pixels with such formats as multi-byte values
15:38 emersion: said code maps GL_UNSIGNED_BYTE+GL_RGBA to a DRM_FORMAT
15:39 emersion: DRM_FORMAT is always LE, and GL_UNSIGNED_BYTE makes the GL format independant of the endianness
15:39 emersion: so should be all right
15:39 MrCooper: karolherbst: is that even legal? :) Not sure offhand if so, but I'd assume it's subject to endianness
15:40 karolherbst: MrCooper: not sure if it's legal actually.. but you could also use INT for a 32 bit format
15:40 karolherbst: so...
15:40 karolherbst: but yeah.. I think using BYTE for DRM is probably the path forward
15:40 karolherbst: just really messy what to do about 565 formats
15:40 MrCooper: assuming you mean GL_UNSIGNED_INT_8_8_8_8, that's a packed format and subject to endianness
15:41 karolherbst: GL_INT?
15:41 MrCooper: you mean each component is a 32-bit int?
15:41 karolherbst: nope
15:41 karolherbst: ohh wait..
15:42 karolherbst: ahh right ... GL isn't that specific
15:42 MrCooper: yeah, it's only 100% specific ;)
15:43 karolherbst: although there is GL_RGB8 .. no idea what it is used for though
15:43 MrCooper: emersion: that sounds good, but doesn't answer the question if the code ever reads/writes pixels as multi-byte words
15:44 emersion: which code?
15:44 MrCooper: the code which reads/writes pixel data
15:44 emersion: i have no such code
15:44 emersion: data comes from a wayland client
15:45 karolherbst: ahh okay.. so one can specify the internal format of a texture in glTexImage, but the provided data are declared with base formats + data type
15:45 MrCooper: presumably the data was written by some code :)
15:45 emersion: lol
15:45 emersion: indeed. could come from many sources: hand-written loop, cairo, pixman, etc
15:46 emersion: libpng, libjpeg
15:46 MrCooper: sreiously though, sounds fine then
15:46 emersion: :P
15:46 karolherbst: so one could do GL_RGB8, GL_RGBA, GL_INT, and internally we would have to down sample from 32 bit channels to 8 bit ones, correct?
15:46 karolherbst: uhm.. blit I guess
15:49 robclark: mareko: at this point, I'd say gles and fixing last couple weird bugs and pedantic cases (like shadertoy front page isn't great for shoving all the shader compile thru one gpu-process thread, etc)
15:50 imirkin: karolherbst: PIPE_FORMAT_* >= 8 is array. others are packed. so L8A8 would be array.
15:50 robclark: mareko: it did occur to me that we can try to hack valgrind into deqp-runner.sh.. at this point I'm starting to suspect the issue you are hitting is compiler version related (otherwise I should be seeing it locally)
15:50 karolherbst: imirkin: yeah, makes sense
15:50 imirkin: karolherbst: note that this logic does not carry over to other things.
15:50 imirkin: i.e. non-PIPE_FORMAT things
15:50 karolherbst: right
15:50 karolherbst: I was just thinking from a u_format_tests.c perspective
15:51 imirkin: karolherbst: there are also defines for PIPE_FORMAT_RGBA8888 which goes to opposites for big and little endian
15:51 karolherbst: yeah...
15:51 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/blob/09ae283eb7c5c742b9ad27cf4101f742e9e0be7c/src/util/format/u_format_tests.c is what I have now
15:51 imirkin: can't look now, but it's a big can of worms you've opened :)
15:51 karolherbst: and was wondering if it's all "correct" now or if I still messed up
15:51 karolherbst: :D
15:51 karolherbst: well.. got llvm regressions...
15:52 karolherbst: but only with PIPE_FORMAT_A8R8G8B8_UNORM
15:52 karolherbst: everything else is fine...
15:52 karolherbst: uhm
15:52 karolherbst: llvmpipe
15:52 karolherbst: no.. actually PIPE_FORMAT_X8R8G8B8_UNORM
15:53 imirkin: i.e. BGRX in LE and XRGB in BE
15:53 karolherbst: imirkin: anyway, the plan is to fix it once for real so that nobody else has to go through that
15:53 imirkin: could be speical-cased somewhere (incorrectly)
15:53 karolherbst: probably...
15:53 robclark:wonders if anyone has just considered disabling all the hard formats on BE?
15:53 karolherbst: but I only touched code affecting BE
15:53 karolherbst: and the test
15:53 karolherbst: robclark: I got u_format_test to pass
15:54 karolherbst: like completely
15:54 karolherbst: it's not that hard, code is just very confused
15:54 karolherbst: and I think most attempts were just "wrong"
15:54 robclark: oh, ok.. seems like way more effort than BE is worth, but ok
15:54 karolherbst: especially this "BE" order in u_format.csv is all bonkers
15:55 karolherbst: robclark: thing is.. fixing this also makes the general code easier
15:55 karolherbst: as the "fixes" I did was mostly to remove stuff
15:55 karolherbst: :D
15:55 karolherbst: anyway
15:55 karolherbst: llvmpipe fails with some 1 vs -1 error
15:55 karolherbst: something odd
15:56 pq: karolherbst, want to check why those pieces you removed were added originally to see what other software you may need to fix? :-P
15:57 karolherbst: pq: yeah.. that's probably the annoying part
15:58 karolherbst: but afaik I don't regress those things
15:58 karolherbst: I hope at least...
16:25 karolherbst: mhhh util_format_description.is_bitmask
16:29 karolherbst: this is annoying...
16:30 karolherbst: I think I finally understand why the confusion came around...
16:30 karolherbst: that's super annoying
16:30 karolherbst: util_format_r8sg8sb8ux8u_norm_fetch_rgba for instance.. we have this "fast path" to use bitmask instead of the struct to load data
16:30 karolherbst: but that toally doesn't work on BE
16:31 karolherbst: it's bytes, so the order in memory doesn't matter
16:31 karolherbst: but
16:31 karolherbst: we load a 32 bit value, swapping the values around
16:31 karolherbst: and of course that leads to the channels being in the wrong order
16:32 karolherbst: but
16:32 karolherbst: the tests actually specify 32 bit values
16:32 karolherbst: so this got never caught
16:32 karolherbst: the test does use packed values for packed formats though
16:32 karolherbst: hence the "BE order" inside the csv
16:33 karolherbst: but I think it's even worse
17:23 robclark: MrCooper, eric_engestrom, hmm, is apt/apt-get somehow removed from the baremetal container? I was trying to do a quick hack to pull in valgrind for an issue that I can't reproduce locally (maybe different compiler version compared to what is used in CI?).. but seems like apt/apt-get does not exist?
17:24 MrCooper:hasn't done anything with baremetal containers
17:32 jekstrand: cmarcelo: I put in a SQUASH patch to make review easier. I'll squash before assigning marge.
17:33 cmarcelo: ack
17:34 MrCooper: robclark: that said, without seeing the error, one generally needs to run "apt-get update" first in a container
17:35 robclark: https://gitlab.freedesktop.org/robclark/mesa/-/jobs/5761241#L1302
17:35 jekstrand: cmarcelo: I'm running the compiler MR through Jenkins right now and will merge a bunch of it once that's green.
17:35 jekstrand: cmarcelo: In particular, I need the genxml stuff for other MRs.
17:36 jekstrand: pendingchaos: What's the status of the NIR intrinsic builders MR?
17:36 jekstrand: pendingchaos: Sorry I've been ignoring it.
17:36 pendingchaos: I think it's just waiting for review
17:37 jekstrand: Ok. I'll see if I can review today.
18:03 hakzsam: dcbaker[m]: can you please backport https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7513 to 20.3?
18:06 dcbaker[m]: hakzsam: done. it's the top commit on the staging/20.3 branch
18:06 hakzsam: thanks!
18:16 danvet: glisse, did you see the discussion around ttm hugepmd support and how it's (ab)using devmap?
18:16 danvet: I wonder whether we need to revert or not :-/
18:19 dcbaker[m]: np
18:22 glisse: danvet: no, i haven't followed that
18:24 danvet: glisse, https://lore.kernel.org/dri-devel/504d77b87c81b7027157e0c7b5286e17123c59d9.camel@linux.intel.com/
18:24 danvet: is kinda where it died out
18:24 danvet: I think would be good if you can take a look
18:38 glisse: danvet: ok so gup_fast must never succed om mmap of device file
18:38 glisse: if it is broken then anything that break it must be reverted
18:39 glisse: but ttm should be fine with special pte
18:39 glisse: at least on x86 and ppc, i am forgetting the status of that on arm
18:39 danvet: glisse, yeah for normal pages it's all fine
18:39 danvet: because special pte
18:39 danvet: but ttm also support hugepmd entries for device mmap
18:40 danvet: and that "works" because it marks them up as PFN_DEVMAP
18:40 glisse: yeah that the one thing i must investigate how Thomas implemented it
18:40 danvet: it looks a bit like abuse, but I also think it filters out gup fully
18:44 glisse: yeah need to dig that up
18:44 glisse: my meal is burning :)
19:21 lrusak: when uploading a egl image with format DRM_FORMAT_GR1616 how does that work internally? What is the GL texture format and internal format?
19:46 mareko: robclark: the issue I'm hitting is due to mesa_to_tgsi not handling NumParameters < NumParameterValues correctly
19:46 mareko: robclark: i.e. I need to fix multi-slot params there
19:48 zmike: mareko: can you eyeball that shader runner float/double MR again if you get time?
19:49 lrusak: emersion, do you know the answer to my question above?
19:50 robclark: mareko: ahh, ok.. my attempt to add valgrind to CI didn't go so well, so glad you at least know what is going on.. a bit odd that I wasn't hitting that w/ local runs of deqp
19:54 mareko: zmike: which one?
19:54 zmike: mareko: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/400
20:25 jenatali: Out of curiosity, is there some kind of bar for adding wraps? I'm looking at getting our D3D driver building for WSL and I'm going to need to pull in our headers, trying to figure out the best way to set that up
20:26 dcbaker[m]: For anything that a Linux distro needs to build, there's going to be pushback to requiring a wrap
20:26 dcbaker[m]: for anything that's just for windows, I don't think anyone cares
20:26 jenatali: Makes sense
20:28 jenatali: I could see a potential (distant) future where including the d3d12 driver for a distro might make sense, to have built-in acceleration for a VM with our paravirtualization driver, but I don't see that happening anytime soon
20:53 karolherbst: jenatali: somebody from vmware mentioned they are working on making their d3d frontend available
20:53 jenatali: karolherbst: Oh, cool, I hadn't heard that
20:54 karolherbst: yeah.. it was some comment on an MR
20:54 karolherbst: I think if we have two drivers making use of it it might make sense to merge some stuff or do it the proper way or something.. dunno
20:55 karolherbst: although I think it's mainly the other way around
20:55 karolherbst: but who knows
20:59 jenatali: I suspect there'll be very little overlap - we're in the process of getting an MIT-licensed repo set up to host d3d12-related headers, but we're not currently bringing d3d11 or older out of the SDK license
21:01 Lyude: :(
21:02 jenatali: Yeah, I know
21:09 Lyude: thanks for trying at least! :)
21:12 airlied: jekstrand: naggy printf mcnaggy nag
21:29 jekstrand: airlied: Yeah....