00:15 Lightkey: How well is Intel's DG1 supported? Would the Asus Vivobook Flip 14 with Tiger Lake and "Iris Xe Max" Just Work™?
00:17 airlied: no
00:17 airlied: Lightkey: it's got no upstream support yet
00:24 Lightkey: Aww.
00:28 swivel: airlied: any insight on ETA for support? is it being worked on at least?
00:29 airlied: swivel: it's been worked on, I've gotten a DG1 running with some code I wrote, but the officail intel code has yet to be submitted upstream
00:29 airlied: karolherbst, jekstrand :https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7231
00:29 swivel: cool, so it's not like intel completely abandoned linux support or anything along those lines
00:30 airlied: no it's just delayed and upstreaming is taking longer than expected
00:30 airlied: karolherbst, jekstrand : the first 3 patches I think deal with new lowering
00:31 karolherbst: but that requires each driver to implement PIPE_COMPUTE_CAP_HAS_GLOBAL_GROUP_SIZE, no?
00:33 karolherbst: airlied: also, in nir options, what's rare should be true
00:33 karolherbst: not what's common
00:33 airlied: karolherbst: does it? I've implemented it in all the drivers we have
00:34 airlied: karolherbst: I didn't see any negative options though
00:34 airlied: there is'nt any dont_lower_
00:34 karolherbst: we phrase it better
00:35 karolherbst: like has_umul24
00:35 airlied: has_stupid_kernel_abi
00:36 karolherbst: for example
00:36 karolherbst: has_kernel_inputs or something.. dunno
00:36 karolherbst: and maybe make PIPE_COMPUTE_CAP_HAS_GLOBAL_GROUP_SIZE just a normal CAP with a default value
00:36 karolherbst: I think everybody hates PIPE_COMPUTE_CAP_*
00:37 airlied: karolherbst: yeah too many options :-p
00:37 karolherbst: or make it a shader cap? dunno :p
00:38 karolherbst: but compute caps are annoying
00:38 karolherbst: I dislike every bit of that interface
00:40 airlied: yeah it's total overkill
00:41 karolherbst: stuff like this is why we need rust :p
00:57 karolherbst: "image2d_array_msaa_depth_t" lol...
01:17 airlied: karolherbst, jekstrand : okay the mr has updated caps
02:09 karolherbst: airlied: I am going a bit crazy with formats right now :D
02:14 karolherbst: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7241/diffs?commit_id=e1df2b443415485c8b46cd1b9e96afd0baf33c5f
02:16 karolherbst: what... the CTS doesn't test CL_UNORM_INT_101010_2?
02:16 karolherbst: the heck :D
02:18 karolherbst: https://gist.github.com/karolherbst/8a8dea551c94c7c5c623e3555a5aaea5
02:18 karolherbst: LD
02:18 karolherbst: :D
02:19 airlied: wow absolutely no mention of it in the cts
02:19 airlied: karolherbst: nice
02:19 karolherbst: now fill image crashes for CL_DEPTH with 16 bit...
02:20 karolherbst: that's even required by CL 2.0
02:20 karolherbst: CL_UNORM_INT_101010_2 is CL 2.1 btw
02:20 airlied: the CL 3.0 CTS doesn't even mention it
02:20 airlied: guess you get to file a cts bug
02:20 karolherbst: I guess
02:21 karolherbst: mhh
02:21 karolherbst: util_format_pack_description returns garbage for PIPE_FORMAT_Z16_UNORM
02:22 karolherbst: ehh
02:22 karolherbst: maybe not?
02:22 airlied: should be working, GL uses it
02:23 karolherbst: ahh..
02:23 karolherbst: util_format_pack_rgba
02:23 karolherbst: is the issue
02:23 karolherbst: desc->pack_rgba_float is called
02:23 karolherbst: mhh
02:23 airlied: ah yeah you can't pack depth using that infterface
02:23 karolherbst: :)
02:23 karolherbst: util_format_pack_z_32unorm?
02:24 karolherbst: but that also sounds wrong...
02:24 karolherbst: but I guess that's correct?
02:24 airlied: yeah that should work
02:24 airlied: what calls the pack functions?
02:24 karolherbst: resource::clear
02:26 airlied: ah just for the clear value
02:26 airlied: yeah llvmpipe unpacks that
02:26 karolherbst: airlied: maybe we could add an util_format_is_depth_or_stencil check in util_format_pack_rgba?
02:26 karolherbst: dunno
02:26 karolherbst: I guess we could do that inside clover
02:27 airlied: why?
02:27 airlied: clover should do it
02:34 karolherbst: mhhh
02:38 karolherbst: I think the CTS is broken here :D
02:39 airlied: for depth clears?
02:39 karolherbst: yeah
02:39 karolherbst: treats it as int input
02:39 karolherbst: but the spec says float
02:40 airlied: yeah the spec does say float for depth clears
02:41 karolherbst: right
02:42 karolherbst: guess that only is broken for the UNORM formats
02:42 karolherbst: yeah lol.. doesn't try float with CL_DEPTH anyway
02:43 karolherbst: uhm.. wait
02:43 karolherbst: it's my fault
02:43 karolherbst: "{ CL_DEPTH, CL_UNSIGNED_INT32 }" oops
02:43 karolherbst: needs to be CL_UNORM_INT32
02:44 airlied: makes sense
02:45 karolherbst: CL doesn't know 32 bit norms :D
02:45 airlied: 32-bit unorm is a pointless format
02:46 karolherbst: not saying it should know it
02:50 airlied: uuggh I found the llvm clover adding implicit input arguments just for radeon
02:52 airlied: make_kernel_args is a bit of a horror
02:54 airlied: might just have to explicitly lower some of those intrinsics as extra input args
02:54 karolherbst: airlied: radeon as in what exactly?
02:55 airlied: karolherbst: both r600 and radeonsi
02:55 karolherbst: ahh
02:55 karolherbst: yeah, that's all tight to the llvm backend
02:55 airlied: it's tied to libclc
02:58 airlied: iris lowers work_dim in the backend, we could probalby do that in the frontend
02:59 karolherbst: module::argument::grid_dimension
02:59 karolherbst: yeah
03:00 karolherbst: mhhh, need to fix supported_formats as well
03:05 karolherbst: mhh
03:05 karolherbst: how do I get nouveau to accept CL_DEPTH stuff
03:05 karolherbst: probably not at all
03:12 karolherbst: mhhh
03:12 karolherbst: I should sleep
03:17 jekstrand: karolherbst: So should I. :P
06:38 zzag: I'd like to render into opengl textures and then export them using eglExportDMABUFImageMESA. However, the problem is that exported dmabufs need to have the same fourcc. is there a way to create textures with a specific fourcc, e.g. DRM_FORMAT_ARGB8888?
06:48 daniels: zzag: instead of exporting from GL, allocate with gbm_bo_create{,_with_modifiers}() and import to GL
06:55 zzag: daniels: that's what i was afraid of. i was hoping that there is some buffer allocator agnostic way to create textures with a specific fourcc
06:56 daniels: you'd like buffer allocation to be independent of buffer allocators? :P
06:58 zzag: nah, just some abstraction over buffer allocation (ideally an egl extension or something) so my code is not bound to gbm
07:21 MrCooper: anholt: since the pages job has no needs:, it can only run once all jobs of the previous stages have passed
08:26 danvet_: robclark, maybe for context, I'm just somewhat sad mood that the entire "try to make legacy cursor work better for atomic drivers" effort seems such epic fail
08:26 danvet_: lots of drivers need to handle this, every driver hacks up its own thing
08:27 danvet_: all slightly different in what works and what doesnt
08:27 danvet_: and I'd expect cros might want to care about a bit more a real standard here, not just piles of hacks
08:27 danvet_: but maybe I'm just helpless hopeful and expecting wrongly, as usual :-)
08:28 danvet_: also entire discussion (after my initial confusion cleared up) not meant to block your patches, making that worker sched_fifo is clearly needed no matter what
10:03 dormito: If I suspect my gpu drivers (amdgpu/radeon) to be leaking memory (I know that slabinfo keeps reporting kmalloc-192 is growing, without bounds... it seems to corralate with when my screens are powered down), is the kernel leak detector the best way to do that, or does the gpu subsystems have better ways to do that?
10:32 MrCooper: dormito: don't know of any alternative to kmemleak
14:12 alyssa: anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7201
14:13 alyssa: Multiple CI flakes I think..?
14:13 alyssa: one in freedreno a306, the other mingw
14:13 alyssa: (Not sure who maintains the mingw target)
14:13 gitbot: Mesa issue (Merge request) 7201 in mesa "panfrost: 16-bit depth buffer support" [Panfrost, Opened]
14:18 alyssa: gitbot: You're new, hi! :)
14:18 gitbot: alyssa: Error: "You're" is not a valid command.
14:18 alyssa: Yeah, I don't like people starting conversations with me either, that's alright.
14:45 mripard: alyssa: it looks like you broke it :)
14:45 alyssa: mripard: I am qute good at breaking things ;)
14:50 robclark: danvet_: legacy cursor in general makes me sad.. but unfortunately CrOS uses it.. I think the way msm_atomic handles it is a reasonable prototype for what helpers could look like for async commit (at least for hw that has flush regs, and can poll the hw about whether flush is complete)
14:53 mripard: alyssa: still, breaking it by saying just hi is quite an achievement :)
14:55 danvet_: robclark, the trouble is right now that's all we ever managed
14:55 danvet_: a prototype in one driver
14:55 danvet_: more or less
14:55 danvet_: we even landed it, but a few of the driver conversions padovan did way back never made it in
14:55 danvet_: and now msm does another round
14:56 danvet_: so if we make this the new helper, we now have 2
14:56 danvet_: at that point imo best to just give up and move the one helper we have back into drivers as copypasta
14:56 danvet_: I just think we can do better
14:56 danvet_: it's also not just cursor, there's some good reasons for having async plane updates too
14:57 danvet_: but with bespoke versions of this in every driver we're not going to get it
14:58 vsyrjala: the name is just so bad. i915 cursors for instance simply can't do async updates
15:03 robclark: danvet_: I don't think it has to be completely separate from existing helper, but haven't really had chance to think about how that would look.. but in the short term I need it to work and not drop/miss frames just because the user has the indignity to move the mouse cursor ;-)
15:04 robclark: faster-than-vblank is a thing people with big power hungry gaming rigs can worry about.. but staying smooth 60fps at low clk speeds is a thing I have to care about today ;-)
15:14 alyssa: mripard: I do seem to have that effect on humans...
15:33 MrCooper: anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6209/diffs?commit_id=45fdba7f5e7964b7dd631ac72548ae5cc8869a5e will fix it
15:46 karolherbst: ehh.. did somebody broke the nir serialization stuff?
15:46 danvet_: robclark, well the helpers as-is got landed iirc because google paid for it
15:47 danvet_: but then somehow it got lost
15:47 danvet_: so if they don't fit for you, they're kinda pointless
15:48 karolherbst: mhh, maybe I broken it.. let's see
15:49 robclark: I don't have physical access to another arm chromebook to compare.. (ie. they are all locked away in office).. IME not dropping to 30fps when cursor moves is pretty easy.. staying at 60fps is less so
15:55 danvet_: robclark, oh I'm not against your changes to set the worker to sched_fifo
15:55 danvet_: that's needed no matter what, essentially you're emulating double buffered registers with that afaiui
15:55 danvet_: what looks a rather meh is that dpu has its own async_update infrastructure
15:56 danvet_: ignoring the async_update stuff we added specifically to make cros happy
15:56 danvet_: if cros doesn't want the helper async_update stuff, it's a bit silly to have that around
15:57 robclark: not quite emulating double buffered (they are all double buffered.. but it is UB if you update them again after flush).. but I'll see if we can come up with something more common eventually (but now is not a good time)
15:57 robclark: I guess the other arm chromebooks probably use async_update? I haven't really looked at them
15:59 danvet_: amd, mtk, msm/mdp5, rockchip, vc4
15:59 danvet_: from what I can tell
15:59 danvet_: more or less
15:59 danvet_: so msm/dpu is the first one adding this support and not using it
15:59 danvet_: disregarding the not converted ones that landed beforehand
16:04 robclark: (fwiw, mdp4 and early mdp5 had "real" cursors.. but on those the regs were not double buffered so you really had to be careful to update them in vblank)
16:04 danvet_: yeah I know
16:04 danvet_: well not the "not double buffered part"
16:21 vsyrjala: DPA: https://paste.debian.net/1168133/ should perhaps fix your modifier issue, by not creating a bogus IN_FORMATS blob
16:25 DPA: vsyrjala: Thanks, I'll check if it does.
16:36 anholt: MrCooper: great, thanks!
17:06 kusma: anholt: do you just want me to push the result to your branch when I'm done?
17:14 anholt: kusma: that would be great!
17:16 kusma: anholt: OK, done.... but it seems gitlab isn't up to speed yet...
17:17 kusma: I mean, I see it here: https://gitlab.freedesktop.org/anholt/mesa/-/commits/docs-vc4/
17:17 kusma: But not in the MR
17:17 anholt: yeah, the web ui has slowed down in responding to pushes recently
17:18 kusma: Ah, there :)
17:18 kusma: Yeah, I've also noticed that
17:20 kusma: anholt: thanks a lot for the cleanup, much nicer that way :)
17:21 anholt: glad you like it. looking forward to deleting my whole wiki :)
17:23 anholt: kusma: looks like you might have missed adding the redirect for vmware?
17:23 kusma: :)
17:23 anholt: I can put that bit in and merge
17:23 kusma: anholt: Whoops, maybe I rebase-missed that :P
17:24 kusma: anholt: Hmm, seems right here...
17:25 anholt: git grep vmware docs/conf.py ?
17:25 kusma: anholt: ah, seems you never added it :-P
17:25 kusma: I just checked that I took the same list of redirects as was in your branch
17:25 anholt: ah
17:25 kusma: So yeah, that should be added as well, good point!
17:38 DPA: vsyrjala: It didn't help. It Xorg still won't pick up the linear modifier with this patch.
18:03 vsyrjala: DPA: i was more expecting it to drop to some pre-modifier path when the blob is not present
18:13 ajax: is there any hardware that can render to rgb9e5/
18:13 ajax: ?
18:15 imirkin: ajax: not nvidia
18:16 imirkin: ajax: and presumably there's a distinction between render and blend?
18:16 imirkin: any (semi-modern) hw could pretend it's R32 and then have shader fixup code for it, but that won't work for blending
18:16 ajax: imirkin: yes, supporting it as a texture is just EXT_texture_shared_exponent which is quite widely supported
18:17 ajax: but APPLE_color_buffer_packed_float implies it's a legal renderbuffer format
18:17 ajax: which is kind of wild
18:18 imirkin: because it says it's ok for RenderbufferStorage?
18:19 imirkin: anyways, the R11F_G11F_B10F one is definitely renderable on most hw
18:19 anholt:hasn't encountered rgb9e5 renderbuffers on any hw
18:19 imirkin: but i don't think i've seen hw which can do RGB9_E5, esp not with blending
18:19 ajax: no; EXT_texture_shared_exponent specifies that you _can_ pass RGB9E5 to RenderbufferStorage, but just because it's esy to specify
18:20 ajax: but APPLE_color_buffer_packed_float adds it to the gles2 (!) table of renderbuffer image formats
18:20 airlied: maybe some imgtec or something
18:24 anholt: kusma: landed, and decommissioned my old wiki. Thanks!
18:37 DPA: vsyrjala: It probably does, but that won't matter. With glamor, it'll allocate a bo with gbm without specifying modifiers, so etnaviv will allocate a bo with an incompatible modifier (unless ETNA_MESA_DEBUG=no_supertile is set).
19:04 karolherbst: "read_instr: Assertion `!"bad instr type"' failed." :/ those are painful to debug
19:05 karolherbst: ehh wait..
19:07 kusma: anholt: great :)
20:27 mareko: AMD gfx10.3 supports rgb9e5 render targets
20:27 mareko: and also image stores
20:29 ajax: mareko: nice! thanks
20:29 mareko: with random features like that, you never know if they keep in hw or remove it
20:42 karolherbst: the heck, who added this useless check? "1. Commit messages must not exceed 80 characters" :p
20:42 karolherbst: can we stop treating 80 chars as anything magic nobody cares about except for false reasons? :p
20:45 HdkR: I'm happy when my lines are less than 160 characters :P
20:46 karolherbst: 160 is quite long, true
20:46 karolherbst: in my old java days I did 220 :D
20:46 karolherbst: but that was too much
20:46 karolherbst: 120 is quite okayish
20:46 karolherbst: or 140
20:46 karolherbst: anyway
20:46 karolherbst: can we let 80 die?
20:46 karolherbst: it doens't deserve any better
20:46 HdkR: I agree
20:47 airlied: the kernel dropped 80 alrrady im pretty sure
20:47 karolherbst: yeah
20:47 karolherbst: moved to 100
20:47 karolherbst: but what I am complaining about is git commits
20:47 hakzsam: anholt: are you aware of https://gitlab.freedesktop.org/jpark37/mesa/-/jobs/5126100 ?
20:47 karolherbst: hakzsam: I already pinged anholt on that
20:48 hakzsam: ok
20:53 karolherbst: the check is even broken..
20:56 pepp: karolherbst: it comes from MR !6209 (and the 80 limit is the default from https://gitlab.freedesktop.org/freedesktop/ci-templates/-/blob/master/tools/ci_fairy.py#L910)
20:57 Lyude: karolherbst: changing to 100 chars literally changed my life
20:57 Lyude: did not realize just how dramatically easier things are with 20 extra characters
20:57 karolherbst: :D
20:58 karolherbst: at least the kernel had always this "do not line break strings ever" rule
20:58 karolherbst: but a lof ot people ignored it
20:59 Lyude: karolherbst: and checkpatch still complained about exceeding 80 chars in strings for some reason
20:59 karolherbst: because nobody cares about checkpatch
20:59 Lyude: i wouldn't say that :P
20:59 karolherbst: I know
20:59 Lyude: tbh, i kinda wish nouveau would follow some aspects of the kernel style more closely
21:00 karolherbst: ohh
21:00 karolherbst: checkpatch on 5.9 was fixed actually
21:00 karolherbst: "my $max_line_length = 100;"
21:00 karolherbst: Lyude: I try my best to follow those, but Ben tends to ignore it even if I am doing it right :p
21:01 Lyude: yeah i know it bugs me too :(
21:01 karolherbst: breaking strings is really something you have to tell people often not to do
21:01 Lyude: tbh the thing I care about is just the if ((foo = bar)) stuff
21:01 karolherbst: breaking long strings is literally the worst thing you can do
21:01 karolherbst: followed by using spaces/tabs wrong
21:01 karolherbst: everything else is just minor
21:02 Lyude: basically yeah, as long as it's consistent
21:02 Lyude: *looks at a very specific other driver in the kernel*
21:02 karolherbst: double spaces?
21:02 karolherbst: terrible
21:02 karolherbst: okay, there are three worst things one can do
21:03 karolherbst: ohh
21:03 karolherbst: you mean assigning in the if clause?
21:03 karolherbst: that's terrible as well
21:03 Lyude: depends on the language. imho, my least favorite things: spaces after the identifier for a function (e.g. `foo ();` vs. `foo();`). actually that's really it. i just can't stand that one, but like all style choices i can learn to live with it
21:03 karolherbst: the glib styles is strange...
21:04 karolherbst:shouders
21:04 Lyude: honestly - part of the reason I dislike it is pretty legitimate, my brain differentiates between function calls and conditionals based on where there are spaces
21:04 Lyude: sure, my text editor can highlight most of it, but it still trips me up every now and thern
21:04 karolherbst: glibs style is just terrible
21:04 karolherbst: period
21:04 karolherbst: every bit of it
21:04 karolherbst: :p
21:05 Lyude: yeah... i hate the gint/gchar/etc. stuff.
21:05 karolherbst: yeah, that's terrible to
21:05 karolherbst: just use stdint
21:05 Lyude: actually i just plain don't use it when using glib
21:05 karolherbst: if your compiler can't do stdint/stdbool, your compiler is broken
21:06 Lyude: karolherbst: ironically while I don't like their code style I think there's actually a lot of really neat stuff glib does that people forget about
21:06 karolherbst: ohh sure
21:06 karolherbst: just it isn't the coding style
21:06 karolherbst: everything else might be perfect, the coding style just trips me off way too much
21:10 karolherbst: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/merge_requests/45 :p
21:11 karolherbst: I already prepared the best comments "we live in 2020, not 1960"
21:11 karolherbst: when was "80" chars even a real thing...
21:12 karolherbst: always sounded like nobody had to do that, just "there are those machines"
21:14 AndrewR: karolherbst, editing c files from VGA console ?
21:14 karolherbst: "don't care"
21:14 karolherbst: nobody does that
21:15 karolherbst: and even VGA has more space
21:15 Lyude: hey, at least one person does that, and i'm sure that person thinks they're very important
21:15 karolherbst: "don't care"
21:15 Lyude: hehe
21:15 airlied: just bump to 160 and move on :-p
21:16 karolherbst: if one person wants everybody else to suffer I call this persons a sadist
21:16 karolherbst: airlied: small steps, otherwise we will never get there
21:16 karolherbst: :p
21:17 karolherbst: signed of is also pretty useless these days..
21:17 karolherbst: I think it was _always_ useless
21:17 airlied: signed off where?
21:18 karolherbst: commits
21:18 airlied: what projdct? mesa.
21:18 airlied: ?
21:18 karolherbst: ci-template
21:18 karolherbst: seems like ci-template enforces that tags on MRs
21:18 airlied: sob only matters if project uses DCO
21:18 karolherbst: ...
21:18 karolherbst: not even then it matters
21:18 airlied: it does
21:18 karolherbst: there is no way it is legally binding nor enforceable
21:19 airlied: you a lawyer?
21:19 karolherbst: same as EULAs are not enforceable in some countries
21:19 karolherbst: you can always say "didn't see it"
21:19 karolherbst: and there you go
21:19 karolherbst: can't proove it
21:19 airlied: that misses the point
21:19 karolherbst: doesn't matter
21:20 airlied: ehich likely means you havent read the DCO
21:20 karolherbst: you can only enforce this kind of stuff if contributes _had_ to see it
21:20 karolherbst: and to sign off on it expicitly
21:20 karolherbst: like thise github CLA stuff you sometimes see
21:20 karolherbst: that's fine
21:20 karolherbst: but tags on commits are worthless
21:20 airlied: they do sign off on ot
21:20 airlied: that is what sob mea s
21:20 karolherbst: "I just did it because every other commit has that"
21:21 karolherbst: "I thought it meant I sign my commit is from me"
21:21 karolherbst: etc...
21:21 karolherbst: for lawyers from companies that's way to vague and they wouldn't rely on that
21:21 karolherbst: had this fun one or two times already
21:21 airlied: for companies they already rely on it
21:22 karolherbst: but not because the tags are there
21:22 karolherbst: the tags really don't change a thing
21:23 airlied: you should have that discussion with the LF lawyers then
21:24 airlied: as far as they ade aware the DCO is sufficent protectio
21:25 airlied: if you are receiving patches and suspect the submitter hasnt resd it, then please push back on them
21:25 airlied: at least all corporate contributors seem to take it seriously
21:25 karolherbst: yeah, but there is still no way to be 100% sure
21:25 karolherbst: the sob tag as a "I hereby confirm this is my work" might work
21:25 karolherbst: but besdies that? mhh
21:25 karolherbst: questionable
21:26 airlied: and if someone from nvidia sjbmit a 1m line c++ driver with an sob i moght query iy
21:26 karolherbst: right
21:27 airlied: for non corp contributors it isnt as important, since if they are submitting stuff they dont have rights to, there isnt much recourse, than the rights ownsr asserting theft
21:29 karolherbst: right, but this is a problem depending on the country already anyway, especially if you move into reverse engineering
21:57 Lyude: anarsoul: do you remember if your laptop's lcd panel was one of the ones that didn't work with VESA backlight controls and explicitly needed those intel patches?
21:58 anarsoul: yes, it doesn't work with VESA backlight controls and needs intel patches
22:04 Lyude: anarsoul: at some point soon I want to try one more vesa backlight related thing
22:04 anarsoul: IIRC you said that my panel doesn't declare vesa backlight controls
22:05 anarsoul: but sure
22:06 Lyude: oh maybe I did, mind grabbing https://gitlab.freedesktop.org/lyudess/auxrw/-/tree/master and getting me the output of `./auxrw r /dev/drm_dp_aux 700-72f` again if you can?
22:12 anarsoul: sure
22:12 anarsoul: 1 min
22:24 karolherbst: pendingchaos: ehh, your 1a912a550f34683e731b8f3ef36a15bb38398ae3 broke nir_deserialize for me :/
22:25 karolherbst: maybe we have too many intrinsics now?
22:25 anarsoul: Lyude: see PM, please let me know if you need more testing or auxrw dumps
22:26 karolherbst: but mhh.. we check for that
22:27 pendingchaos: nir_intrinsics.h only has 361 but it looks like packed_instr uses 9 bits
22:27 karolherbst: yeah.. it's odd
22:27 karolherbst: but it's reproducible here in an odd way anyway
22:29 karolherbst: let's see...
22:31 karolherbst: pendingchaos: so the error I am getting is read_instr: Assertion `!"bad instr type"' failed.
22:31 karolherbst: and header.any.instr_type is 13
22:32 karolherbst: and I think the odd thing is, this only happens with clover and only once the binary passed from the clover so file into the pipe driver so file
22:32 karolherbst: something is really off here