<karolherbst>
airlied: ... I debugged why optimizing libclc regresses llvmpipe perf only to find out that it didn't has the shader cache enabled in rusticl, because... llvmpipe_screen_late_init
<karolherbst>
any suggestion on how to deal with that?
<karolherbst>
ohh wait...
<karolherbst>
mhhh
<karolherbst>
I could just create the helper context before that
<karolherbst>
let me do this then
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
Zopolis4 has quit [Quit: Connection closed for inactivity]
smiles_1111 has joined #dri-devel
Guest3646 is now known as DemiMarie
benjaminl has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjaminl has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
benjaminl has joined #dri-devel
bmodem has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
benjaminl has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
hikiko has quit []
Company has quit [Quit: Leaving]
kzd has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
thellstrom1 has joined #dri-devel
fab has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
Lightsword_ has joined #dri-devel
exit70_ has joined #dri-devel
siqueira_ has joined #dri-devel
benjaminl has joined #dri-devel
Lightsword has quit [Read error: Connection reset by peer]
lemes has quit [Read error: Connection reset by peer]
_isinyaaa has quit [Read error: Connection reset by peer]
siqueira has quit [Read error: Connection reset by peer]
lemes has joined #dri-devel
itoral has joined #dri-devel
exit70 has quit [Ping timeout: 480 seconds]
sassefa has joined #dri-devel
isinyaaa has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
ngcortes has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
sassefa has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
rasterman has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
pallavim has quit [Remote host closed the connection]
alanc has joined #dri-devel
frieder has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
benjaminl has joined #dri-devel
lemonzest has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
tursulin has joined #dri-devel
fab has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
Leopold has joined #dri-devel
MajorBiscuit has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
pcercuei has joined #dri-devel
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
lynxeye has joined #dri-devel
djbw_ has quit [Read error: Connection reset by peer]
djbw_ has joined #dri-devel
vliaskov has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest3811
swalker__ has joined #dri-devel
libv_ has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
Guest3811 has quit [Ping timeout: 480 seconds]
libv_ is now known as libv
MajorBiscuit has quit [Quit: WeeChat 3.6]
benjaminl has joined #dri-devel
Ahuj has joined #dri-devel
fab has quit [Quit: fab]
benjaminl has quit [Ping timeout: 480 seconds]
sgruszka_ has joined #dri-devel
benjaminl has joined #dri-devel
<karolherbst>
dcbaker: another thing: you might want to allow providing custom/additional rust flags for test targets, as you could end up with new warnings for unused code or something
pcercuei has quit [Quit: brb]
cmichael has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
benjaminl has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
cimarrrrrrrrrrrrrrrrrrrrrrrrrr has quit [Remote host closed the connection]
<daniels>
gets you to ../src/gallium/auxiliary/nir/tgsi_to_nir.c:2027: ttn_emit_instruction: Assertion `dst->num_components == 4' failed.\
<DavidHeidelberg[m]>
alyssa: it was you `: ../src/gallium/auxiliary/nir/tgsi_to_nir.c:2027: ttn_emit_instruction: Assertion `dst->num_components == 4' failed.` I guess :D
<alyssa>
since Firefox decided the following ' was part of the link
<daniels>
ah yes
<daniels>
there's another one in bold red without the trailing ' just beneath it
Kwiboo has joined #dri-devel
<alyssa>
missed that one because it's low contrast and I'm colour blind ^_^
<alyssa>
anyway, yes, I see the assert fail now
<alyssa>
I can work with that!
<alyssa>
thank you both for the pointers
<daniels>
np
<alyssa>
CI is really showing its value here
<alyssa>
"rewrite the heart of Mesa touching every driver significantly, and only own 2 vendors hardware"
<daniels>
yeah, traces sure are handy given the amount of real-world coverage we get from CTS
<alyssa>
I'm a little surprised piglit didn't hit that one
Danct12 has quit [Ping timeout: 480 seconds]
<alyssa>
meanwhile I finally set up t860 deqp locally
<alyssa>
so ironically I have better local midgard coverage than I did when I was actually on the hook for midgard :~P
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
benjaminl has joined #dri-devel
<alyssa>
the thought of `nir_def *` is keeping me going ngl
<austriancoder>
ci question: I rebased https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23673 to current master and want to give it a quick test with ./.gitlab-ci/bin/ci_run_n_monitor.py --target gc2000_piglit but the rebased pipeline has no etnaviv targets (since the rebase). what I am doing wrong?
alyssa has quit [Quit: leaving]
benjaminl has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
<jenatali>
austriancoder: I think the farm is/was down so it was disabled
benjaminl has joined #dri-devel
kts has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
mvlad has quit [Remote host closed the connection]
benjaminl has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
fab has quit [Read error: No route to host]
lanodan has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
fab has quit []
benjaminl has joined #dri-devel
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
lanodan has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
alyssa has joined #dri-devel
* alyssa
glares at glsl_type
<alyssa>
I just need to swap out the base type why is this thing a const *
<austriancoder>
jenatali: only the lima farm is down atm
<austriancoder>
if I make an unrelated change - like adding a comment somewhere in src/gallium/drivers/etnaviv and do a force push the pipeline has now a etnaviv stage
Leopold has quit [Remote host closed the connection]
krushia has quit [Read error: No route to host]
krushia has joined #dri-devel
<jenatali>
Oh, right, ci-run-n-monitor uses the fork pipeline, which gets generated based on changes since the last push, since there's not a direct compare branch like in a MR
<jenatali>
I've been burned by that before, it's annoying
fab has joined #dri-devel
Leopold has joined #dri-devel
cmichael has quit [Quit: Leaving]
MrCooper has quit [Remote host closed the connection]
<dcbaker>
karolherbst: ... well that's embarrassing. The code for passing additional arguments to rust.test exists, but it's not in the listed keyword arguments so passing it will be an error
<karolherbst>
:'(
Leopold has quit []
<karolherbst>
oh well, as long as it's there with 1.2 that's fine at least for me :D
<karolherbst>
but not adding the libstdc++ dep makes it fail in either case... I also tried to use g++ as the linker but that didn't really change much
<dcbaker>
that makes sense. I'm assuming that libstdc++ needs to be the last library linked to, or at least it needs to be linked after the other c++ libraries
<karolherbst>
mhh.. maybe
<dcbaker>
either way, we should just solve this in Meson and not make you do it yourself
<karolherbst>
let me see if that fixes the issues :)
<dcbaker>
I haven't even tested it, just wrote some code, so no promises :D
<karolherbst>
it doesn't even run
<karolherbst>
`ImportError: cannot import name 'BothLibraries' from partially initialized module 'mesonbuild.build' (most likely due to a circular import) (/home/kherbst/git/meson/mesonbuild/build.py)`
jkrzyszt has quit [Ping timeout: 480 seconds]
<dcbaker>
yeah... I just fixed that
<dcbaker>
things that were supposed to be in the T.TYPE_CHECKING: block that weren't :/
<karolherbst>
ohh that bindgen thing also kinda came up in the past, glad that you also try to fix that one :)
<karolherbst>
dcbaker: okay, the link_args and rust_args work perfectly it seems, not so much the libstdc++ one
<alyssa>
jenatali: I'm not sure what to do re: derefs
<alyssa>
I have barely seen a deref before today and wanted to keep it that way =P
<alyssa>
I was just trying to fix a preexisting bug in llvmpipe, sigh
<jenatali>
alyssa: Is there a question, or just complete no idea what's going on?
<alyssa>
Kinda #2
<alyssa>
like I agree that this is probably broken
<alyssa>
I just don't know what I'm to do about it :-p
<alyssa>
(and I am several yak shaves away from where I started by now)
<alyssa>
which reminds me I have a nir-to-tgsi bug to get to
djbw_ has quit [Read error: Connection reset by peer]
Kayden has quit [Quit: -> office]
kts has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<dcbaker>
karolherbst: Apparently my distro doesn't package a new enough spirv-llvm-translator.... we're still at 11.x
<dcbaker>
I did push an updated, can you see if that works now?
idr has joined #dri-devel
<karolherbst>
oof
<karolherbst>
dcbaker: sure you pushed?
<dcbaker>
we did have 14.x packaged at one point, but I guess that wouldn't help now..
<dcbaker>
no
<dcbaker>
now I pushed
<karolherbst>
dcbaker: yep, that seems to have done the trick
djbw_ has joined #dri-devel
<dcbaker>
Sweet. Another case where rust suffers from being special :/
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
mbrost has joined #dri-devel
mvlad has quit [Remote host closed the connection]
moony has quit [Ping timeout: 480 seconds]
lvrp16 has joined #dri-devel
moony has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat_ has quit [Read error: No route to host]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
<bluetail>
isn't Rust communicated as the savior?
<psykose>
supply-side rust evangelion
pallavim_ has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
pallavim has quit [Ping timeout: 480 seconds]
penguin42 has joined #dri-devel
<penguin42>
karolherbst: hi, just trying to get to grips with get_timestamp and whether to return a result - is nora in here as well?
<karolherbst>
penguin42: so for get_timestamp itself it is fine to just return the timestamp or Option in case we want to make it an optional feature, but the CL API functions have to return the proper error codes. API validation should all happen inside `api/`
<penguin42>
karolherbst: OK great, that's the way I was going - I tried to stuff a Result into get_timestamp but it looks to me like none of the stuff in that half of the code uses Result or any of the API errors
<penguin42>
karolherbst: Another thing I wasn't sure about is you were suggesting doing *device_timestamp = *host_timestamp; - but we're using write_checked for pointer writes, do we have a read_checked as well, if not why not?
<karolherbst>
jenatali: sooo.. one thing I was thinking about was to shortcut linking of programs with just one object, but I'm not sure if we can just skip over spirv-tools linker. Any ideas here? Otherwise I'll just try things out and see how well it goes
<karolherbst>
penguin42: because you can't read from a null pointer and any result would be invalid
<karolherbst>
so you could return an Option, but you can also just check for is_null()
<jenatali>
IIRC we run the linker so that it strips the linkage annotations and removes unreachable SPIR-V
<karolherbst>
`write_checked` point was really just to not bother with null pointer checks
<karolherbst>
jenatali: right... but none of this matters when translating to nir, does it?
<karolherbst>
spirv_to_nir only translates function called by the entrypoint
<jenatali>
Well, at one point NIR didn't like the linkage annotations :)
<karolherbst>
mhhhh
<penguin42>
karolherbst: I guess we should probably check for the null pointers to spit out the right CL error?
<karolherbst>
penguin42: correct
<karolherbst>
write_checked is really just done to e.g. return the event object or other things which are not API errors, but like optional arguments
<penguin42>
karolherbst: OK, let me see where I go with that lot
<penguin42>
karolherbst: Switching bug; did we get the patch in which turns vectorisation on for fload4 and stuff? That made a hell of a difference for me
benjamin1 has joined #dri-devel
<karolherbst>
not yet, I think last time I asked mareko he said he wasn't sure about the benefits. But I think that might have ment GL or maybe he just didn't see your results, dunno
<penguin42>
karolherbst: OK, I tried to forward port it but it had got upset by an intervening patch (I think the raytracing stuff), I think I added comments on there showing the benefit so it's a clear win here
<penguin42>
karolherbst: It's actually a real pain for anyone writing OpenCL to write code that will work well on different cards/stacks - you try something like the vector ops and find they make a big difference for you and then someone else comes along and says it's worse on their card/stack/phase of moon
<karolherbst>
yeah.....
<karolherbst>
we know the pain
<karolherbst>
but for us it really shouldn't matter if you use vecs or not in code at least
<karolherbst>
it's just.. uhh... vecs in CL are just wrong
<karolherbst>
but then there are GPU ISAs doing vectors in compute, but I doubt anybody actually does that anymore
benjaminl has quit [Ping timeout: 480 seconds]
<karolherbst>
vecs are really only useful these days to ensure that loads are all vectorized, but that's it
<karolherbst>
I suspect in non GPU world it can look different
<alyssa>
karolherbst: Is there any way to scalarize in vtn or something like that, so we don't need vec8+ in NIR?
<alyssa>
I'm sure I've asked before
<karolherbst>
but on GPUs almost everything is scalar these days
<karolherbst>
alyssa: yeah.. this one pass I want to wire up
<karolherbst>
what was it called?
<karolherbst>
ohh
<karolherbst>
in vtn?
<karolherbst>
uhhh
<karolherbst>
mhhh
<alyssa>
or LLVM I guess
<alyssa>
although that doesn't help for SPIR-V kernels
<karolherbst>
we might be able to do it, but....
<karolherbst>
I suspect it's not worth the effort making vtn do it
lynxeye has quit [Quit: Leaving.]
<karolherbst>
vec5 is already a thing and I think somebody wanted a vec6 as well.. or evne higher?
<karolherbst>
wasn't freedreno doing like vec10 stuff somewhere?
<karolherbst>
alyssa: do we actually still have a constant cost from supporting vec8/vec16 in nir?
<karolherbst>
I thought we kinda got rid of most of it
<karolherbst>
ehh.. I guess the swizzle is still there...
<alyssa>
the swizzle is massive and I want it gone
<alyssa>
removing swizzles from NIR at this point would be a nonstarter
<alyssa>
next best is only storing swizzles for up to k components, where k is certainly less than 8
<alyssa>
I don't totally hate nir_alu_src having a vec4 swizzle, ignored if src->num_components > 4 (implied to be identity)
<alyssa>
+ an intrinsic to swizzle larger vectors
<alyssa>
I think that'd probably be workable to generate in vtn
<jenatali>
That sounds fine to me
<alyssa>
I don't really understand what the vec5 stuff is about.
<alyssa>
If CL were the only producer of big vectors, that plan would be straightforward, since lower_alu_to_scalar could run immediately after vtn so no other passes have to know about the big swizzles
<jenatali>
I assumed it's for sparse resource accesses, 4-component result + 1 status component
<alyssa>
oof. ok.
<jenatali>
(I haven't confirmed that, just a hunch, I saw similar code in our WARP driver)
<alyssa>
Yeah
<alyssa>
Yeah, it's sparse, that makes sense
<alyssa>
I would *almost* rather nir_tex_instr produce two defs for sparse
nicofee[m] has quit [Quit: Client limit exceeded: 20000]
<jenatali>
FWIW in DXIL it returns a struct
<jenatali>
Which then you have to use intrinsics to get components out of
<jenatali>
I could see NIR having it return an opaque single-component SSA with an intrinsic to get the 4-component result, and a different one to get the status
ngcortes has joined #dri-devel
<alyssa>
Oh, I kinda like that too
* alyssa
doesn't want to be the person to implement this though
<alyssa>
maybe I'm just salty from being in the nir_register salt mines
<HdkR>
Season those registers well
<HdkR>
Salt, pepper, paprika
<ccr>
perhaps some chili!
Hazematman has quit []
* ccr
offers a bottle of million scoville hot sauce
* penguin42
waits for alyssa to curry the arguments
<alyssa>
penguin42: I'm a C programmer
<alyssa>
all we have is water and salt
<alyssa>
no curry
<HdkR>
C++20 is the spice of life
vliaskov_ has quit [Ping timeout: 480 seconds]
<penguin42>
it's all those crunchy <'s
<alyssa>
mmm, piglit crashing in common code on radeonsi but not llvmpipe
<karolherbst>
alyssa: yeah.. I strictly don't mind handling it all in vtn, or doing something smart about the swizzle. Though I do think that limiting the max components is probably the sanes way out here
<alyssa>
karolherbst: CL requires vec16 no?
<jenatali>
Yeah
<karolherbst>
well yes.. but...
<karolherbst>
if we go after CL it's going to bite us sooner or later probably :D
<jenatali>
alyssa: Can't some hardware also do 16-component 8-bit UBO loads?
<jenatali>
I thought that was another reason for vec16
<karolherbst>
it's not really component based
<karolherbst>
but more like.. bytes
<karolherbst>
so you can just convert to higher bit size and destruct it later
<alyssa>
yeah, that will generate ~same code as 4-component 32-bit UBO load
<alyssa>
+ unpacks
<jenatali>
You can do ulong16 in CL though...
<HdkR>
uint8x16_t is just a vector, you can't lie to me vec16
<karolherbst>
sure, and we could just split it up inside vtn
<alyssa>
jenatali: that's what we're talking about, right
<jenatali>
Right, sure
<karolherbst>
I just don't know how painful that might look in vtn..
<karolherbst>
but let me check something...
<jenatali>
I just meant you can't upconvert the bitsize of that, you have to split it into multiple instructions
Mershl[m] has quit [Quit: Client limit exceeded: 20000]
<alyssa>
jenatali: right, the question is how painful it is to do that in vtn, versus supporting Just Enough vec16 in NIR to run lower_mem_access_bit_size and lower_alu_to_scalar and nothing else
<jenatali>
Yeah that makes sense
<karolherbst>
mhh so spirv-tools doesn't have an option to reduce vector component size sadly :D
<alyssa>
Speaking as the author of the only(?) NIR backend for hardware with legitimate vec16 SIMD ALU
<alyssa>
I do not want vec16 ALU in NIR :~P
<karolherbst>
alyssa: CL has full swizzles on vec16 though
<alyssa>
karolherbst: So?
<alyssa>
In the "vtn splits it up" plan, that includes dealing with the swizzles in vtn
<karolherbst>
how would you encode that in nir if you want to optimize the space siwzzles take
<karolherbst>
ahh right
<karolherbst>
I meant the other plan
<alyssa>
In the other plan, vtn inserts swizzle intrinsics for every vec16 source
<alyssa>
(every vec16 source with a nonidentity swizzle, I mean)
<karolherbst>
that might actually be not too bad
<karolherbst>
soo.. we only support swizzles for 4 components, everything else has to check in the source
<karolherbst>
if somebody _doesn't_ want to check the source, they have to lower to vec4 + thise magic vec8/16 lowering pass
<karolherbst>
*swizzle lowering
<karolherbst>
or it's just part of the vec lowering
<karolherbst>
yeah...
<karolherbst>
I think that's the path of least resistence
<karolherbst>
we might want to ditch vec8/16 from some backends (iris, radeonsi, llvmpipe?) first I think
Duke`` has quit [Ping timeout: 480 seconds]
<alyssa>
meanwhile I've reproduced my TTN crash
<alyssa>
thanks to radeonsi drm-shim
<alyssa>
so glad I set up all those aliases so I can just prefix tests with a driver name and it works :p
<alyssa>
fp64 in tgsi-to-nir, for some inexplicable reason
bgs has quit [Remote host closed the connection]
<alyssa>
fs_pack_color_zs, I guess
fab has quit [Quit: fab]
fab has joined #dri-devel
ram15[m] has quit []
benjaminl has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
neobrain[m] has quit []
Haaninjo has quit [Ping timeout: 480 seconds]
thellstrom1 has quit [Read error: Connection reset by peer]
<dj-death>
alyssa: this trace is known to change hash every time we make compiler changes
Kayden has joined #dri-devel
<alyssa>
dj-death: Alllright
<alyssa>
(It's changing on zink+turnip too fwiw)
<alyssa>
if this is a case of "inserting moves in slightly different places causes random butterfly effects that result in imperceptible hash differences", whatever
<alyssa>
just concerned that it's a real fail and not spurious trace CI being trace CI
pp[m] has quit [Quit: Client limit exceeded: 20000]
halfline[m] has quit [Quit: Client limit exceeded: 20000]
rasterman has quit [Quit: Gettin' stinky!]
<dj-death>
imperceptible indeed
<dj-death>
on the edges
<dj-death>
my guess it catches one edge of a triangle once, the other the next time
<alyssa>
alright
<alyssa>
ignore it then?
<alyssa>
it's fine I still have this LLVM crash to deal with
ceoarrrrrrrrrrrrrrr^ has joined #dri-devel
<dj-death>
once you
<dj-death>
once you're done with the MR, update to the latest hash ;)
<alyssa>
sounds good
<alyssa>
I don't understand how LLVM is segfaulting
<alyssa>
not llvmpipe
<alyssa>
LLVM
ngcortes has quit [Ping timeout: 480 seconds]
<airlied>
where's the explosion?
<alyssa>
airlied: #0 0x0000ffff7c1cb71c in llvm::ConstantVector::getSplat(llvm::ElementCount, llvm::Constant*) () from /lib/aarch64-linux-gnu/libLLVM-15.so.1
<alyssa>
dj-death: perhaps we should remove that trace then if it's known to be especially sensitive
<dj-death>
alyssa: you should ask anholt_
djbw_ has quit [Read error: Connection reset by peer]
* alyssa
shrug
<alyssa>
If I can update the checksum for that one I don't care too much right now
<alyssa>
airlied: to be clear, it only happens after my "gallivm: rewrite the world" commit so it's something I've changed, but I don't know how to go about debugging that appropriately named splat
<alyssa>
Any guesses how many regressions I've introduced since a few hours ago?
<alyssa>
:P
Haaninjo has joined #dri-devel
<psykose>
three
mbrost has joined #dri-devel
Vanfanel has quit [Quit: Client limit exceeded: 20000]
EricCurtin[m] has quit [Quit: Client limit exceeded: 20000]
benjamin1 has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
znullptr[m] has quit [Quit: Client limit exceeded: 20000]
Vin[m] has quit []
onox[m] has quit [Quit: Client limit exceeded: 20000]
arisu has quit []
yshui` has quit []
bubblethink[m] has quit [Quit: Client limit exceeded: 20000]
<karolherbst>
dcbaker: ohh.. did you end up ignoring -I flags in deps? Because that's something I can't test locally really... or maybe I can? dunno... but you know, debian adds paths like "-I/usr/include/x86_64-linux-gnu" to random deps
Wallbraker has quit [Quit: Client limit exceeded: 20000]