04:12 sumits: sravn, thanks much! :)
07:44 MrCooper: imirkin_: -amdgpu & -ati do
08:23 pq: Lyude, FYI: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_631650 talks about monitor brightness control under "EDR".
08:47 pq: imirkin_, interesting. Combined with DRM fbdev helpers, I suppose that could be quite a surprise to fbdev using userspace. But I suppose no-one hit that case.
09:25 rendermag: well well karolherbst: your utter poopspam has been noticed and registered, for more than 7years..contentless incoherent poop of yours. While i have been talking pretty cohrently how things actually work , yeah that for years, and you keep pooping as of today to the main channels, when the rebelling hits the peak, do you think your boomerang hits me somehow or will it cut your fingers instead?
09:26 karolherbst: *sigh*
09:27 rendermag: karolherbst: do you honestly think with your pathetic and recognizable framing, i could get more hurt than i allready have gotten, and do you think i wont stand up for myself, if i am pushed to the corner like an infetcted dog_
09:27 rendermag: ?
09:27 rendermag: i have piles of fans too, no one likes what is going on
09:30 rendermag: currently it much looks like, i am collecting voluntary torturing suggestions from others. For the reason cause i lost a lot of my freedom, due to people chring me based of zero evidence against me, you know this is crazy, someone needs to straighten up, and this is not me.
09:31 rendermag: I never really figured out what research is being done about me, cause this predictive programming to stop me, was executed quite a long time, allready 18yers old i was crippled.
09:32 rendermag: how can i during those days as primary suspect was involved in some gang stuff, it is beyond me really, total setup.
09:33 rendermag: people come out with technologies to support my innocence or prove, this is little bit overkill, you never find any evidence to support your setups.
09:33 rendermag: you find evidence to your paranoia and hallucinations only.
09:35 rendermag: so 18 years old when 3-4 years it was combined before how to injure me when they get chanches, and i was slammed into taking on a surgery finally, for me the conspiration is 25years old, and executed based of brain pictures or god knows what during childhood, with zero evidence whatsoever.
09:38 rendermag: you have acitivty that points to very common ones to big fellons, where 3years i was researched before the lockup i was under cameras drinking everyday, and after doing my time 3years under cameras drinking
09:38 rendermag: what is that you are hoping to dig up or once more predict?
09:39 swivel:grabs the popcorn
09:39 rendermag: that maybe i executed in uknown place some murders or murdereous events like a shitbag and also without any reason etc. just because ia m a lunatic right?
09:40 rendermag: maybe as 14years old did some gang murders, this is what i hear on the streets.
09:41 rendermag: i was trining every day then , and i was at one stage in the youth team doing especially well, when i stopped
09:41 rendermag: i did not even have real time to deal with such things what they research about me
09:42 rendermag: however people i have seen by a fluke once, RIP the dead gangsters, yea were allegedly involved in smuggling very much expensie metal to different countries, at least it was registered.
09:42 rendermag: And talks about on the streets, which is all i know about them, they were involved in bad things.
09:48 danvet_: thx
09:49 danvet_: pq, sry I made a bit a mess with my replies :-/
09:49 danvet_: gitlab edit button would be useful
09:49 pq: it has an edit button
09:52 pq: ah, email, no worries
09:53 pq: danvet_, good point about the threads, a lot less to think about.
10:10 danvet_: daniels, https://paste.debian.net/1164401/ good enough?
10:10 danvet_: good news is that this doesn't break intel-gfx-ci
10:10 danvet_: so at least i915.ko is following this rule
10:10 danvet_: no idea which other driver is busted
10:12 pq: danvet_, the fixme comment still talks about affectec, not busy mask.
10:12 danvet_: pq, I'm pretty sure you want affected, not busy
10:12 danvet_: see my first reply
10:12 danvet_: busy you can always compute yourself in userspace
10:13 danvet_: since it's the subset of affected which have a drm_event pending
10:13 danvet_: and since you now get affected, you can perfectly keep track of that, even for crtc where the kernel added the commit/event on its own
10:13 pq: I can't compute that
10:14 danvet_: so the busy set you want is the set of crtc that would cause an EBUSY if you'd commit this, right?
10:14 pq: the whole point is to detect userspace errors, so if I am submitting a modetset on a CRTC that is already busy, by code is obviously broken as it tells me the CRTC is not busy
10:14 danvet_: now I'm confused
10:15 pq: the point of EBUSY is to indicate userspace bugs, right?
10:15 danvet_: yeah
10:15 danvet_: except userspace doesn't know about all the EBUSY sources, unforunately
10:15 danvet_: and I think passing affected_crtc mask back will give userspace enough information to know again all EBUSY sources
10:16 danvet_: so you can go back to unconditional assert if you get an EBUSY at commit time
10:16 pq: so if the kernel does not tell me what CRTC is actually busy when it returns EBUSY, I cannot look it up my userspace state either, because my userspace state is already broken since I am attempting a modeset on the busy CRTC itself.
10:16 danvet_: nah, that's not what's happening here
10:16 danvet_: from a userspace pov you're doing everything correct
10:16 pq: no, but it's a case still
10:16 danvet_: and you still get an EBUSY
10:17 danvet_: so affected_crtc will allow you to catch these
10:17 danvet_: without this EBUSY is fairly useless (at least if you want to pipeline modeset changes as nonblocking commits)
10:17 danvet_: so fixing that is step one
10:18 danvet_: so maybe Im missing your point, and you want this busy mask for some debug stuff?
10:18 pq: ok, let's say I get EBUSY on modesetting CRTC A, and I get affected CRTC mask saying A, B, C. To my own bookkeeping, A is not busy, B is not busy, and C is not busy. Where is my bug?
10:18 danvet_: maybe as step two later on
10:18 danvet_: you missed an affected_crtc from a previous commit
10:19 MrCooper: pq: in your bookkeeping? :)
10:19 pq: maybe that is the bug, maybe not
10:19 danvet_: so without affected_crtc you have no idea
10:19 pq: it would help to know which CRTCs the kernel considered busy, that's all I'm saying
10:19 danvet_: ah
10:19 danvet_: well we can throw a drm_debug in there somewhere
10:19 danvet_: it's probably there already
10:20 danvet_: but yeah if we assume you've already taking affected_crtc into account
10:20 danvet_: there's a bug somewhere
10:20 pq: ok, I can get that with the DRM fligth recorder then ;-)
10:20 danvet_: neither kernel nor compositor can tell you where though, that's what humans are for
10:20 danvet_: yeah
10:20 danvet_: pq, if you want a fallback, do a full stall in your compositor, and a full blocking modeset across all crtc
10:21 danvet_: that should get any lost ebusy sorted and reset
10:21 danvet_: if that doesn't help, the kernel driver is dead :-)
10:21 pq: well like daniels said, I we don't want to paper over any EBUSY
10:22 danvet_: hm we don't have any drm_debug for ebusy
10:22 pq: you did bring up a good point here that affected crtc mask is still needed, busy mask is not enough. That was my mistake.
10:23 danvet_: yeah and assuming your userspace book-keeping is solid, you can compute the busy mask from the affected mask
10:23 danvet_: but also we need more drm debug I think for ebusy
10:23 danvet_: I'll do another patch for this
10:23 pq: awesome
10:23 pq: thanks
10:23 danvet_: and then we longingly look at seanpaul to get that drm crash recorder going :-)
10:23 danvet_: maybe siqueira can help out to make that happen
10:28 danvet_: pq, https://paste.debian.net/1164403/ good enough output?
10:29 danvet_: note that the async_check is for async commits only, atm all entirely internal
10:29 danvet_: and does a transparent fallback to a blocking one iirc
10:29 danvet_: plus it's not even exposed to userspace through the atomic ioctl
10:32 seanpaul: danvet_: just needs review
10:42 danvet_: vsyrjala, another option would be if we just force the EINVAL
10:42 danvet_: if affected_crtc is bigger than requested and modeset not set
10:42 danvet_: but that's kinda nasty, since drivers might want to make a better choice
10:44 danvet_: doing that just for plane changes is rather nasty
10:45 vsyrjala: not sure it's any more nasty than an extra vblank wait (which we have many)
10:45 danvet_: well those are maybe also not great
10:46 vsyrjala: sadly unavoidable, thanks hw
10:46 danvet_: I think they're somewhat ok for idle->busy since there's really not much you can do for self-refresh with link training
10:46 danvet_: yeah
10:46 danvet_: but pulling random other hw in is a bit too nasty
10:46 danvet_: especially since that can result in dropped frames there (well pretty much will)
10:46 danvet_: whereas some vblank wait on a single crtc is more like "oh well it's soft rt, we got unlucky"
10:47 danvet_: which compositors kinda need to deal with anyway
10:47 danvet_: vsyrjala, I also wonder whether we could go up without adding other stuff
10:48 danvet_: and force the sync only if we reduce bw allocation
10:48 danvet_: or whether just tracking a drm_crtc_commit on the global state is sufficient
10:50 vsyrjala: we do try to avoid eg. cdclk stuff if it doesn't have to go up. dunno if we want to start playing similar tricks w/ sagv
10:50 danvet_: vsyrjala, do we have a similar problem on pre-gen12=
10:51 danvet_: well going up should be ok, as long as we sync with the previous "going up" thing
10:51 danvet_: I think
10:51 danvet_: and then just only ever go down when modesetting
10:51 pq: danvet_, does DRM_DEBUG_ATOMIC print which device it's on?
10:52 danvet_: pq, not sure, but this file isn't converted over to the new stuff yet anyway
10:54 danvet_: vsyrjala, we also should be able to go down if there's only a single crtc enabled
10:54 danvet_: and that's kinda the case that matters
10:56 pq: danvet_, otherwise the messages look like a good addition to me.
10:56 hansg: Is anyone else also having ssh access-denied issues for git@gitlab.freedesktop.org ?
10:57 pq: hansg, seems to work for me
10:58 hansg: Weird, I'm pretty sure it is not my local setup as the same ssh key does work when doing "git remote update" from e.g. gitlab.gnome.org
10:58 hansg: Anyways time to do some debugging I guess
10:58 danvet_: hansg, #freedesktop for server issues
10:59 hansg: danvet_, ok
11:15 daniels: danvet_: re debug output, yeah that's what I meant - the WARN text is nice, but having it as debug output even if allow_modeset would be really helpful
11:32 danvet_: daniels, oh you mean unconditionally?
11:49 pq: hansg, wait, what did you mean with ssh access? I just tried git remote update
11:49 hansg: pq, that is what I was doing too, but with a ssh (git@gitlab.freedesktop.org:plymouth/plymouth.git) URL as origin
11:50 pq: oh, yeah, exactly that but for weston repo worked for me
11:50 hansg: pq, this is probably ssh client version related, "ssh -V" for me gives: "OpenSSH_8.3p1, OpenSSL 1.1.1g FIPS 21 Apr 2020"
11:51 hansg: Anyways we are looking into this in #freedesktop now
11:55 daniels: danvet_: right, so DRM_DEBUG() if affected_crtc != requested_crtc (userspace hitting API weirdness which is good to know about when debugging), and further WARN_ON if that && !allow_modeset (KMS driver is objectively buggy)
12:07 shfbsdbvf: Hi, how can I report bug in radv? I can't find related subproject in this list https://gitlab.freedesktop.org/mesa
12:08 hakzsam: shfbsdbvf: fill an issue here https://gitlab.freedesktop.org/mesa/mesa/-/issues
12:14 shfbsdbvf: hakzsam: thanks :)
12:23 DPA: I'm getting a 404 for https://gitlab.freedesktop.org/mesa/mesa
12:25 daniels: DPA: known, working on it
12:50 danvet_: vsyrjala, so marius vlad says kbl also hits the warning
12:50 danvet_: but the code you pointed out is gen12+ afaict?
12:55 vsyrjala: sagv is gen9+. details are just a bit different between those two
12:55 vsyrjala: and cdclk is bdw+
13:05 danvet_: vsyrjala, but cdclk should be for modeset only?
13:09 vsyrjala: mostly. there are a few cases where we can do a cdclk bump without a modeset. currently only works on bxt
13:09 vsyrjala: and glk
13:12 daniels: all of GitLab is currently down, will be back in 10-15min
13:20 imirkin_: MrCooper: hah, so nouveau is the odd man out in that respect. oh well - no one's complained about it yet, so i'm not going to be looking to tack that on :)
13:21 imirkin_: pq: well, you can set the preferred bpp explicitly too (not that I remember how). but by default, yeah, you get a C8 buffer. never thought about the fbdev usage case for that. "too bad"?
13:42 pq: imirkin_, I agree, fbdev is too bad. ;-)
13:43 imirkin_: "get more vram"?
13:43 imirkin_: or if they really want it, they can force it
13:44 pq: the only real risk is someone screams "kernel regressed userspace", but apparently it didn't happen
13:44 imirkin_: when?
13:44 pq: whenever nouveau started using C8
13:45 imirkin_: afaik that's been there since dawn of time
13:45 imirkin_: the C8 stuff broke at some point, and people did scream
13:45 imirkin_: took a bit to figure out wtf was going on since we had all forgotten about it
13:45 imirkin_: in the switch to atomic modesetting
13:46 pq: actually, when nouveau started using DRM fbdev helpers with KMS, more like, since that stops modesetting via fbdev
13:46 imirkin_: there's a very precise sequence of events that needs to happen to enable C8, and we were ... not doing that
15:02 jekstrand: Is gitlab SSH down for anyone else
15:02 jekstrand: daniels: ^^
15:02 jekstrand: remote: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp: lookup gitlab-prod-gitaly-1.gitlab-prod-gitaly.default on no such host"
15:02 imirkin_: <daniels> all of GitLab is currently down, will be back in 10-15min
15:02 imirkin_: admittedly that was ~2h ago
15:02 jekstrand: Maybe some of it is still down?
15:03 imirkin_: i have no additional info :)
15:03 jekstrand: I love how the the message sais "Error while dialing". I'm pretty sure that's not what happened. :)
15:04 imirkin_: in Go, the connect function is called "Dial"
15:04 daniels: yes, the Mesa repos are currently all completely knocked out
15:04 daniels: we're working on it flat tack
15:04 jekstrand: ok. I'll wait patiently then.
15:04 daniels: doing our best
15:05 jekstrand: At first I thought maybe Intel IT had tweaked the vpn/proxies and banned gitlab or something dumb like that. Glad to know it's not on my end.
15:05 daniels: heh, for once Intel IT is blameless
15:05 daniels: note that this means you'll also have a hard time with the web UI
15:05 daniels: you can still read & comment on some MRs
15:05 daniels: and definitely on issues
15:05 daniels: but you'll definitely hit random 503s, including on things like your todos
17:31 mcoffin: Hey, sorry if this is already a known issue, but is this page showing up as 'not found' for anyone else? https://gitlab.freedesktop.org/mesa/mesa I was working on an issue report, and it seems like gitlab.freedesktop.org might be experiencing some issues
17:31 imirkin_: gitlab.fd.o is indeed experiencing some issues
17:32 imirkin_: last update was ~2h ago, at which time "we're working on it"
17:32 jekstrand: mcoffin: Its known and the admins are working like mad on it.
17:33 mcoffin: Awesome, thanks guys just wanted to make sure it wasn't just me. I know they were having issues with ops cost of GL already, so it's a bummer they had an outage on top of that. Thanks for the quick replys!
17:34 pcercuei: drm_crtc_funcs.gamma_set() is also used for the atomic API, or only for the legacy one?
17:35 mcoffin: Also, does anybody know what the best way to get ahold of marek would be? I found a regression introduced by a commit of his in the 20.2 tree (283ad85944b5d9082f0ede7ab41fb353db53fee8)
17:36 jekstrand: mareko: ^^
17:36 jekstrand: mcoffin: Generally, I'd say file a bug. :-)
17:37 kisak: since you can't currently make a bug report, what's happening with that commit?
17:37 imirkin_: pcercuei: gamma_set should only be legacy. if you have an atomic driver, it will set the GAMMA_LUT property i believe
17:37 imirkin_: (or maybe even DEGAMMA_LUT if GAMMA_LUT isn't supported, not 100% sure)
17:37 pcercuei: makes sense, yes
17:37 pcercuei: thanks
17:38 imirkin_: pcercuei: that said, if you expect things to work with existing userspace that uses set_gamma, make sure you support a 256-sized LUT, not matter what your hw supports
17:38 mcoffin: jekstrand: I did file one, but I couldn't find a gitlab handle for him to cc him in the comments. Thanks for finding is handle for me :)
17:38 jekstrand: mcoffin: What issue are you seeing? I wrote the three passes enabled in that commit.
17:39 pcercuei: imirkin_: nah, userspace uses atomic API, and doesn't support DRM_FORMAT_C8 yet. I'm working on it
17:39 imirkin_: pcercuei: well, depends on the userspace ;)
17:40 imirkin_: pcercuei: you have a very embedded/controlled environment though i guess? (my memory is very short)
17:40 vsyrjala: atm you need a .gamma_set(). but there's an atomic helper you can just plug in
17:40 pcercuei: imirkin_: yes. SDL1
17:40 pcercuei: with a custom DRM backend (WIP)
17:41 mcoffin: jekstrand: I'm not too experienced with userspace driver dev (just have done some pm/oc stuff for amdgpu), so my specifics are crap, but the game "American Truck Simulator" and "Euro Truck Simulator" hang in an infinite loop, continually allocating memory until the system just OOM's. Happens when you hit the "drive" button, before the first frame of the load screen comes up. Bisected to that commit.
17:41 mcoffin: I've tried to find other cases where it happens, but that's the only one I've found so far
17:41 imirkin_: pcercuei: right. i was mostly talking about Xorg, which at various versions basically expects you to have something that's 256-sized
17:41 imirkin_: if that's not a concern, do whatever you like :)
17:41 pcercuei: the hardware has 256 entries anyway ;)
17:41 imirkin_: hehehe
17:42 imirkin_: yeah, there's a reason the assumption was baked in
17:42 imirkin_: it's a popular quantity
17:42 vsyrjala: C8 with something other than 256 entries would be a bit weird
17:42 pendingchaos: it looks like the issues page is still be working fine: https://gitlab.freedesktop.org/mesa/mesa/-/issues
17:42 imirkin_: well, set_gamma is used for RGBX8888 too
17:42 mcoffin: and becuase I've never had issues with userspace drivers before, I don't exactly have any tooling or knowlege of how to narrow it down. Since it's just in infinite loop and not a crash, I couldn't get a backtrace, and I don't really know where to toss a breakpoint in to inspect the issue.
17:43 jekstrand: mcoffin: I can totally believe that.
17:43 pcercuei: vsyrjala, well, the hardware does support 1bpp, 2bpp, and 4bpp pixel modes too ;)
17:43 pcercuei: (but I'm not adding support for these)
17:44 jekstrand: mcoffin: If you can attach externally, let it run until you're pretty sure it's hanging (maybe look for when memory usage starts to climb in top?) and ^C. Then run "finish" in GDB multiple times until it fails to finish. That should tell you the function-call-level at which it's infinite-looping.
17:44 Lyude: pq: ah, that might be relevant
17:44 Lyude: btw did you see any of the intel HDR patches that I sent onto intel-gfx?
17:44 jekstrand: In particular, I'm interested in knowing if the infinite loop is in one of those three passes or if it's in the optimization loop because passes are fighting with each other.
17:45 mcoffin: jekstrand: Will do right now, thanks for the help; I just didn't know where to start
17:45 jekstrand: No worries. Compiler infinite-loops aren't common but they do happen.
17:48 mcoffin: was very thankful for my 3960X's 20s compile time when doing that bisect. iirc was ~14 steps between 20.1.8 and 20.2.0-rc1
17:51 jekstrand: mcoffin: Another thing you can do is run with MESA_SHADER_DUMP_PATH=/tmp/mesa-dump and that will dump out all the shaders. Then you can use the run script from shader-db to test them without the game.
17:55 mcoffin: jekstrand: Thanks for helping me with the tooling. I'll try the shader debugging now. Here's the releant logs from GDB, so it hung in `si_nir_opts` seemingly (line 23 is where i sent a SIGTERM to avoid system running out of memory). https://gist.github.com/mcoffin/b1e78a538772e9c4edb990ea969a5d28
17:56 jekstrand: mcoffin: In that case, there are probably two opts fighting
17:57 kisak: oh mcoffin, even though the main page for mesa is down, https://gitlab.freedesktop.org/mesa/mesa/-/issues is working
17:58 jekstrand: mcoffin: Oh, I see the problem. It's calling nir_lower_var_copies in the same loop as find_array_copies and they're fighting
17:58 mcoffin: That was my assumption based on the contents of the commit, but I haven't worked with shader compilers ever, so there's some ramp-up time.
17:58 mcoffin: notably, the commit immediately before that one also has some optimization pass reordering, so you may want to look there too to see if it conflicts with what you wrote.
18:01 mcoffin: jekstrand: since kisak pointed out GL issues are working - here's the issue for reference: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3550
18:02 mcoffin: setting MESA_SHADER_DUMP_PATH didn't seem to cause anything to be dumped, unfortunately. Is there a compile-time option that needs to be enabled for that to work?
18:02 jekstrand: Maybe? I don't use it often. :-/
18:03 imirkin_: i always have to edit the code
18:03 imirkin_: so that it dumps BEFORE doing stuff
18:03 imirkin_: rather than after doing stuff, by which point it has already crashed
18:05 jekstrand: mcoffin: I just wrote a description of what I think is wrong. I'd make you an MR if it weren't for the gitlab issues. :-/
18:10 mcoffin: jekstrand: If you want to shoot me a patch over email I could test at least :)
18:11 jekstrand: mcoffin: Ok, can do. Or I'll just pastebin it here.
18:11 mcoffin: just DM'd you my email
18:11 jekstrand: One second
18:18 jekstrand: mcoffin: Attached a patch to the bug
18:18 jekstrand: mcoffin: I also pushed a branch. That seems to be working but creating MRs isn't
18:21 mcoffin: jekstrand: Just applied locally from the email, patch appears to resolve the issue! :) Thanks for the snappy resolution, though sort-of a bummer I didn't have to deep dive and learn more haha
18:21 jekstrand: mcoffin: No worries. Hopefully when mareko gets back on, he can review and run his shader-db on it.
18:22 mcoffin:googles shader-db
18:23 imirkin_: it's a database of shaders we use to ensure that things work (and potentially collect stats on quality of compilation)
18:23 imirkin_: everyone has their own personal private repository of these
18:23 jekstrand: If you look at the commit message of 283ad85944b5d9082f0ede7ab41fb353db53fee8, it has the shader-db results from enabling those optimizations.
18:23 imirkin_: collected from a variety of games over the eons
18:23 jekstrand: It looks like it cut virtually all of the spilling from F1 2015 and GRID: Autosport.
18:58 danvet_: mupuf, kishore has already created a new series, but I can't get at the MR because 503 :-/
20:25 daniels: btw, everything is coming back, just as fast as rsync's little legs can take it ... which is really surprisingly slow
20:29 jekstrand: daniels: Thanks!
20:33 HdkR: daniels: I find that rsync over ssh is bottlenecked by CPU due to encryption here. Local rsync? :)
20:34 kisak: rsync is probably crying it's little heart out over a billion small files, right?
20:34 daniels: HdkR: over ssh yeah
20:34 daniels: kisak: indeed
20:37 HdkR: I should check if rsync over NFS/SMB and a VPN ends up being faster. I presume it would still be CPU bottlenecked by encryption
20:38 HdkR: NFS/SMB without encryption at least has a higher bound before it becomes CPU limited
21:01 SanderMI: This frequency modulation, none really wants common public i.e non-contracted employees to be having somekind of full access to it. Cause this can be used as a gun by morans and misused by rookies where their interactions become dangerous to others. Instead you are given some primitive elementary control over things duty cycle based ranges , and a way to reverse the pulses with BGF! Imo those are very logical safety measures.
21:20 jekstrand: jenatali: Does your DXIL back-end use C++?
21:20 jenatali: jekstrand: Nope
21:20 jenatali: Just the glue for LLVM/clang for the CL frontend
21:58 jekstrand: Ugh... structurizer....
22:09 jekstrand: karolherbst: What do we need to do to get libCLC landed?
22:09 jekstrand: Maybe I need to just review the patches in detail
22:09 jekstrand: jenatali: ^^?
22:10 jenatali: jekstrand: Yeah I'm just waiting for a few more patches get r-b or acks
22:10 jekstrand: jenatali: These kernels I'm working on... They need CLC and rounding modes
22:10 jenatali: Oof... yeah rounding modes I haven't started porting yet
22:10 jekstrand: Lots of OpSMulExtended...
22:11 jekstrand: Wait... no.
22:12 jekstrand: ctz
22:12 jekstrand: That I can wire up
22:13 karolherbst: right.. conversions..
22:13 karolherbst: and proper unordered/ordered comparisons are also something we might want to deal with :D
22:13 karolherbst: even thought the latter is really just a perf opt