ngcortes has quit [Remote host closed the connection]
saurabhg has joined #dri-devel
technopoirot has quit [Ping timeout: 480 seconds]
<graphitemaster>
in glsl is it safe to assume a shared array of T indexed by thread id will be "thread-safe" in the memory barrier case, or is it possible for a write to such an array to be "larger" than T (thus hitting adjacent Ts) and so you need a memory barrier regardless?
<graphitemaster>
I cannot find anything in the spec about this
<graphitemaster>
Like imagine shared float stuff[N]; stuff[gl_LocalInvocationID] = n, but some stupid compiler decides to generate a 64-bit wide store to the shared variable with like zero extension or something
<graphitemaster>
Or like some masked write
<DrNick>
OG Alpha style?
<jekstrand>
graphitemaster: As long as you stay in-bounds, it should be safe. If you go out-of-bounds, you're in undefined behavior territory anyway.
rsripada has quit [Remote host closed the connection]
<cwabbott>
I assume that commit is what caused it because all the other changes are to freedreno or turnip
<cwabbott>
the tests it broke are in the same general area, but I have no idea how it could affect d3d12 because it doesn't use border_color_is_integer
<jenatali>
cwabbott: I can take a look later today
<cwabbott>
jenatali: that struct is a union, so as long as it's just copying bits I guess it should be fine?
<jenatali>
cwabbott: No, it's copying integer bits into a destination that's going to interpret it as a float
<cwabbott>
also, stencil is just a normal integer border color, so if this is a problem it should be a problem for everything
<cwabbott>
jenatali: I think it should hit the lowering path, actually
<jenatali>
D3D doesn't support integer texture sampling (yet), so there is no integer border color concept
<jenatali>
Except for stencil...
<cwabbott>
jenatali: what I don't get is, it already was an integer
<cwabbott>
the bits were the same
maxzor_ has quit [Ping timeout: 480 seconds]
<jenatali>
Hm? What do you mean it already was an integer?
<cwabbott>
stencil border color is an integer
<cwabbott>
it just was reinterpreting the integer as float and copying it around (in mesa/st)
<cwabbott>
now it copies around the same integer
<jenatali>
st_translate_color is getting called with is_integer, and the definition of is_integer is now changed to include stencil sampling where it didn't before
<cwabbott>
right
<cwabbott>
but if you look at what it's copying around, it's a union
<cwabbott>
so the is_integer and !is_integer parts are actually doing the same thing
<cwabbott>
(except the cases that replace with a constant)
<cwabbott>
the higher layer (mesa itself) should be setting the stencil border color as an integer
<jenatali>
Which is missing from the integer side of the function
<cwabbott>
that commit also moves it
mclasen has joined #dri-devel
<cwabbott>
to the integer side
<jenatali>
Oh. Sorry I just woke up, haven't tried it yet :)
<zmike>
you mean you don't do border colors at 5:30am!??!!?!??!?
<cwabbott>
border colors: not even once
<ccr>
"this is your brain." "this is your brain on border colors."
<cwabbott>
jenatali: also, I don't think the driver knows whether a sampler is a stencil sampler at shader-compile time
<cwabbott>
so the integer sampling lowering should also happen for stencil
<jenatali>
Right
<jenatali>
I'll see if I can get you an answer before the baby wakes up, otherwise I probably won't be able to get you one until quite later in the day
<cwabbott>
haha, ok
rkanwal has quit [Quit: rkanwal]
Lynne has quit [Remote host closed the connection]
shashank_sharma has joined #dri-devel
shashank_s has joined #dri-devel
saurabhg has quit [Remote host closed the connection]
saurabhg has joined #dri-devel
aravind has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
<jenatali>
The difference is that now I'm getting border color not-replicated, only in the R channel
shashank_sharma has quit [Ping timeout: 480 seconds]
<jenatali>
And for whatever reason D3D samples border color out of G
pjakobsson has quit [Remote host closed the connection]
<jenatali>
cwabbott: texobj->StencilSampling is false for me, so st_translate_color gets called with integer format as false but baseFormat as GL_STENCIL_INDEX, sending it down the float path, but it doesn't hit any cases in the switch
<jenatali>
So, replicating the GL_STENCIL_INDEX handling to both sides of the integer branch would work. But you probably want to understand why StencilSampling is false?
<cwabbott>
jenatali: huh, yeah that sounds broken?
<cwabbott>
then again, I don't know much about GL
<cwabbott>
but at least is_integer should be true if we're sampling stencil
<jenatali>
zmike: ^^
<cwabbott>
otherwise vulkan will definitely be broken
<cwabbott>
by vulkan I mean zink
<zmike>
uhhh
<zmike>
which test are we talking about here
<zmike>
texwrap formats ugh my ptsd
<cwabbott>
I thought GL_STENCIL_INDEX was not a real format, just used for the StencilSampling (sample stencil part of D24S8) case
<cwabbott>
but maybe that's wrong?
* jenatali
shrugs
<jenatali>
My knowledge of GL is limited to what I learn from debugging code that we asked other people to write for us, or me implementing new extensions
<jenatali>
And I haven't had to touch stencil sampling yet :)
<zmike>
I'm looking at it
<zmike>
hmmm I'm seeing is_integer=1 in st_translate_color
<jenatali>
I wonder if I'm looking at another MSVC packed enum being signed issue...
<jenatali>
Let's see how StencilSampling gets set
<zmike>
ah but texobj->StencilSampling is indeed false
<jenatali>
Oh weird then how do you get is_integer=1?
<zmike>
texobj->_IsIntegerFormat
<jenatali>
That's also false for me
<jenatali>
Interesting
<zmike>
just to make sure, this is piglit/bin/texwrap GL_ARB_texture_stencil8 bordercolor swizzled
<jenatali>
Oh I didn't go for the swizzled one
<zmike>
isn't that the one that's failing?
<zmike>
oh both of them are
<jenatali>
Yeah
<zmike>
ok so it's fine
<zmike>
the line wrapping and my brain
ella-0_ has joined #dri-devel
sul has joined #dri-devel
<cwabbott>
does mesa use GL_STENCIL_INDEX internally for stencil formats?
<zmike>
hm the samplerview being referenced is PIPE_FORMAT_S8_UINT
<zmike>
so it knows it's stencil
<zmike>
puzzling
<cwabbott>
I guess if that's true it would be expected, but I'd expect IsInteger to be true
<cwabbott>
_IsIntegerFormat that is
ella-0 has quit [Read error: Connection reset by peer]
<zmike>
ah GL_DEPTH_STENCIL_TEXTURE_MODE isn't used I think
<jenatali>
Right, because this is a stencil-only texture, not the stencil part of depth-stencil
<jenatali>
So that sounds like a bug, but a different bug
<zmike>
I don't know that it's a bug?
<jenatali>
Why do you have _IsIntegerFormat true but not me... hm...
<zmike>
ah that bug
<zmike>
let's find out
nchery has joined #dri-devel
<zmike>
texobj.c:709
<zmike>
should be it
<jenatali>
Right
<zmike>
I have GL_UNSIGNED_INT;
<jenatali>
Looking...
<jenatali>
I have GL_UNSIGNED_NORMALIZED
<zmike>
🤔
<jenatali>
Probably because we don't have an S8_UINT format
<jenatali>
So we map it to Z24S8
<cwabbott>
well, in that case I guess StencilSampling should be true then?
<zmike>
huh.
<jenatali>
So we need StencilSampling to be true because this is sampling the stencil part of a depth-stencil texture for us
<zmike>
so then maybe the check should be (texobj->_IsIntegerFormat || texobj->StencilSampling || texBaseFormat == GL_STENCIL_INDEX)
<zmike>
in st_atom_sampler.c
<cwabbott>
I imagine you'd want StencilSampling to be true, though
<jenatali>
That'd work. Or maybe when testing texture completeness we should set StencilSampling to be true if the base format is GL_STENCIL_INDEX
<zmike>
I think maybe you don't want to mess with StencilSampling since that's a GL state
<zmike>
this is the only place it should matter anyway, it seems
<jenatali>
texobj.h:142 also looks suspect
<jenatali>
Agreed those look like the only 2 though
<zmike>
hm
<zmike>
do you have restrictions on nearest vs linear for stencil sampling?
<zmike>
I guess GL does so it doesn't matter if you do
<jenatali>
Yeah, it's an integer, we don't support sampling integer formats at all, right now we lower them to loads but in the future we're adding point sampling support
<jenatali>
But yeah it's a GL limitation too
<zmike>
hm
<zmike>
I think it doesn't affect the texobj case
<zmike>
that's specifically for stencil sampling of a depth/stencil image
<zmike>
so changing that one conditional in st_atom_sampler.c should be sufficient
<jenatali>
Ok
<zmike>
cwabbott: ^
toolchains has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
kj has quit [Remote host closed the connection]
jewins has joined #dri-devel
<cwabbott>
ok, seems like that fixed it
<zmike>
\o/
<zmike>
cwabbott: marge away!
kj has joined #dri-devel
sul has quit [Read error: Connection reset by peer]
nchery has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
sul has joined #dri-devel
nchery has joined #dri-devel
maxzor_ has joined #dri-devel
sul has quit [Read error: Connection reset by peer]
kj has quit [Remote host closed the connection]
maxzor_ has quit [Ping timeout: 480 seconds]
technopoirot has quit [Ping timeout: 480 seconds]
kj has joined #dri-devel
<jenatali>
cwabbott: I had to disappear for a bit otherwise I would've said you could add an r-b to that last patch (now that I've been forced to understand it in depth anyway :P)
nchery has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
chaim has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
nchery has joined #dri-devel
sul has joined #dri-devel
Lynne has joined #dri-devel
toolchains has joined #dri-devel
Duke`` has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<austriancoder>
If someone has some spare time for a quick review: !17121
wvanhauwaert has quit [Ping timeout: 480 seconds]
<jenatali>
Looks like the freedreno runners are pretty badly overloaded right now, taking a full hour for a change to common Vulkan code :(
<zmike>
robclark playing minecraft again during work hours smh
tursulin has quit [Ping timeout: 480 seconds]
<robclark>
zmike: slacker!
<robclark>
not sure if there is a way to see what jobs are queued up?
<jenatali>
Looks like I got a flake failure too :(
toolchains has quit [Ping timeout: 480 seconds]
tobiasjakobi has quit []
<robclark>
jenatali: looks like it is in particular a630 runners that are backed up? Could be related to a thing tomeu is trying to get running (freedreno in vm ci job)?
<jenatali>
Ah could be
<jenatali>
Guess I'll try again later
flto has quit [Quit: Leaving]
tango_ has quit [Ping timeout: 480 seconds]
<robclark>
tomeu, anholt_, I wonder if we could do a separate tag/label thing for a subset of any given group of runners that we could use for WIP/experimental things, so-as to not starve marge?
<robclark>
like marge generated pipelines have access to whole set of runners, but other pipelines have just a subset.. or something along those lines?
technopoirot has joined #dri-devel
devilhorns has quit []
<anholt_>
could easily do for bare-metal, but harder to do for lava.
<anholt_>
(their tags aren't at the gitlab level, and you'd need to coordinate with owners of those labs instead of just going in gitlab admin interface)
<robclark>
ahh.. well at least we could do it for a630 runners
flto has joined #dri-devel
ybogdano has joined #dri-devel
<robclark>
anholt_, tomeu: hmm, I suppose if the lava runners are doing their own job scheduling, they could still prioritize marge jobs?
<jenatali>
It also seems like marge should cancel in-progress jobs when a merge times out and it moves on to a new one, otherwise those old jobs are just stealing time from the new ones
<anholt_>
I don't know that lava cares about gitlab-level job cancels, anyway.
<jenatali>
Oh then maybe that's not helpful
<anholt_>
I mean, it would be really good if it did, but collabora would have to have some daemon outside of gitlab-runner watching and managing that.
<anholt_>
(I'm way more concerned about people clicking cancel than marge timeouts, which are quite infrequent)
<jenatali>
Fair
ppascher has joined #dri-devel
<krh>
is nir_opt_offsets.c useful for global IO? Something like load_global_amd/ir3 seems like could benefit?
<anholt_>
seems like
toolchains has joined #dri-devel
<tomeu>
anholt_: we have a priority property that we could increase for jobs in marge-triggered pipelines
<tomeu>
but right now the gitlab runner for lava will stop taking new jobs if the queue is full
<tomeu>
we could do some scheduling in the gitlab runner, but then the time waiting in the queue will count towards the gitlab job timeout
<tomeu>
robclark: btw, I only had one long-running job, wonder if more machines were stuck even if the gitlab jobs had already stopped
toolchains has quit [Ping timeout: 480 seconds]
<jekstrand>
bbrezillon: Is dozen using the common secondary support these days?
<robclark>
not sure, it would be nice to have a timeline view of when individual runners started and finished various jobs
pixelcluster has quit [Quit: Bye-bye!]
jkrzyszt has quit [Ping timeout: 480 seconds]
jewins1 has joined #dri-devel
Haaninjo has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
JohnnyonF has joined #dri-devel
sul has quit [Read error: Connection reset by peer]
Johnny has joined #dri-devel
<jenatali>
jekstrand: I think so
<jekstrand>
Ok, I guess I get to blind-type convert its pipeline layouts too.
<jekstrand>
attempting lavapipe at the moment
<jenatali>
I can help if you need
toolchains has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
* jekstrand
really wishes he'd payed more attention to VK_KHR_pipeline_libraries
<zmike>
^ - everyone in khronos anytime any extension is released
<jekstrand>
I was too trusting
<jekstrand>
This descriptor set layout merging is utter nonsense
<jekstrand>
And there's absolutely no good reason for it
<zmike>
if you think it's bad now you should've seen it before I started hassling people about it
saurabhg has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
technopoirot has quit [Ping timeout: 480 seconds]
<jenatali>
Man CI is having a rough time today
<jekstrand>
zmike: Ok, talked to tobias and I'm not crazy and it's not as bad as I thought. Lavapipe is just insane.
<jekstrand>
I really should have started from that assumption....
Major_Biscuit has quit [Ping timeout: 480 seconds]
<jenatali>
Hopefully Dozen is less insane :P
<jekstrand>
Dozen doesn't have pipeline libraries yet
<jenatali>
True
<zmike>
jekstrand: I think I might have been able to simplify the copy code after the craziness was driven out of the spec but instead I just added a null check
<zmike>
though also the way lavapipe handles descriptor sets is a little special
toolchains has quit [Read error: Connection timed out]
mbrost has joined #dri-devel
<bbrezillon>
jekstrand: yes, it is
<jekstrand>
bbrezillon: Ok, I've found a path that doesn't require quite as much effort as my original plan
<bbrezillon>
how does secondaries interact with the pipeline library stuff you were mentioning? Or is this 2 different things that popped up in the discussion?
sul has joined #dri-devel
<anholt_>
jenatali: yeah, sorry about that. doing some filtering work to reduce the pain
<jekstrand>
I'm trying to add a common vk_pipeline_layout implementation
<bbrezillon>
that's good news, I guess
<jekstrand>
bbrezillon: And we can simplify some of the stuff with secondaries if we can assume every driver that uses the common trace/replay code uses vk_pipeline_layout
<jekstrand>
Specifically, we can get rid of those annoying per-diver ref/unref hooks
<bbrezillon>
hm, interesting
<bbrezillon>
I guess the plan is to keep all the driver specific stuff at the set_layout level
<jekstrand>
Yeah.
<bbrezillon>
and then just reference set layouts from the pipeline layout
<bbrezillon>
too bad I diverged from this approach a while back then...
<jekstrand>
And that's where it interacts w/ pipeline libraries. With pipeline libraries, you don't necessarily have the full set of set layouts up-front.
<jekstrand>
You just have the ones that a particular shader needs.
<jekstrand>
Which is fine for anv/radv
<zmike>
ah, I see why you are sobbing in the corner now
<jekstrand>
Less fine for panvk but I've got a plan to let panvk keep having its own thing.
<bbrezillon>
I guess that just means we can't create the root signature at pipeline-layout creation time
<jekstrand>
maybe not?
<jekstrand>
I'd have to be far deeper in the details to be sure.
<bbrezillon>
that's probably fine
toolchains has joined #dri-devel
<bbrezillon>
especially since such pipelines are not supposed to be bound
<zmike>
I'd imagine you can't create the root signature until you've got the full pipeline since descriptor sets can be merged at any point
<jenatali>
I mean we could create a root signature, but if it gets merged, we'd have to create a different one with the new result
<bbrezillon>
yep, there's no point in creating the root signature early if it's not the final one
<jenatali>
That sounds okay, those objects are supposed to be relatively cheap, they're just a way to cache driver metadata and don't correspond directly to GPU objects
<bbrezillon>
and I guess we have all we need at the pipeline level to create it late
<bbrezillon>
all we the the set layouts for is the binding translation step happening in the NIR domain
<bbrezillon>
(I mean, in the pipeline-library case)
<bbrezillon>
and jekstrand seemed to imply that we get passed all the set-layout shaders care about
saurabhg has joined #dri-devel
<jekstrand>
bbrezillon: Yup
<jekstrand>
bbrezillon: It's only if you have cross-set stuff that it gets hairy
JohnnyonFlame has joined #dri-devel
JohnnyonFlame has quit []
toolchains has quit [Ping timeout: 480 seconds]
<jenatali>
anholt_: One thing I've noticed is that there's 2 a630 jobs that run on every MR, seeming to ignore the rules, the gles_asan and vk_asan ones
<jenatali>
Or maybe that's for robclark ?
Johnny has quit [Ping timeout: 480 seconds]
<ajax>
anyone happen to know how we do macos ci these days?
<zmike>
I have Tim Apple's home line if you want to call him about something?
<jekstrand>
dj-death: Looking at the ANV pipeline libraries MR and I see you're doing an extra indirection for dynamic buffers now.
nchery has quit [Ping timeout: 480 seconds]
<jekstrand>
dj-death: That's gonna mean no push constants. :(
<jekstrand>
I guess we can optimize to only do the indirection if there's a set missing and tell people to put their dynamic stuff in set0
lemonzest has quit [Quit: WeeChat 3.5]
lynxeye has quit [Quit: Leaving.]
nchery has joined #dri-devel
<jekstrand>
Actually, maybe that's ok.... We still generate a per-stage bind_map and UBO pushing requires it go in the bind_map
technopoirot has joined #dri-devel
Haaninjo has quit [Ping timeout: 480 seconds]
<ajax>
jenatali: hmph. that gives me build testing but not, like, piglit against xquartz
<ajax>
(not to sound ungrateful, thank you for pointing me at it)
<jenatali>
ajax: Yeah I have zero context on it other than remembering seeing that MR go by a little while ago :)
<ajax>
i keep needing to fix code that has unpleasantly large #ifdef APPLEGL in it and i'd prefer not to break it if i don't have to
<jenatali>
ajax: Well, if the build was working, it looks like it at least tries to run meson tests in that pipeline
tjmercier has joined #dri-devel
tjmercier has left #dri-devel [#dri-devel]
tjmercier has joined #dri-devel
shashanks has joined #dri-devel
shashank_s has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
sumoon has joined #dri-devel
<dj-death>
jekstrand: no really choice I guess (for the indirection)
<dj-death>
s/really/real/
Haaninjo has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
<dj-death>
jekstrand: and yeah, with independent sets you can't really push much
<dj-death>
jekstrand: use push descriptors I guess is the answer
<dj-death>
jekstrand: I want to force the push descriptors in the binding table only
<dj-death>
for some other work
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
<jekstrand>
dj-death: So I think push is actually going to be fine the more I think about it.
<jekstrand>
dj-death: Because push only happens for stuff that ends up in the binding table and, since that's per-stage, independent sets don't matter. All that matters is that you have all the descriptor set layouts for the given stage.
toolchains has joined #dri-devel
<dj-death>
jekstrand: hmmm independent sets are within a stage
<dj-death>
jekstrand: oh I see
<dj-death>
yeah we do have one bind map per stage
<dj-death>
so should be find
<jekstrand>
dj-death: I'm re-thinking through all this stuff for NVK.
<jekstrand>
Trying to build it with all the flexibility up-front.
<dj-death>
I did disable the binding table for independent sets :(
<jekstrand>
Why?
<dj-death>
but actually I think it only applies to dynamic buffers
<dj-death>
because I didn't know better
<jekstrand>
Binding table should work fine with independent sets
<jekstrand>
Ah
<jekstrand>
Yeah, it took me a bit to wrap my head around the independent set stuff too
<dj-death>
because the offsets are in the flatten table
<jekstrand>
And a chat w/ Tobias to make sure I wasn't crazy. :)
<airlied>
jekstrand: would love to push desc sets below galliim for lvp, but uggh
<dj-death>
jekstrand: also because dynamic offsets are not tracked per stage
<jekstrand>
dj-death: That sould be fine, I think.
<dj-death>
jekstrand: yeah, not quite sure what I was thinking
<jekstrand>
dj-death: It's ok. This extension is thorny
<jekstrand>
bbrezillon, jenatali: That'll need a pair of dozen patches before it can go in as-is.
pixelcluster has joined #dri-devel
<jenatali>
Ack
toolchains has joined #dri-devel
<jekstrand>
Other drivers can choose to use it at their leisure but I want the common ref counting for the ones using vk_cmd_queue.
shashank_sharma has joined #dri-devel
<YuGiOhJCJ>
hello, I am using a i7-9700 CPU, mesa 22.1.1 and when I check the xorg log file, I see that xorg tries to load the driver "i965_dri.so" that is not anymore provided by mesa, so I am wondering why xorg does not try the iris driver that is an alternative for i965 https://www.phoronix.com/scan.php?page=news_item&px=Mesa-Classic-Retired
<dj-death>
jekstrand: yeah I did change a thing at some point to use a single push buffers for all stages, I guess that's going out of the window
shashanks has quit [Ping timeout: 480 seconds]
<dj-death>
I kind of like a single buffer
<jenatali>
jekstrand: Got a particular timeline in mind for when you want to land that?
shashanks has joined #dri-devel
apinheiro has joined #dri-devel
shashank_s has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
shashank_sharma has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
technopoirot has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
mclasen has quit [Ping timeout: 480 seconds]
neonking_ has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
neonking_ has joined #dri-devel
toolchains has joined #dri-devel
<anholt_>
YuGiOhJCJ: perhaps you have an ancient x server? xserver should be asking mesa what driver to use as of 8d4be7f6c4f7c673d7ec1a6bfdef944907a3916e
zf has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
toolchains has quit [Ping timeout: 480 seconds]
pixelcluster has quit [Ping timeout: 480 seconds]
saurabhg has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
ybogdano has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
toolchains has joined #dri-devel
ybogdano is now known as Guest3565
ybogdano has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Remote host closed the connection]
Guest3565 has quit [Ping timeout: 480 seconds]
technopoirot has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
pixelcluster has joined #dri-devel
gawin has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
karolherbst has joined #dri-devel
ybogdano is now known as Guest3566
ybogdano has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
technopoirot has quit [Ping timeout: 480 seconds]
Guest3566 has quit [Ping timeout: 480 seconds]
shashanks has joined #dri-devel
<zmike>
I assume someone has reported gitlab being crazy today?