00:00karolherbst: the vtn code is less scary than the nir pass though
00:04jenatali: karolherbst: I was just skimming the image-related fixes from working through the CTS and only one of them was relevant to upstream code, everything else was in our lowering passes. I updated the upstream MR with it
00:13karolherbst: cool thanks
00:14jenatali: I should really go grab the rest of the core changes I've made and start sending them upstream
00:37jekstrand: karolherbst: Oh, for pushing the structurizer? I thought you'd already done it.
00:37jekstrand: karolherbst: But now I know you haven't......
00:38karolherbst: I still didn't do the vtn changes you asked for :p
00:38jekstrand:doesn't remember what he asked for
00:38karolherbst: one pass instead of two pass approach
00:38jekstrand: Yeah, I seem to recall something about that
00:39karolherbst: at least I ported over to the new switch helpers :p
00:39karolherbst: but didn't push it yet
00:40karolherbst: guess I will try to do all of that until the end of the week
00:41jekstrand: Ok. I'm basically not around until next week anyway and I'll probably have a lot of back-log
00:41jekstrand: But feel free to ping when you want me to look again
00:41karolherbst: cool, thanks
00:42mattst88: lol, the windows build didn't time out this time
00:42mattst88: > WARNING: Failed to load system CertPool: crypto/x509: system root pool is not available on Windows
00:43mattst88:gives up for today
00:47jekstrand:kind-of wants to just turn off the Windows build tests
00:47jekstrand: They fall over a lot
00:48airlied: yeah they don't seem to be adding a lot of value at present
00:49mattst88: yesterday after reassigning to marge 3 or 4 times it succeeded and merged
00:49mattst88: but today, no such luck
00:51airlied: mattst88: that seems like a new type of fail
00:53mattst88: I'm pretty confused about !3559. it keeps reporting that "Someone canceled the CI."
00:54mattst88: maybe it's just getting confused about a particular kind of CI failure, but it's strange that I haven't seen that happen in other MRs like !5566
01:20airlied: mattst88: might be worth just merging that one
01:22mattst88: airlied: frustratingly, I told gitlab to retry that one failed windows build... and it passed
01:22mattst88: so I'll try assigning to marge one more time and then I'm going to push it
01:23mattst88: nice. it just merged immediately. I assume because CI was green and it didn't need to rebase
01:27mattst88: my MR changes stuff only in src/intel/compiler, but it's still doing a build test on windows :(
01:28airlied:prepares to throw llvmpipe gl 4.0 at ci
01:35tarceri: ElBarto: I think it would be safe to tell your users classic swrast is deprecated. This thread sums up the future fate of all classic drivers https://lists.freedesktop.org/archives/mesa-dev/2019-December/223852.html I dont think anyone is actively maintaining classic swart at this point
01:39tarceri: to summarise the thread it's only really i965 that is keeping all classic drivers from being forked off into their own repo, but given the success of iris that could change
02:02tarceri: karolherbst: I'm trying to enable -Wimplicit-fallthrough project wide should the following code have a /* fallthrough */ comment or should there be a break here: https://gitlab.freedesktop.org/tarceri/mesa/-/blob/master/src/gallium/drivers/nouveau/nv30/nv30_texture.c#L242
02:04imirkin: tarceri: fallthrough expected.
02:06tarceri: imirkin: thanks
07:25daniels: mattst88, jekstrand, airlied, anholt: btw our CI policy is really clear - if something is unstable or flaking or otherwise getting in everyone's way, then you're all very much empowered to insta-disable it; the only requirement is that you use sensible judgement (like 1 in 100 failing is not cause to disable, but 1 in 10 is); all you need to do is to notify the person responsible so they can get it fixed and re-enable
07:25daniels: when it's less broken
07:26daniels: I've disabled Windows now (well, when Marge merges)
09:01daniels: anholt_: long a630-es3 run https://gitlab.freedesktop.org/mesa/mesa/-/jobs/3401617
09:40danvet: pinchartl, nag on drm/atomic-helper: reset vblank on crtc reset
09:40danvet: pinchartl, https://firstname.lastname@example.org/
09:41danvet: lynxeye, [PATCH 3/8] drm/imx: Use __drm_atomic_helper_crtc_reset <- can you ack this one pls?
09:50lynxeye: pH5: ^^
10:19karolherbst: jekstrand, pmoreau: we might want to have a shared place of reporting supported spir-v extensions by vtn. Right now we don't really bother with any of that except for OpenGL, but we also need to know that for clover
10:19karolherbst: do we want to have a vtn function reporting all the extensions or how do we want to deal with it?
10:31pinchartl: danvet: sorry haven't had time yet :-S
10:49danvet: lynxeye, pH5 thx
10:49danvet: pinchartl, should I just merge?
10:50danvet: apparently the bugfix in there is the biggest offender syzkaller hits right now, would be nice to get it sorted
10:50danvet: syzkaller on vkms
10:50danvet: I just wanted to fix it all since not really anyone is using vkms aside from testing
11:19pinchartl: danvet: looking at it now
11:27pinchartl: danvet: reviewed
11:40danvet: pinchartl, thx
14:19jekstrand: karolherbst: We add them one-by-one to the client drivers.
14:20jekstrand: karolherbst: OpenGL is the only API where you can query SPIR-V extension strings AFAIK
14:20jekstrand: Everywhere else, SPIR-V extensions are accessed through an API extension with it's own (likely similar) name
14:31MrCooper: mattst88: Marge can't (re-)start the CI pipeline if she doesn't need to rebase, that's why she just kept pointing out the fact that somebody had cancelled https://gitlab.freedesktop.org/manu/mesa/-/jobs/3388028 (presumably because it was hanging and about to time out anyway)
14:32MrCooper: basically, if Marge doesn't need to rebase, one has to make sure the pipeline either has passed or is running before assigning the MR to her
15:21karolherbst: jekstrand: when are the nops supposed to be removed?
15:23karolherbst: okay, assumed vtn cleans it up but now that I structurize inside spirv_to_nir I see those :)
15:23karolherbst: anyway, already implemented the more explicit goto/goto_if stuff and that seems to be able to make a few things much easier actually
16:06mattst88_: MrCooper: ah, okay, thanks. that behavior is unexpected to me, but I'll keep that in mind
16:55karolherbst: jenatali: mind giving my new structurizer branch a try? I did some changes which could break stuff
16:55karolherbst: just wanting to me sure everything is alright before continuing
17:05jenatali: karolherbst: I should be able to get it to it next week
17:06jenatali: If you don't hear from me just remind me to do it
17:59Lyude: danvet: btw, I remember we talked about this w/r to selftest for the drm vblank work stuff. Do you know if anyone's been planning on coming up with more mock frameworks for drm?
18:00danvet: Lyude, so aside from being buried in way too many ideas myself already, I was kinda waiting for kunit to grow some more mocking infra first
18:00Lyude: danvet: gotcha
18:00danvet: so that we wouldn't have to then convert it all over again
18:00Lyude: yeah, makes sense
18:00danvet: we have a bunch of mock objects all over already
18:01danvet: but with a bit more real framework doing stuff like "give me a counter when this hook is called" and similar, could be a lot easier
18:01danvet: Lyude, btw my comments on the vblank stuff all ok? kinda felt bad for another round of small nits :-/
18:02Lyude: danvet: oh yeah-actually ben's already pulled stuff into their tree, they're just finishing up a pretty significant refactor of some of the disp code in nouveau
18:02danvet: so a few fixup patches for the nits?
18:02Lyude: (also your comments were helpful :)
18:03danvet: or did I miss the latest round?
18:03Lyude: danvet: I think you missed the latest round, I def addressed all the nits you had
18:04danvet:really badly out of the loop on everything :-/
18:04Lyude: hehe, np
18:05Lyude: i'm still looking for some folks to help review all the igt stuff i've got btw if you know anyone else who might be interested, going to send out a poke to the igt-devel list today
18:05danvet: Lyude, hwentlan or niklaus mayb?
18:06Lyude: danvet: good idea!
18:06danvet: Lyude, yeah found v8 now, looks all really tidy
18:07Lyude: hwentlan-btw, if you have stuff needing review i'm always up for trades :)
19:05linkmauve: Hi, is there any way to disable desktop GL using an environment variable, to expose only GLES to the application?
19:09imirkin: MESA_GL_VERSION_OVERRIDE=0.0 maybe?
19:13mattst88: I'm interested to know the story here...
19:16imirkin: i'd imagine an application that supports both desktop and ES, and wanting to test the ES path?
19:16imirkin: without messing with the application
19:16linkmauve: Yes, exactly.
19:17imirkin: setting the override to 0.0 doesn't seem to do anything
19:17imirkin: but you can set it to 1.0
19:17imirkin: and hope that the application wants something ever-so-slightly more modern
19:18linkmauve: ContextCreationFailed(BadMatch) :(
19:18linkmauve: Maybe if I remove both libGL.so and libOpenGL.so?
19:19imirkin: shouldn't matter
19:19imirkin: libEGL is more than capable of providing desktop
19:19imirkin: libGL is more about GLX than it is about GL
19:19imirkin: (ok, yeah, it also exposes linkage for the varous core gl functions, bla bla bla)
19:27TheRealJohnGalt: You can force it by selectively moving those libs and then setting the usual mesa path env flags and LD_LIBRARY_PATH to the new folder. I've tested it in the past before.
19:27TheRealJohnGalt: to the new folder ahead of usual LD_LIBARARY_PATH*
19:31imirkin: that presumes that you've built mesa without desktop GL support (somehow, is that even possible?)
19:50karolherbst: imirkin: you can even build mesa without GL support :p
19:51karolherbst: but yeah.. gles only also works
19:51imirkin: but can you with GLES but not GL? not sure.
19:51imirkin: how do you even specify that?
19:52imirkin: ah =]
19:53karolherbst: but seems like meson errors out on that.. mhhh
19:53karolherbst: but it seems like most of the meson code is written like opengl being optional
19:55imirkin: and is "opengl" separate from "opengles"?
19:55imirkin: we have gles1/gles2 enables
19:55imirkin: but i think that's to make libGLESv1/v2
19:55imirkin: as opposed to core support
19:55karolherbst: we also have this: "with_any_opengl = with_opengl or with_gles1 or with_gles2"
19:56karolherbst: and also shared-glapi code checking if we have two things enabled, etc...
19:56imirkin: it's a solid mess then. excellent.
19:56karolherbst: it seems like everything is potentially in place
21:12nifker: Does nouveau not support Vulkan?
21:12airlied: nope not yet
21:55zf: but when it does, it'll be called nouveaulkan, right?
22:01airlied: novk is what it is right now :-P
22:06ccr: vulveau .. umm ..
22:13linkmauve: Hmm, indeed, meson.build:142:4: ERROR: Problem encountered: building OpenGL ES without OpenGL is not supported.
22:24mattst88: linkmauve: I suspect that could be fixed
22:43dcbaker[m]: Without glvnd it would be a lot of work, with glvnd it might need possible without any other changes
22:51mattst88: yeah, doesn't seem worth bothering with the non-glvnd configuration to me
22:59airlied: linkmauve: might be easier to just hack in an env var to disable GL context somehow