00:08 jenatali: Dunno though, when we registered the driver name it's a Mesa driver name prefix instead of MSFT
00:16 anholt: my understanding is: I would go with msft, spi should be for mesa submissions where there's no other adopter responsible for it.
00:16 Kayden: yeah
00:16 Kayden: I think it depends on who's doing the submission, mostly
00:17 Kayden: anv submissions are done by Intel employees, radv submissions typically aren't done by AMD folks
00:18 Kayden: if jenatali's involved it probably makes sense just to do MSFT
00:19 jenatali: Yeah makes sense
00:20 jenatali: We still need to talk to Khronos to define what conformance requires from a layered VK driver...
00:20 karolherbst: jenatali: isn't it like to run on two drivers?
00:21 jenatali: Except our legal group bars us from participating in working group meetings
00:21 karolherbst: ehh.. pass conformance on two
00:21 karolherbst: wat...
00:21 jenatali: karolherbst: it's defined for GL and CL that way
00:21 jenatali: VK isn't defined yet AFAIK
00:21 karolherbst: mhhh
00:21 jenatali: (I expect it'll end up the same, just needs to get into docs)
00:21 karolherbst: but you are not allowed to do that?
00:22 karolherbst: or maybe just submit the MR?
00:22 jenatali: Last time around we got special permission to set up meetings outside of the IP zone
00:22 karolherbst: uhhh
00:22 karolherbst: why is legal like this
00:22 jenatali: Yeah
00:24 Kayden: :(
00:26 jenatali: And then once I finish on WARP I need to get a second driver to conformance. Hopefully that's easy but who knows
01:45 karolherbst: dcbaker: soo.. in regards to that isystem situation with bindgen. Do you agree that the bindgen stuff needs to do something similar to what CLikeCompilerArgs.to_native does in regards to isystem arguments?
02:48 mareko: Venemo: can you please Rb https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22306 ?
10:30 Venemo: mareko: I'll take another look at it!
12:00 karolherbst: dcbaker: I hate it, but doing it properly looks like a serious amount of work: https://github.com/mesonbuild/meson/pull/11733 Any ideas on that?
13:49 Company: I need a GL/EGL expert, because versions of eglCreateContext() confuse me.
13:49 Company: if I want a GL - or actually: GLES - context as new as possible buit at least version 2, what do I pass to eglCreateContext()?
13:50 Company: because apparently, if I pass 2.0, ANGLE hands out 2.0 and Mesa hands out a 3.2 context
13:50 Company: even though they both support GLES 3
13:52 HdkR: Company: Make sure you eglBindAPI before eglCreateContext
13:53 Company: the code does that
13:53 linkmauve: Company, what I’ve seen programs do is request the most recent version they want to support, then one before that, then one before that, until the earliest one they support.
13:54 Company: it passes MAJOR_VERSION 2 attrib, but I thought that'd automatically give me 3 if available
13:54 HdkR: That too, you usually work your way backward from newest supported to oldest in your application. Changing the ctx_attrib flags as you go, and potentially channging the config you got from eglChooseConfig
13:55 HdkR: Since eglChooseConfig has an `EGL_RENDERABLE_TYPE` where you specify GL or ES
13:55 Company: yeah, I know that
13:55 Company: I'm just confused about versions and min vs max vs actual
13:56 Company: so there is no way to set a min/max and you're actually meant to try them all
13:56 HdkR: Also yes, if you're passing in a version ot eglCreateContext, you're not guaranteed to be automatically promoted to a newer version
13:56 linkmauve: Company, when you request a version, the driver can give you anything from that version up to the most recent compatible version.
13:56 Company: right, but it's the driver's choice?
13:56 HdkR: Which Angle might be respecting your decision when you chose version 2, but mesa EGL promotes
13:57 HdkR: That is yes
13:57 Company: because I want the most recent one
13:58 HdkR: Then you'll be wanting to pass in EGL_CONTEXT_MAJOR_VERSION, EEGL_CONTEXT_MINOR_VERSION, and if you are also wanting GL, EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE
13:58 HdkR: It's a big song and dance
13:59 HdkR: `The context returned must be the specified version, or a later version which is backwards compatible with that version. Even if a later version is returned, the specified version must correspond to a defined version of the client API`
13:59 Company: does that work the same with GLX and Apple and Windows GL, too?
13:59 HdkR: EGL Spec wording around this promotion
14:01 HdkR: Pretty sure
14:01 Company: looks like I'm gonna write some code then
14:01 Company: thx
14:06 HdkR: Luckily GL/ES is a slow lumbering beast at this point. So even if you hardcode every version you care about, it is unlikely to suddenly have a GL 5.0 or an ES 4.0 :)
14:21 Company: technically I think I could add code that queries the version via glGetString() and goes from there, but I'm not gonna do that, because then I need to figure out if that'a actually supported
15:16 Venemo: mareko: I've taken another look at the MR but it seems to me that there are still issues and now I agree with alyssa, it needs more consideration. also I would appreciate some input from gfxstrand
16:16 javierm: tzimmermann: I'm surprised that nobody ever cared about the bug you are fixing in patch #1
16:38 tzimmermann: javierm, IGT triggers it while writing near the EOF. i guess that all applications write near the beginning of the framebuffer
16:38 tzimmermann: and it also shows how this is all badly maintained and obsolete :(
16:38 gfxstrand: karolherbst, jenatali: Have either of you seen this problem with LLVM 16:
16:39 gfxstrand: : CommandLine Error: Option 'use-dbg-addr' registered more than once!
16:39 tzimmermann: thanks for reviewing, BTW
16:39 jenatali: gfxstrand: Yeah I saw some discussion about it a few days ago
16:39 jenatali: It's a Fedora 38 problem IIRC
16:39 gfxstrand: *sigh*
16:40 jenatali: gfxstrand: https://bugzilla.redhat.com/show_bug.cgi?id=2187824
16:41 gfxstrand: Hey, look! An LLVM update!
16:43 HdkR: LLVM updated and broke GPUs again. Surprised? :P
16:44 gfxstrand: Broke the mesa build, actually.
16:44 gfxstrand: But, yeah
16:44 HdkR: Nice
16:51 javierm: tzimmermann: you are welcome. Awesome cleanup tbh
16:51 javierm: I haven't noticed that there was that much duplicated code there
17:05 tzimmermann: javierm, i've got to leave. bye
17:06 MrCooper: gfxstrand: assuming /usr/lib64/libLLVMSPIRVLib.so is involved, should be fixed in current F38
17:07 MrCooper: (see https://bugzilla.redhat.com/show_bug.cgi?id=2187824)
17:08 gfxstrand: MrCooper: Yeah, I pulled an update and it's okay now.
17:08 gfxstrand: Somehow it got fixed between when I did my F38 upgrade yesterday late afternoon and this morning.
17:08 zmike: have to assume it was karolherbst working late at the pub
17:38 gfxstrand: Ugh... now my rust isn't compiling.
17:38 gfxstrand: What did this Fedora update do?!?
17:39 psykose: 'Option 'use-dbg-addr' registered more than once!' means the process loaded multiple llvm versions
17:40 psykose: i.e. you have one library linked to 15 and another to 16, linked to the same process, etc
17:40 karolherbst: zmike: I never touched that piece of software in my life
17:40 zmike: while sober*
17:41 penguin42: gfxstrand: Yeh there's a fix just went in
17:41 penguin42: gfxstrand: https://bugzilla.redhat.com/show_bug.cgi?id=2187824
17:42 HdkR: zmike: Some software just can't be worked on while sober
17:42 zmike: F A C T S
17:43 ccr: standardized required level of inebriation for working on X
17:44 gfxstrand:looks at chanel topic
17:56 gfxstrand: Gotta love how I have to update bindgen after an LLVM update....
17:57 karolherbst: I'd wished we could get rid of LLVM :)
18:01 gfxstrand: Ok, now that I've updated to F38 and fixed all the LLVM fallout, I feel like I should get a new CTS baseline.
19:32 anholt: should vk_common_GetPipelineCacheData be setting a nonzero count?
19:33 gfxstrand: should be
19:34 gfxstrand: Ugh... Looks like no one's incrementing count. :facepalm:
19:34 gfxstrand: I'm surprised CTS didn't at least warn on this.
19:34 gfxstrand: That's an old bug
19:35 anholt: we don't expose cts warnings from the deqp runner, and maybe we should be.
19:35 gfxstrand: IDK if there is a warning
19:36 anholt: (been staring at this function for https://gitlab.freedesktop.org/mesa/mesa/-/issues/8868)