00:00lrusak: jkqxz, yea I'm aware that I can do something with shaders, it would just be nice if mesa handled that natively with shaders :)
00:08jkqxz: lrusak: Then I think you're out of luck, because GPU APIs don't offer formats where the data is packed in the low bits at all.
00:12mareko: it looks like glthread has to have its own instance of the vbo module for fast immediate mode
00:16mareko: it's probably not a good idea to push all vertex data through the glthread queue
00:19jekstrand: Venemo: Bad enum ordering
00:20Venemo: jekstrand: can we do anything about it, or will it always need to be a special case?
00:20lrusak: jkqxz, I'm just wanting the ability to import YUV420P10 like we can with YUV420 :)
00:21jekstrand: Venemo: Uh... ¯\_(ツ)_/¯
00:23lrusak: jkqxz, is it possible to specify NV12 or P010 for ffmpeg sw decoders?
00:25Venemo: ok jekstrand sorry for bugging you with it
00:27jekstrand: Venemo: No worries
00:33jkqxz: lrusak: Only if the specific decoder offers it, which they generally don't. (P010 in particular it not a sensible format for CPU operations.)
00:34lrusak: yea so that's the problem :(
00:48jekstrand: pendingchaos: How do I prevent nir_opt_load_store_vectorize from turning an 8-bit vec4 store with an alignment of 1 into a 32-bit scalar store?
00:49pendingchaos: should be possible to do in the callback
00:49pendingchaos: return false if the bit_size argument is 32 and low/high are 8-bit stores
00:50karolherbst: doesn't it make more sense to have this as a core part of the pass? because if the alignment doesn't fit the combined load/store there is no point combining it anyway, no?
00:51karolherbst: or is there hardware being able to deal with that nonetheless?
00:51pendingchaos: if the alignment is the issue, you can compare the alignment with bit_size in the callback
00:52pendingchaos: AMD hardware can do some 64-bit loads with a 4-byte alignment
01:03mareko: AMD hw thinks it's loading an array of 32-bit values
01:05karolherbst: mareko: how is it perf wise then? I would kind of expect not much of a difference between 64 and 2x32 loads then, except maybe getting rid of issuing latency or something
01:07jekstrand: pendingchaos: Can it also split loads/stores?
01:12mareko: karolherbst: the hw has to be able to load 4x32 bits for formatted buffers and images; the hw usually loads whole cache lines, the slowdown starts when the load straddles 2 cache lines
01:12karolherbst: I see
01:32airlied: lols who knew user cull, then clipping then face cull was the order, draw definitely didn't
01:34imirkin: what would be sensitive to that? pipeline stats?
01:34airlied: imirkin: piglit test clip-cull-4
01:35airlied: I've wondered for years why it was broken :-P
01:35tarceri: how does one do a merge when panfrost ci is failing to upload whatever it is trying to upload?
01:36imirkin: hm, right
01:36imirkin: coz if any of the prim is culled, the whole thing is culled
01:36imirkin: if you do clipping first, then a prim might not get culled
01:41airlied: tarceri: furiously ping daniels
01:41airlied: then submit an MR to disable panfrost, there are likely many examples
01:42airlied: daniels: &&
01:45tarceri: ok thanks
03:03mareko: airlied: does draw do guardband culling or view clipping?
03:04mareko: user cull being the first is not a good idea
03:05mareko: actually, any clipping being before any culling is not a good idea
03:06mareko: culling removes primitives, so you want that first; clipping can add primitives
03:23airlied: mareko: no guardband at all
03:23airlied: viewport clipping
03:29mareko: airlied: that's bad
03:34airlied: it's got a TODO :-P
03:34mareko: airlied: the ideal case is to never do viewport clipping: if a primitive is completely outside, cull; if it intersects the border, keep it; if it intersects the border and the guardband boundary, clip it if hw doesn't support vertices outside the guardband
06:21tomeu: tarceri: retrying should help
06:21tomeu: will investigate
06:31tomeu: oh, I see that you retried a lot of times
06:31tomeu: that's quite some data
06:39tomeu: daniels: several jobs to our lab failed several times in this pipeline: https://gitlab.freedesktop.org/tarceri/mesa/pipelines/125042/builds
06:39tomeu: a bunch due to gitlab not finding the artifacts from the build stage, and the others due to the http connection to LAVA timing out without clear cause
06:40tomeu: an ideas?
06:41tomeu: looks like the jobs started failing due to the http connection timeouts, and at some point the reason for the failure switched to be that the artifacts from the previous job weren't found
07:01tarceri: tomeu: hehe yeah 2/3 jobs worked after retrying but the last one seems really stuck
07:04tomeu: yeah, I think meson-arm64 needs to be retried first, so the artifacts are available
07:04tomeu: no idea why it's failing to find it
07:04tomeu: unless you have been retrying past the artifacts expiration period of 4 weeks ;)
08:44daniels: tomeu: you can't retry your way out of the artifact failure, you need to retry the upstream job which generates the artifacts first, but then it should work. that's a transient issue we still haven't really diagnosed yet.
08:44daniels: the HTTP stuff, no idea - if it's cloning git repos and fetching artifacts then the network for the runner is working fine, so it's probably on our side? is gtucker doing the upgrade?
08:45tomeu: yeah, that's what I referred by meson-arm64
08:45tomeu: the upgrade is about to start, but that happened while slept
08:46tomeu: this has started to happen right when we moved the runner to packet, so was wondering about a firewall closing the connection after a while, etc
08:46daniels: actually, armhf, not arm64
08:46daniels: since it's t760 failing
08:49daniels: but no, there's no kind of firewall or anything that I've ever heard of
08:54tango_: sorry if this isn't the right channel, but: does clover's opencl work without X running?
13:26MrCooper: tango_: yes it does
13:26MrCooper: (requires /dev/dri/render* nodes being available)
13:27daniels: for anyone with CI pipelines failing due to not copying the Windows Docker tag, !4346 fixes so you'll need to rebase when it lands
13:29MrCooper: just leave it to Marge :)
13:34kisak: hmm, at this point I'm out of ideas on getting a viable mesa 20.0 + llvm 10 build. Dies with http://dpaste.com/04RXJ5V.txt
13:35kisak: I tried the lighter mitigation cherry picked by debian ( https://github.com/llvm/llvm-project/commit/d21664c ) and the bit more substantial backport set at https://github.com/NixOS/nixpkgs/pull/81819/commits/3a84353edb56a6167fb687f2fdc32cab48a65079
13:35gitbot: NixOS issue (Pull request) 81819 in nixpkgs "llvmPackages_10: rc2 -> rc3" [10.Rebuild-Darwin: 1-10, 10.Rebuild-Linux: 1-10, Closed]
13:36kisak: anyone happen to look at this "undefined reference to `getPollyPluginInfo()'" llvm issue?
13:38kisak: (building without opencl would avoid the issue, but not suitable for what I'm doing)
13:44MrCooper: kisak: you should ask LLVM folks, Mesa doesn't directly do anything with Polly
14:15arora: jekstrand tlwoerner: Hello, I have uploaded the GSoC draft, kindly review it and provide feedback.
14:16jekstrand: Yeah, I saw it. Honestly, I think it mostly looks fine. The time scale is longer than I thought but that's probably fine
14:16jekstrand: arora: You mentioned that your school is out right now with no idea when it will reconvene
14:17jekstrand: arora: Do you think it's likely that you'll have to go back to school to finish mid-summer?
14:17jekstrand: If so, we'll deal with it somehow
14:22arora: Yes, I will have to go back to school to write my semester examinations.
14:23arora: jekstrand: There's rumours floating around that they might shrink our summer holidays (from may to august) to just august maybe.
14:23jekstrand: Are you planning, then, to just try to get a head start now while school is out?
14:23jekstrand: If so, I think that should work ok
14:23jekstrand: I expect GSoC will be flexible given the current worldwide situation
14:24arora: jekstrand: Yes, I was thinking of a head start, I was reading this currently: https://www.x.org/wiki/Events/XDC2016/Program/ekstrand_vulkan.pdf
14:26arora: They should be, but there's no such update on their update.
14:26arora: Maybe since this activity occurs remotely, they might not be so flexible with it.
14:27arora: *there's no update on the website. oops.
14:35pq: arora, a tip for git: use any of the graphical git history viewers to see what you have and where you are at. I'm personally a 'gitk --all' addict.
14:35imirkin: what does --all do?
14:35pq: shows all branches and tags, not just the branch you are on
14:35imirkin: ah neat!
14:35imirkin: i use gitk a lot too
14:36imirkin: never knew about that
14:36imirkin: although tbh it doesn't really fit my use-case -- usually i want to look at a range of commits anyways
14:36pq: the next best thing I have is a git alias: logt = log --graph --decorate --color=auto --oneline --all
14:38arora: jekstrand: Any changes that I should make to the draft?
14:42emersion: nice alias
15:00MrCooper: argh, symbols-check.py fails without python2 installed on Debian
15:06karolherbst: what's python2? :p
15:07karolherbst: mhh, but that script should run with python3 as well, no? I guess you simply have no python symlink pointing to the python3 interpreter
15:07arora: pq: Are graphical ones better?
15:07arora: emersion: thanks
15:09MrCooper: karolherbst: exactly
15:10MrCooper: should that just be changed to python3? Mesa already requires Python 3, right?
15:11karolherbst: guess it would make sense to see what other scripts used in the build do
15:12karolherbst: ahh ehh.. yeah well. doens't matter
15:12MrCooper: there are all three variants, obviously
15:18karolherbst: yeah.. but I was just more wondering about breaking builds
15:19jekstrand: arora: Draft looks pretty good TBH. One comment though: Vulkan is spelled with a "k". It's wrong on the title of your submission but right in the draft document.
15:19karolherbst: okay sooo
15:19karolherbst: MrCooper: we don't call symbols-check.py with an python interpret
15:19karolherbst: but directly
15:20karolherbst: I'd convert it to do something similiar like we do for the nir code gen
15:20karolherbst: and use prog_python
15:21karolherbst: this way we can do whatever in the script as it will be ran with the python3 interpreter in the build anyway
15:21karolherbst: MrCooper: did you call the script directly or thorugh the normal meson build?
15:21MrCooper: the latter
15:21karolherbst: okay.. yeah
15:21karolherbst: then I guess we should run it with an interpreter like we do for other scripts
15:22karolherbst: just do the same as we do with install_megadrivers
15:22karolherbst: and use python3 hardcoded :)
15:22arora: jekstrand: oops, corrected that.
15:23MrCooper: anyway, leaving that to someone who actually knows Python
15:26jekstrand: arora: Other than that, the draft looks pretty good IMO
15:29arora: jekstrand: thank you :)
17:19vsyrjala: review anyone https://patchwork.freedesktop.org/patch/350385/?series=72484&rev=1 ?
17:29kusma: jekstrand: hmm, is there a reasonable way of lowering 8-bit arithmetics to 16 or 32-bit in nir? I tried cooking up something (while lowering) myself, but that's starting to look really dodgy.
17:31pendingchaos: kusma: nir_lower_bit_size()
17:31kusma: pendingchaos: thanks!
17:31pendingchaos: I'm currently trying to fix imul_high/umul_high and shifts and make the pass create less conversion operations
17:31pendingchaos: so that it can be used for all arithmetic
17:32kusma: How did I miss that one? :-P
17:32jekstrand: Oh, right... that's a thing.
17:32jekstrand: I forgot about that
17:34jekstrand: pendingchaos: Yeah, we likely need something which can detect patterns like i2i16(iadd(i2i32(x), i2i32(y))) and turn it into iadd
17:34jekstrand: Possibly just some nir_opt_algebraic rules that do i2i16(iadd(x@32, y@32)) -> iadd(i2i16(x), i2i16(y))
17:35jekstrand: We already have rules to clean up i2i16(i2i32(x))
17:39pendingchaos: I'm currently trying to detect the patterns inside the pass
17:39pendingchaos: along with lowering phis to 32-bit if possible
17:39pendingchaos: we can then run the pass very late in ACO and avoid rerunning divergence analysis (we only want to lower uniform ALU)
17:40jekstrand: ah, that makes sense
17:41pendingchaos: not sure how to deal with iadd(i2i32(x), ...)
17:41pendingchaos: x is a 32-bit value in the backend, but we have to mask it with 0xff/0xffff
17:41pendingchaos: even though iadd doesn't care
17:42pendingchaos: *mask or sign extend
17:42dschuermann: pendingchaos: don't put too much effort into avoiding rerunning divergence analysis. it's a quite cheap pass (especially with the refactoring MR <- jekstrand :P )
17:44dschuermann: maybe we can also improve a second run by not resetting the information. I don't think that a divergent value becomes uniform in most passes, so maybe a metadata flag can ensure that
17:57jekstrand: pendingchaos: I've added an ACO patch to that MR. If someone could do some quick testing, that'd be nice.
17:57jekstrand: None of the desktop drivers are in the GitLab CI. :-(
18:00hakzsam: jekstrand: I'm going to give it a try with radv/llvm in a few minutes
18:00jekstrand: hakzsam: Thanks!
18:00jekstrand: hakzsam: LLVM should hopefully be fine since it uses lower_bool_to_int32
18:01jekstrand: For ACO, I had to write an ACO patch.
18:01hakzsam: yeah, I think so, I'm just going to do quick testing
18:02pendingchaos: I'm not sure if the CTS has any boolean shared memory tests btw
18:02pendingchaos: crucible might have a couple
18:07kusma: pendingchaos: thanks, that does the trick. I still need to hack around some i2i8/u2u8 opcodes, but that seems much more tolerable...
18:07pendingchaos: jekstrand: func.compute.shared-memory.* passes with ACO with aco_instruction_selection_setup.cpp updated
18:08jekstrand: pendingchaos: cool. With my update or some other?
18:10pendingchaos: with your commit and aco_instruction_selection_setup.cpp updated
18:10pendingchaos: _setup.cpp doesn't seem to have to be updated for them to pass, but the tests probably aren't covering some cases
18:11jekstrand: pendingchaos: Ok, cool. If you give me the _setup.cpp patch, I'll squash it in
18:11pendingchaos: maybe _setup.cpp doesn't have to be updated for this to work
18:11pendingchaos: I think it should be though
18:12pendingchaos: jekstrand: https://pastebin.com/raw/LGvq4kPV
18:13jekstrand: pendingchaos: Applied, thanks.
18:18kisak: FWIW, I got lucky reading llvm's commit log and unblocked myself
18:28sravn: vsyrjala: while touching all the logging, could we migrate to drm_ based logging. Would require drm_dbg_kms(aux->crtc->dev, "...
18:29sravn: vsyrjala: And we have only two users of DRM_DEBUG_KMS_RATELIMITED() - could be good to kill this one
18:29hakzsam: jekstrand: nothing to report, looks good :)
18:30vsyrjala: sravn: i expect a mass conversion to device based logging in the core/helpers at some point
18:33sravn: vsyrjala: yep, but why not when touching a lot of logging anyway to ease the migration-
18:34sravn: vsyrjala: If DRM_DEBUG_KMS_RATELIMITED is replaced, for example by drm_err_ratelimited then a-b from me
18:34vsyrjala: because i already wrote the patch before the device based logging was a thing
18:36sravn: Ohh, it is from the 23th of January. Thats before covid-19 was a thing... Still a quick refresh should be doable
18:39vsyrjala: git says i actually wrote it in may of last year :P
18:53danvet: sravn, btw working on devm_drm_dev_alloc, it's pretty
19:12sravn: danvet: way behind on reviews, but looks forward to next patch series anyway
19:59kaairagupta: Hey..Is there a standard way to represent a drm fourcc + modifiers as a human-readable string??
20:01emersion: kind of
20:02emersion: printf("%.4s", (uint64_t)modifier);
20:02emersion: note, it's not guaranteed to yield printable chars
20:02bnieuwenhuizen: why .4?
20:03emersion: err, more like printf("%.4s", (char *)&modifier);
20:03pinchartl: emersion: we're looking for a way to print a human-readable string for the whole format, fourcc + set of modifiers
20:03emersion: also it's endian-dependant
20:03pinchartl: and ideally something that would be short :-)
20:03emersion: many fourcc codes are 4 printable chars
20:03emersion: hence the name
20:04pinchartl: the 4CC part is fine, adding the modifiers is a bit more annoying
20:04pinchartl: there can be up to 4 of them
20:04pinchartl: and they're just numbers
20:04emersion: oh, modifiers
20:04bnieuwenhuizen: pinchartl: all 4 have to be the same right?
20:04vsyrjala: only one modifier
20:05pinchartl: only one ?
20:05emersion: sorry, completely missed the question then
20:05pinchartl: * To accommodate tiled, compressed, etc formats, a
20:05pinchartl: * modifier can be specified. The default value of zero
20:05pinchartl: * indicates "native" format as specified by the fourcc.
20:05pinchartl: * Vendor specific modifier token. Note that even though
20:05pinchartl: * it looks like we have a modifier per-plane, we in fact
20:05pinchartl: * do not. The modifier for each plane must be identical.
20:05pinchartl: * Thus all combinations of different data layouts for
20:05emersion: please keep this for yourself: https://github.com/ascent12/drm_info/blob/master/fourcc.py
20:05pinchartl: * multi plane formats must be enumerated as separate
20:05pinchartl: * modifiers.
20:05pinchartl: I've understood this as meaning we can have up to 4 modifiers for a given format
20:06vsyrjala: it just means that if modifier!=modifier[n] the kernel will tell you to away
20:06pinchartl: emersion: how secret does it have to be ? :-)
20:06pinchartl: vsyrjala: ok, I had misunderstood it then
20:06emersion: it's secret because i'm not proud of it :)
20:06pinchartl: why are there 4 then ?
20:07vsyrjala: four is a lucky number?
20:07pinchartl: emersion: :-)
20:07pinchartl: vsyrjala: so it means that we can't apply one modifier that would describe tiling, and another one that would describe compression ?
20:08pinchartl: that severely limits usability :-S
20:08vsyrjala: yes, you will need both in the same modifier. if you're brave you can try to partition your modifier bits into orthogonal parts
20:08emersion: modifiers are opaque anyway
20:08bnieuwenhuizen: pinchartl: which is why people tend to parametrize their modifiers :)
20:09pinchartl: ok, we'll have to parametrize the modifiers for the bayer formats then
20:09pinchartl: that's good to know
20:11vsyrjala:convinced murphy will make an appearance eventually wrt. parametrization
20:11pinchartl: oh yes it will :-S
20:11imirkin: 64 bits should be enough for anyone
20:12ascent12: -8 bits for the vendor, but that's still plenty
20:13vsyrjala: the main question is how many do you reserve for the eventual "we got the parametrization wrong -> need new namespace"
20:13imirkin: vsyrjala: that'll be vendor 255.
20:14vsyrjala: probably shouldn't waste precious vendor bits for that
20:14bnieuwenhuizen: I'm a fan of just sticking a version number in there :P (or at least leaving a sufficient number of bits to be reserved as zeroes to make one)
20:18pinchartl: vsyrjala: for bayer, we currently have Intel-specific layouts, and compression schemes defined by MIPI. both need to be combined in the same modifier
20:18hakzsam: meson-window-vs2019 failure https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/2091053
20:26sravn: kaairagupta: the is drm_get_format_name() but you only get support for big or little endian
20:33krh: parameterization is the wrong knee jerk approach
20:33krh: you blow out a combinatorial amount of your modifier space
20:34krh: in reallity the space will be very sparsely populated and I recommend just enumerating the combination that will actually be used
20:35emersion: a big switch isn't that worse than many small switches
20:36emersion: krh: what's the reason you want to get rid of usage flags btw?
20:36emersion: do you think usage should be encoded in modifiers?
20:37emersion: how do you suggest gbm understands i want to allocate a buffer for scan-out?
20:37krh: the usage flag means that there has to be one place (gbm) that knows what every usage flag implies for every piece of hw on the system that might use the buffer
20:37krh: it's not composable at all
20:38emersion: gbm uses mesa anyway
20:38emersion: the user-space driver knows about this stuff
20:38krh: it perhaps practical if you're building a device (say... a chromebook) and you know what all the hw pieces in there are
20:38krh: but for a generic solution that ships in a generic distro on all the hw out there... it's not a practical solution
20:39krh: the mesa driver knows what the 3d hw can do
20:39emersion: gbm needs to know whether to allocate memory that can be scanned out or not
20:39jekstrand: Is it just me or is GitLab CI hosed right now?
20:39krh: it knows nothing about what video codec, video capture, scanout etc might require
20:39emersion: hmm, okay. why no pass this info to the kernel then?
20:40krh: I'm not saying the current system works, but adding the use flags back in is a step back
20:40emersion: how so? it's an implementation detail whether mesa or the kernel handles usage flags
20:41emersion: gbm will need to know about this anyway
20:41krh: no, that's exactly the point
20:41krh: having one component that needs to know about all the requirement from all the hw parts that might use a buffer doesn't work
20:41emersion: how do you allocate scan-out-able memory with gbm if gbm doesn't know it should be scan-out-able?
20:42emersion: mesa doesn't need to know, mesa can just ask the kernel
20:42krh: the intention with the modifiers was that you could go and ask the APIs for various consumers and producers (kms, gl, libva, v4l2) what their requirements were
20:44krh: they'd answer by returning a list of modifiers for the specific use case ie: "if I want to scanout YUV 90 degree rotated on this crtc, which modifiers do you support?", or "which modifiers can the encoder consume for RGBA8 buffers?")
20:45krh: and then you go find the common subset, which gives you a smaller list of modifiers that all your consumers and producers can agree on
20:46krh: and yes, this misses the contiguous allocation requirement
20:46krh: and similar "placement restrictions"
20:46krh: USE_SCANOUT is meaningless
20:47emersion: do you mean it's not enough?
20:47krh: once you start trying to y-flip, rotate, use compression etc... anything except "single fullscreen framebuffer per crtc" you're going to run into a ton of special cases
20:48krh: can I use compression with USE_SCANOUT? yes, but only one plane on one crtc
20:48krh: can I use linear with USE_SCANEOUT? yes, but not if you want to rotate the plane
20:49krh: can I use Intel Y_TILED with USE_SCANOUT? yes, but only if you don't hit the watermark limits
20:49emersion: so what you're saying is that it would be better to get the "requirements" from somewhere, then pass thes to KMS?
20:50emersion: so what you're saying is that it would be better to get the "requirements" from somewhere, then pass thes to gbm?
20:50krh: I don't have a good solution
20:51emersion: so, just watch the world burn?
20:51krh: my favorite answer is to not care about devices with contiguous allocation requirements :-P
20:52krh: but if not that, then I'd suggest adding some kind of allocation constraint argument to gbm
20:52krh: use flags are just to vague
20:52emersion: i see
20:53krh: placement constaint, I mena
20:53emersion: are there previous attempts at doing that apart from liballocator?
20:53krh: or some kind of heap concept, perhaps, like what vulkan has
20:54jekstrand: There's also alignment contraings which need to be communicated
20:54krh: 4k should be enough for everybody ;-P
20:54jekstrand: 64k pages forever!
20:54jekstrand: Not just placement alignment but also pitch alignment
20:57jekstrand: We just have the one LINEAR modifier but different people have different pitch requirement
20:58jekstrand: In the Vulkan WSI and mesa EGL code for prime, we just say "256 is good enough for everyone" and hope for the best.
21:01imirkin: jekstrand: 64k is not enough pages.
21:01jekstrand: imirkin: You want those 1M huge pages, don't you?
21:01imirkin: it was amusing to see the various patches fixing 4TB systems since they went over 32bit-of-4k pages.
21:02imirkin: jekstrand: alternate interpretation... 64k pages
21:02imirkin: i.e. 65536 pages.
21:18jekstrand: daniels: Something is seriously weird with GitLab CI and LAVA
21:19jekstrand: daniels: https://gitlab.freedesktop.org/jekstrand/mesa/-/jobs/2093301
21:19daniels: jekstrand: go on
21:19daniels: jekstrand: thanks
21:19jekstrand: daniels: All my CI jobs are failing with stuff failing to transfer or LAVA errors
21:21che: Heyyas. I am building mesa git with lto enabled against llvm git on the upcoming fedora 32 (gcc-10.0.1-0.9.fc32.x86_64). Now in that constellation everything *GL dies. See https://paste.centos.org/view/597c84d3 , vkcube works like a charm though :)
21:24che: I guess I will start a new build and turn off LTO to crosscheck if that makes it work.
21:25daniels: jekstrand: yeah, the BayLibre lab (narmstrong) has all its boards offline apparently; now crash-merging something to disable that particular job
21:28anarsoul: daniels: lima jobs passed, I had impression that boards for lima are also based in BayLibre lab
21:30jekstrand: anarsoul: I think the radv crash is real
21:30jekstrand: anarsoul: The panfrost one it says to contact the LAVA admins
21:31pendingchaos: radv crash might be https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4335
21:31pendingchaos: *might be fixed with
21:32jekstrand: pendingchaos: Yeah, that looks like what I'm seeing in CI
21:32daniels: anarsoul: it's not the whole lab that's unhealthy, it's specifically the t820 boards
21:32anarsoul: I see
21:32narmstrong: daniels: the lava worker seems to be broken
21:33daniels: narmstrong: fun :\
21:33narmstrong: It’s a different worker for the t820 and Lima boards
21:33narmstrong: daniels: I told the guy in charge to look
21:34daniels: thanks :) when it is back good, just reenable it in a MR and assign directly to Marge
23:10robclark: daniels: I think vs2019 build is not working? At least the build error seems to be unrelated to anything in my MR.. https://gitlab.freedesktop.org/robclark/mesa/-/jobs/2094897
23:11daniels: robclark: please retry, will fix properly tomorrow
23:12robclark: ok.. I reassigned to marge already (assuming it was some other MR that marge picked up at the same time before realizing vs2019 was new)
23:56daniels: robclark: thanks & sorry