00:00 daniels: teething issues \o/
00:00 daniels: if it's any consolation, I've been having some very very painful accustomisation to Windows over the past several months
00:35 mareko: craftyguy: does intel plan to hook up some of its CI to gitlab?
00:36 craftyguy: one day, but I'm not sure when I'll have time to yet
02:19 krh: craftyguy: just a few systems would go a long way
02:19 krh: It's daunting to consider moving the entire Intel ci
02:20 krh: But just having a few gens in there would be awesome
02:20 craftyguy: well what I was thinking about is just wiring up some way to trigger the intel CI from gitlab, not convert anything into runners
02:21 mareko: even 1 gen would be enough
02:22 craftyguy: What exactly do you mean by 'hook up'?
02:22 craftyguy: because that can mean a few things I think
02:23 mareko: craftyguy: the same thing as what other drivers have done
02:39 craftyguy: um, ok. I haven't looked at what they've done
02:42 craftyguy: a quick read of the 'hw expectations' here leads me to believe that the intel CI runs too many tests to meet these expectations: https://gitlab.freedesktop.org/mesa/mesa/-/tree/master/.gitlab-ci
02:44 craftyguy: anyways, I do hope to look at this more in depth later. the intel CI is a large system, and there's a pile of work I have in the pipeline already :/
02:52 krh: Yeah upstream ci is a subset of all the tests run by intel ci
02:52 krh: Mostly gles deqp
02:53 krh: But having an Intel system in there in the pre-commit ci would probably take a lot of load off your internal, post conmit ci
02:58 craftyguy: lots of people use the CI pre-merge
02:59 craftyguy: 'the CI' == intel CI in my previous comment :P
03:04 mattst88: I don't doubt there's value in having intel systems in the gitlab CI, but I think the number of systems you have to get into the gitlab CI to get over the hump so that it's a net-win when you consider the reduced load on post-commit CI is large
03:21 jljusten: yeah, I can't see how it'll ever help reduce post-commit testing. still, preventing a merged regression seems like a net-win. and, if something more core-ish regresses intel, isn't it likely to affect multiple gens? so, maybe just a newer gen so it has more enabled features.
03:59 jekstrand: pendingchaos: So... the mem vectorize pass seems to do a whole lot less for me if I run it after nir_lower_io than if I run it before. Is this expected?
04:00 jekstrand: airlied: Did you have Intel patches for vec8/16 kicking around?
08:44 airlied: jekstrand: hmm I kinda thought I landed them
08:47 airlied: https://gitlab.freedesktop.org/airlied/mesa/-/commit/8fc137e8854ce3bfe0fb54dc18bf734b9c4c04b9 was maybe one
08:48 airlied: https://gitlab.freedesktop.org/airlied/mesa/-/commit/7b2241a7610a45cf64423affd6f00b51d6301d90
08:48 airlied: not much other I can see
08:48 airlied: https://gitlab.freedesktop.org/airlied/mesa/-/commits/sycl-env-hacks-shamrock/ was most of what I had from shamrock
10:50 pendingchaos: jekstrand: no, it's not expected
11:36 laomamama: hi,everyone .how can i update mesa driver in manjaro ?Thanks a lot I have download mesa 20.0.2.tar.xz
11:50 jcdutton: Hi. Is there a way to use opencl on AMD Vega using something other than rocm?
14:54 jekstrand: pendingchaos: I figured it out. I needed to run CSE and a few other opts between lower_io and the vectorizer
15:16 LiquidAcid: maybe someone can give me a hint here: i'm trying to get the old ut2004 to run with wayland, using sdl12-compat; now i'm getting a (non-descriptive) segfault in libgldispatch; build glvnd with debug and still the same segfault but no information where; i manually went through the callstack and i can see that the application is calling _ZN19UOpenGLRenderDevice11glGetStringE before everything goes south
15:17 LiquidAcid: glGetString() doesn't sound like that super complex entry point, so i'm wondering what goes wrong there
15:51 janesma: Are AMD systems tested by the gitlab CI?
16:18 janesma: mattst88, krh: I only see 4 regressions written up in gitlab's issue tracker that could have been caught by minimal intel dEQP testing in gitlab: 1938, 2002, 2410, 2128
16:18 MrCooper: janesma: not yet
16:18 janesma: by contrast, there are 23 that were found by exhaustive testing:
16:19 janesma: Categories of regressions that would NOT have been caught:
16:19 janesma: Android: 2685,2584,2482,2129, 2113
16:19 janesma: Piglit: 2106
16:19 janesma: GL46: 2628, 2055, 2252
16:19 janesma: Kernel bug: 2338
16:19 janesma: 32bit build: 2001, 2415
16:19 janesma: Vulkan: 1876, 2136,
16:19 janesma: Ancient hardware: 1872, 2601, 2355, 2323
16:19 janesma: Atom hardware: 2187, 1865, 2537
16:19 janesma: webgl: 1986, 1916
16:19 janesma:
16:19 MrCooper: nobody's suggesting the GitLab CI could completely replace your own CI
16:20 janesma: I think there is some confusion about the degree to which gitlab testing would reduce regressions.
16:21 MrCooper: LiquidAcid: maybe it ends up with a core profile context (which doesn't have glGetString)?
16:21 MrCooper: janesma: is there? 4 > 0 :)
16:21 janesma: "Marge-bot accepts it" is not something that should be substituted for "check Intel CI"
16:23 MrCooper: all anyone should be seriously suggesting is that the GitLab CI could prevent some regressions from landing on master
16:23 MrCooper: which should make a big difference in those cases
16:26 janesma: we would get more value for less work by simply adding an android build test to gitlab.
16:27 janesma: which does not detract from the value that intel/deqp would have in gitlab CI, but also our engineers are already overworked.
16:33 MrCooper: sure, somebody should add an Android job as well
16:33 janesma: that would help us, because then we wouldn't have to maintain it here.
16:33 MrCooper: although then people might complain about that instead of SCons
16:37 LiquidAcid: MrCooper, thanks for the hint; should MESA_GL_VERSION_OVERRIDE help in that case?
16:37 janesma: I would also expect complaints from marge-bot kicking back merge requests due to intermittent failures on intel hardware. It's not easy to prune out all the noise:
16:37 janesma: https://mesa-ci.01.org/mesa_master/builds/
16:37 janesma: all the orange builds would have been kicked back.
16:40 MrCooper: people are used to that from the ARM HW test jobs; not the same as a SCons/Android job which consistently fails when the corresponding build system files aren't updated
17:37 jekstrand: janesma: Get more of what value?
17:39 tango_: MrCooper: OK for some reason my amdgpu driver wasn't loading properly, hence I didn't have the /dev/dri/render* nodes. unloading and reloading it fixed it
17:39 tango_: oh I think I know why, I didn't have the correct firmware at boot time
17:40 tango_: MrCooper: thanks for pointing it out, I can see the device now 8-)
17:46 MrCooper: cool
17:49 janesma: jekstrand: there would be fewer post-merge regressions identified by intel CI if gitlab CI had a basic android build test.
17:49 jekstrand: janesma: Sure. I wouldn't mind seeing an android build test.
17:49 mattst88: yeah, moving/replacing the android build test from Intel's CI to gitlab would actually make a ton of sense
17:50 tango_: now I only need to understand why I get such abysmal performance (12GB/sec) on an rx580
17:50 jekstrand: Feel free to set one up
17:50 janesma: by comparison, spinning up intel hardware for dEQP smoke testing (and dealing with intermittent failures and hardware issues etc) would not identify as many regressions with the Marge-bot process.
17:51 jekstrand: janesma: Sure, no one is claiming that the level of CI we're doing internally can be effectively done with GitLab
17:52 imirkin: every so often a change is made which breaks like 50% of tests on intel. you could have something for that scenario, and not for the "it only breaks this one test, on m32, on a platform that was never released" case
17:54 jekstrand: imirkin: Yeah, but that's about all we could do.
17:55 jekstrand: And even there, it whouldn't be a replacement for running on the actual CI
17:56 imirkin: of course not
17:56 mattst88: imirkin: that's a fair point
17:56 imirkin: it just seems like events like that basically kill your farm
17:56 jekstrand: For instance, mareko's recent glthread MR. It busted piles of Intel stuff but only on Gen6 and earlier because what it broke was SW primitive restart.
17:56 imirkin: which then puts all of you into emergency mode
17:56 jekstrand: Yeah, I'd like to have a smoke test personally
17:57 jekstrand: I'd like to have RADV with and without ACO smoke tests too
17:57 jekstrand: There's a lot of value in "does this change cause anyone's compiler to explode?
17:57 imirkin: i think having one runner per gen, subject to hw availability, feels reasonable. but i don't know the state of your CI farm.
17:57 jekstrand: Like when you add a new opcode that you're pretty sure you lowered away
17:57 jekstrand: imirkin: We don't have the hardware to be able to do that
17:57 jekstrand: imirkin: Old hardwdare is too hard to come by
17:58 imirkin: ok. well do it for the gens you have lots of :)
17:58 imirkin: it doesn't have to be perfect, just something that helps prevent pain.
17:58 jekstrand: We've got a giant pile of BDWs somewhere
17:59 imirkin: and if you only have like one gen4, and gen4 keeps getting broken without the other platforms being broken, then you can re-evaluate, maybe buy some on ebay :) but i don't think that's the majority case.
17:59 imirkin: anyways, just throwing out ideas - i have no dog in this "fight"
18:03 jekstrand: Yeah
18:03 jekstrand: It's just that once we get beyond a single-gen smoke-test, you're very quickly getting into "run the whole farm"
18:03 imirkin: afaik you run many per gen
18:04 imirkin: and using your knowledge of feature breakdowns, you could probably reduce it to a handful of gens based on differences in interactions with core meas
18:04 krh: If we dropped the legacy driver we wouldn't have to test legacy hw...
18:04 jekstrand: That sounds like a lot of work
18:04 imirkin: e.g. is gen7 much different than gen9, as it interacts with core infra? dunno.
18:04 imirkin: i kinda assume not though
18:04 imirkin: but gen6 is pretty different
18:05 jekstrand: The problem is that every gen has something
18:05 imirkin: ok. then i'm wrong :)
18:05 jekstrand: gen6 to gen7 is all the features. 7 to 8 you loose vec4, etc.
18:05 krh: If we went with mareko's plan for splitting dri driver off, we'd only be testing gen8+
18:05 jekstrand: I mean, if you did gen4, 6, and 9, it'd probably be decent coverage
18:06 jekstrand: krh: I'm not convinced mareko's plan works. :-(
18:06 imirkin: i just know that for nouveau, testing one gpu in the tesla series and one gpu in fermi-or-later would get us to a huge amount of coverage as far as core infra goes.
18:06 jekstrand: Yeah, we could probably come up with something
18:07 krh: jekstrand: if we can't find hw for testing, maybe it's time to consider how much churn is reasonable for those old gens
18:08 imirkin: 100% coverage? definitely not. and in truth, i'd want both fermi and kepler, since kepler [and later] is bindless which is its own ball of wax. and yeah, on occasion we get bugs that take down one specific gen. but ... i remember this happening like once or twice in the past (wow) 7 years. not a big deal. a lot more often, the whole thing is just broken.
18:08 imirkin: (and again, not THAT often, but maybe once a year or so?)
18:09 jekstrand: krh: Oh, I fully agree. I just don't know how to reduce churn in a way that's actually acceptable to people.
18:11 krh: I think an lts release and then dropping i965 is feasible
18:12 krh: I forget what the objections to that were, but it would work well for us
18:13 jekstrand: I don't think we can drop IVB/HSW for a little while yet
18:14 jekstrand: But SNB and below I wouldn't feel bad about
18:14 krh: Drop in what sense?
18:14 jekstrand: Or we can just keep delaying these questions for another year and then I won't feel bad about droppping Gen7
18:14 krh: Is ther anything that you're planning to add for those gens?
18:14 jekstrand: If it's living in a legacy branch, it won't get much attention at all
18:14 jekstrand: They still get the odd improvement
18:15 krh: Or your just concerned that you won't maintain them in an lts branch?
18:15 jekstrand: And, more importantly, we have a lot of HSW users yet
18:15 jekstrand: But will that really change in another year?
18:15 jekstrand: I guess the big thing is that I think I'll care less 12 months from now. :-P
18:15 krh: But how many bugs do you get that aren't the result of some refactor for a newer gen?
18:16 jekstrand: Not a lot typically
18:16 krh: How much trouble would those drivers be if you didn't mess with them?
18:16 jekstrand: Most of it is in the compiler and unless we want to completely drop HSW Vulkan, we don't save anything there.
18:17 jekstrand: And HSW Vulkan is still getting new features. :-/
18:17 krh: What if the lts branch was more of a common upstream for downstream to share what fixes they have?
18:18 krh: Hmm you could keep hsw vulkan but still split out i965
18:19 jekstrand: Yeah, but then we have to keep all of vec4 :(
18:20 jekstrand: I guess part of the issue here is that I'm looking at it from a "how much code do I have to maintain?" perspective. The answer may be different if it's more of a "what is mareko likely to break with common core changes?" question
18:22 krh: Or any of us, even yourself
18:23 krh: Nir changes, glsl changes etc
18:23 jekstrand: Most of the misc breakage that's super-painful is the src/mesa/main changes
18:23 jekstrand: NIR/glsl changes tend to be fine, break everything, or break everything vec4.
18:23 jekstrand: It's fairly uncommon for them to break gen6 but not gen7
18:24 jekstrand: And if we want to keep Gen7 Vulkan going, we don't get saved there.
18:24 mattst88: FWIW, I'm supportive of the idea of an LTS Mesa release and then dropping i965 from master, but I do *not* want to drop individual Gens from i965 piecemeal
18:24 mattst88: I do *not* want to have to ship multiple LTS Mesas because we dropped Gen <= 6 in XYZ version and Gen <= 7 in XYZ+1 version
18:25 jekstrand: Yeah, I'd also like to give iris about a year in distros before we completely side-line i965
18:25 jekstrand: That's the other reason to wait
18:25 mattst88: yep
18:26 mattst88: the corollary there is that you don't actually save that much from dropping half of the supported Gens compared to dropping the whole driver
18:26 jekstrand: yup
18:33 krh: Right dropping individual gens from i965 doesn't make sense
18:34 krh: I don't think distros necessarily need to switch to iris before i965 goes into maintenance
18:36 krh: If your supporting pre-gen8 (or don't plan to switch your pre-tgl fleet to iris) you'll have to ship both Mesa lts and Mesa master
19:05 ccr: distro packagers will probably like that a lot :P
19:07 krh:is a distro packager
19:21 ccr:bows respectfully
19:22 airlied: krh: is there packages? :)
19:22 airlied: or did you mean you still have fedora account and will fix it up :-P
19:37 krh: airlied: I know ebuild!
19:42 tango_: as a user, I would like to point out that I still have HSW hardware
19:42 tango_: (on one machine) so ongoing support for it would be appreciated, possibly in a not-too-convoluted way ;-)
19:47 HdkR: Just never upgrade your packages ever again :)
20:40 imirkin: as another user, my (only) laptop is SNB
20:41 imirkin: don't really care if it gets the latest and greatest features, but esp given the recommendation to move away from xf86-video-intel, the GL stuff has to keep working well.