00:00daniels: teething issues \o/
00:00daniels: if it's any consolation, I've been having some very very painful accustomisation to Windows over the past several months
00:35mareko: craftyguy: does intel plan to hook up some of its CI to gitlab?
00:36craftyguy: one day, but I'm not sure when I'll have time to yet
02:19krh: craftyguy: just a few systems would go a long way
02:19krh: It's daunting to consider moving the entire Intel ci
02:20krh: But just having a few gens in there would be awesome
02:20craftyguy: 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:21mareko: even 1 gen would be enough
02:22craftyguy: What exactly do you mean by 'hook up'?
02:22craftyguy: because that can mean a few things I think
02:23mareko: craftyguy: the same thing as what other drivers have done
02:39craftyguy: um, ok. I haven't looked at what they've done
02:42craftyguy: 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:44craftyguy: 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:52krh: Yeah upstream ci is a subset of all the tests run by intel ci
02:52krh: Mostly gles deqp
02:53krh: 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:58craftyguy: lots of people use the CI pre-merge
02:59craftyguy: 'the CI' == intel CI in my previous comment :P
03:04mattst88: 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:21jljusten: 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:59jekstrand: 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:00jekstrand: airlied: Did you have Intel patches for vec8/16 kicking around?
08:44airlied: jekstrand: hmm I kinda thought I landed them
08:47airlied: https://gitlab.freedesktop.org/airlied/mesa/-/commit/8fc137e8854ce3bfe0fb54dc18bf734b9c4c04b9 was maybe one
08:48airlied: not much other I can see
08:48airlied: https://gitlab.freedesktop.org/airlied/mesa/-/commits/sycl-env-hacks-shamrock/ was most of what I had from shamrock
10:50pendingchaos: jekstrand: no, it's not expected
11:36laomamama: hi,everyone .how can i update mesa driver in manjaro ?Thanks a lot I have download mesa 20.0.2.tar.xz
11:50jcdutton: Hi. Is there a way to use opencl on AMD Vega using something other than rocm?
14:54jekstrand: pendingchaos: I figured it out. I needed to run CSE and a few other opts between lower_io and the vectorizer
15:16LiquidAcid: 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:17LiquidAcid: glGetString() doesn't sound like that super complex entry point, so i'm wondering what goes wrong there
15:51janesma: Are AMD systems tested by the gitlab CI?
16:18janesma: 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:18MrCooper: janesma: not yet
16:18janesma: by contrast, there are 23 that were found by exhaustive testing:
16:19janesma: Categories of regressions that would NOT have been caught:
16:19janesma: Android: 2685,2584,2482,2129, 2113
16:19janesma: Piglit: 2106
16:19janesma: GL46: 2628, 2055, 2252
16:19janesma: Kernel bug: 2338
16:19janesma: 32bit build: 2001, 2415
16:19janesma: Vulkan: 1876, 2136,
16:19janesma: Ancient hardware: 1872, 2601, 2355, 2323
16:19janesma: Atom hardware: 2187, 1865, 2537
16:19janesma: webgl: 1986, 1916
16:19MrCooper: nobody's suggesting the GitLab CI could completely replace your own CI
16:20janesma: I think there is some confusion about the degree to which gitlab testing would reduce regressions.
16:21MrCooper: LiquidAcid: maybe it ends up with a core profile context (which doesn't have glGetString)?
16:21MrCooper: janesma: is there? 4 > 0 :)
16:21janesma: "Marge-bot accepts it" is not something that should be substituted for "check Intel CI"
16:23MrCooper: all anyone should be seriously suggesting is that the GitLab CI could prevent some regressions from landing on master
16:23MrCooper: which should make a big difference in those cases
16:26janesma: we would get more value for less work by simply adding an android build test to gitlab.
16:27janesma: which does not detract from the value that intel/deqp would have in gitlab CI, but also our engineers are already overworked.
16:33MrCooper: sure, somebody should add an Android job as well
16:33janesma: that would help us, because then we wouldn't have to maintain it here.
16:33MrCooper: although then people might complain about that instead of SCons
16:37LiquidAcid: MrCooper, thanks for the hint; should MESA_GL_VERSION_OVERRIDE help in that case?
16:37janesma: 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:37janesma: all the orange builds would have been kicked back.
16:40MrCooper: 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:37jekstrand: janesma: Get more of what value?
17:39tango_: 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:39tango_: oh I think I know why, I didn't have the correct firmware at boot time
17:40tango_: MrCooper: thanks for pointing it out, I can see the device now 8-)
17:49janesma: jekstrand: there would be fewer post-merge regressions identified by intel CI if gitlab CI had a basic android build test.
17:49jekstrand: janesma: Sure. I wouldn't mind seeing an android build test.
17:49mattst88: yeah, moving/replacing the android build test from Intel's CI to gitlab would actually make a ton of sense
17:50tango_: now I only need to understand why I get such abysmal performance (12GB/sec) on an rx580
17:50jekstrand: Feel free to set one up
17:50janesma: 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:51jekstrand: janesma: Sure, no one is claiming that the level of CI we're doing internally can be effectively done with GitLab
17:52imirkin: 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:54jekstrand: imirkin: Yeah, but that's about all we could do.
17:55jekstrand: And even there, it whouldn't be a replacement for running on the actual CI
17:56imirkin: of course not
17:56mattst88: imirkin: that's a fair point
17:56imirkin: it just seems like events like that basically kill your farm
17:56jekstrand: 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:56imirkin: which then puts all of you into emergency mode
17:56jekstrand: Yeah, I'd like to have a smoke test personally
17:57jekstrand: I'd like to have RADV with and without ACO smoke tests too
17:57jekstrand: There's a lot of value in "does this change cause anyone's compiler to explode?
17:57imirkin: 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:57jekstrand: Like when you add a new opcode that you're pretty sure you lowered away
17:57jekstrand: imirkin: We don't have the hardware to be able to do that
17:57jekstrand: imirkin: Old hardwdare is too hard to come by
17:58imirkin: ok. well do it for the gens you have lots of :)
17:58imirkin: it doesn't have to be perfect, just something that helps prevent pain.
17:58jekstrand: We've got a giant pile of BDWs somewhere
17:59imirkin: 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:59imirkin: anyways, just throwing out ideas - i have no dog in this "fight"
18:03jekstrand: It's just that once we get beyond a single-gen smoke-test, you're very quickly getting into "run the whole farm"
18:03imirkin: afaik you run many per gen
18:04imirkin: 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:04krh: If we dropped the legacy driver we wouldn't have to test legacy hw...
18:04jekstrand: That sounds like a lot of work
18:04imirkin: e.g. is gen7 much different than gen9, as it interacts with core infra? dunno.
18:04imirkin: i kinda assume not though
18:04imirkin: but gen6 is pretty different
18:05jekstrand: The problem is that every gen has something
18:05imirkin: ok. then i'm wrong :)
18:05jekstrand: gen6 to gen7 is all the features. 7 to 8 you loose vec4, etc.
18:05krh: If we went with mareko's plan for splitting dri driver off, we'd only be testing gen8+
18:05jekstrand: I mean, if you did gen4, 6, and 9, it'd probably be decent coverage
18:06jekstrand: krh: I'm not convinced mareko's plan works. :-(
18:06imirkin: 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:06jekstrand: Yeah, we could probably come up with something
18:07krh: 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:08imirkin: 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:08imirkin: (and again, not THAT often, but maybe once a year or so?)
18:09jekstrand: krh: Oh, I fully agree. I just don't know how to reduce churn in a way that's actually acceptable to people.
18:11krh: I think an lts release and then dropping i965 is feasible
18:12krh: I forget what the objections to that were, but it would work well for us
18:13jekstrand: I don't think we can drop IVB/HSW for a little while yet
18:14jekstrand: But SNB and below I wouldn't feel bad about
18:14krh: Drop in what sense?
18:14jekstrand: Or we can just keep delaying these questions for another year and then I won't feel bad about droppping Gen7
18:14krh: Is ther anything that you're planning to add for those gens?
18:14jekstrand: If it's living in a legacy branch, it won't get much attention at all
18:14jekstrand: They still get the odd improvement
18:15krh: Or your just concerned that you won't maintain them in an lts branch?
18:15jekstrand: And, more importantly, we have a lot of HSW users yet
18:15jekstrand: But will that really change in another year?
18:15jekstrand: I guess the big thing is that I think I'll care less 12 months from now. :-P
18:15krh: But how many bugs do you get that aren't the result of some refactor for a newer gen?
18:16jekstrand: Not a lot typically
18:16krh: How much trouble would those drivers be if you didn't mess with them?
18:16jekstrand: Most of it is in the compiler and unless we want to completely drop HSW Vulkan, we don't save anything there.
18:17jekstrand: And HSW Vulkan is still getting new features. :-/
18:17krh: What if the lts branch was more of a common upstream for downstream to share what fixes they have?
18:18krh: Hmm you could keep hsw vulkan but still split out i965
18:19jekstrand: Yeah, but then we have to keep all of vec4 :(
18:20jekstrand: 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:22krh: Or any of us, even yourself
18:23krh: Nir changes, glsl changes etc
18:23jekstrand: Most of the misc breakage that's super-painful is the src/mesa/main changes
18:23jekstrand: NIR/glsl changes tend to be fine, break everything, or break everything vec4.
18:23jekstrand: It's fairly uncommon for them to break gen6 but not gen7
18:24jekstrand: And if we want to keep Gen7 Vulkan going, we don't get saved there.
18:24mattst88: 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:24mattst88: 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:25jekstrand: Yeah, I'd also like to give iris about a year in distros before we completely side-line i965
18:25jekstrand: That's the other reason to wait
18:26mattst88: 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:33krh: Right dropping individual gens from i965 doesn't make sense
18:34krh: I don't think distros necessarily need to switch to iris before i965 goes into maintenance
18:36krh: 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:05ccr: distro packagers will probably like that a lot :P
19:07krh:is a distro packager
19:22airlied: krh: is there packages? :)
19:22airlied: or did you mean you still have fedora account and will fix it up :-P
19:37krh: airlied: I know ebuild!
19:42tango_: as a user, I would like to point out that I still have HSW hardware
19:42tango_: (on one machine) so ongoing support for it would be appreciated, possibly in a not-too-convoluted way ;-)
19:47HdkR: Just never upgrade your packages ever again :)
20:40imirkin: as another user, my (only) laptop is SNB
20:41imirkin: 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.