02:08 bl4ckb0ne: is there a new release of waffle planned soon?
02:09 bl4ckb0ne: that wrapdb issue prevents me to finish the alpine package
04:09 imirkin: anholt_: re "is_bindless" check being silly for sampler/image -- i don't think it actually is. you can have a (uniform) block with a sampler2D which effective takes 0 space in that block -- that sampler gets "hoisted" to the top-level and allocated separately. but with bindless it would be in that block as expected.
04:10 imirkin: [but i'm happy to see those helpers move to common code...]
07:08 dolphin: bnieuwenhuizen: I was looking to get a notification when I'm mentioned in a comment
07:08 dolphin: I can now only see it when I login to GitLab
07:22 airlied: j4ni, ickle, dolphin : hey tip has a major i915 conflict, I don't feel capable of handling, anyone want to take a pass?
07:22 airlied: the mediatek one is trivial
07:23 dolphin: from backmerge?
07:34 Kayden: anholt_: thanks for mentioning ksim. I should have tried the simulator ages ago. the final SSBO write is definitely getting the wrong binding table index - it used to be 37, it now should be 29, but for some reason it is getting 74. that's not even remotely valid, so it's reading some out of bounds garbage as a descriptor and HDC looks at it and promptly goes nuts
07:34 Kayden: now to figure out where on earth 74 is coming from. :)
07:36 dolphin: airlied: hmm, seems like old conflicts, for some reason that has been a recurring theme for some time
07:36 dolphin: maybe rerere has got confused with the renames in the past couple months
07:41 Kayden: anholt_: err it's not even that, it's the very first sends instruction that's going bonkers
07:41 Kayden: (not send, sends)
07:43 dolphin: airlied: I'll grab some tea and give it a go
08:09 hakzsam: daniels: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1362567 seems stucked
08:24 hakzsam: daniels: it's fine actually, just way longer I thought
08:25 daniels: hakzsam: yes the t860 jobs are down to a single board due to infra issues
08:25 hakzsam: okay
08:37 Kayden: anholt_: Fixed /o\
08:38 Kayden: anholt_: your patch was, of course, fine
08:45 Kayden: anholt_: if you had indirect access to an image array, brw_fs_nir's image intrinsic handling would add binding_table.image_start to the register which held the image index. Sensible, but it actually *added it to that register*. Because, y'know, nobody would reuse the same SSA value in two places, right?
08:46 Kayden: really simple mistake, totally trivial fix
08:46 Kayden: of course, only happens on i965 because neither anv or iris use that codepath
08:46 Kayden: and only happens if you have indirects on image arrays
08:46 Kayden: and you use the same calculation elsewhere
08:53 dv_: hm any idea on when we can expect mesa 20 to be released? just curious
09:00 Kayden: honestly that's a good question
09:01 Kayden: dcbaker said that he wasn't doing 20.0, I think he said it was jasuarez or tanty or someone
09:03 hakzsam: yeah, I think we really need a calendar now, I would guess that branchpoint is ~end of january but who knows
09:04 tjaalton: 20.0 a month from now would be my wish
09:06 Kayden: going to be cutting it close if we don't branch soon
09:53 MrCooper: airlied: indeed, looks like TGSI is slightly slower actually :)
10:07 pq: *sigh* kernel Patchwork... most of my patch review emails are stored empty
13:10 emersion: because of the PGP signature maybe? :S
13:16 pq: emersion, sounds plausible
14:09 jekstrand: hakzsam, dj-death: I just assigned Marge to the ANV MR
14:09 hakzsam: ok
14:09 sravn: j4ni: push "drm/print: introduce new struct drm_device based WARN* macros" to drm-misc-next?
14:10 sravn: j4ni: So we can start using it, and start asking new drivers to use this
14:18 hakzsam: jekstrand: CI failed
14:19 hakzsam: turnip build failures apparently
14:19 jekstrand: Yeah
14:19 hakzsam: I didn't check that :P
14:19 jekstrand: Neither did I
14:19 jekstrand: Let me see if I can hack it up to build
14:20 jekstrand: We really should make entrypoint gen common
14:20 hakzsam: yep
14:22 dj-death: I was going to add "hopefully the header update won't break other drivers"
14:23 jekstrand: I'm very confused how it is
14:25 jekstrand: Ugh...
14:25 jekstrand: There's a vkCmdDrawIndexedIndirectCountAMD function
14:26 dj-death: oh another alias...
14:26 jekstrand: Yeah
14:26 jekstrand: I don't know why it's even in turnip's table
14:26 jekstrand: It's not in ours
14:30 linkmauve: danyspin97, airlied, linking to libOpenGL.so directly isn’t the only way to use OpenGL without the GLX dependency, you can also require EGL 1.5 or EGL_KHR_get_all_proc_addresses and load all symbols using eglGetProcAddress().
14:30 jekstrand: Yeah, turnip is based on a really old variant of ANV's codegen :(
14:30 jekstrand: Too old to fully understand entrypoint aliasing
14:31 linkmauve: danyspin97, but otherwise you have to build Mesa against libglvnd if you want a libOpenGL.so.
14:31 jekstrand: I'm going to hack turnip to claim 1.2 support
14:31 jekstrand: Seems easiest
14:31 GyrosGeier: isn't the GLX dependency kind of given if you want to have an X swapchain?
14:31 jekstrand: Easier than fixing their codegen anyway
14:32 linkmauve: GyrosGeier, sure, but someone could want to use DRM, Wayland, Surfaceless… instead.
14:33 linkmauve: It seems a bunch of people hate X11 so much they want to wipe even libraries they don’t use anyway from their system. :)
14:34 danyspin97: I have a Wayland only system
14:34 danyspin97: and that's exactly the reason xD (apart from hate for x11)
14:35 jekstrand: dj-death, hakzsam: This time for sure!
14:35 danyspin97: linkmauve: but there is no way to achieve retro compatibility, right?
14:36 danyspin97: i.e, use an application already linked to libGLX.so
14:36 karolherbst: danyspin97: XWayland
14:36 linkmauve: Yup, that.
14:36 karolherbst: but yeah, mesa then needs GLX support
14:37 danyspin97: I see :/
14:37 linkmauve: And GLX needs the rest of the Xlib.
14:37 karolherbst: well, fixing the applications is usually the best path forward (aka porting to SDL2)
14:37 karolherbst: or whatever toolkit was used for window management
14:37 danyspin97: I don't have XWayland for now to improve that part
14:38 danyspin97: I have to send a patch to freeglut when I find time to work on it
14:38 karolherbst: I doubt you still want to use freeglut though
14:39 jekstrand: hakzsam: Now I'm seeing build failures because radv's scripts aren't new enough. :-(
14:39 jekstrand: Looks like ANV is the only driver with scripts that can handle the 1.2 update :/
14:39 hakzsam: uhu
14:39 karolherbst: danyspin97: people are way more happy with using SDL2 these days. Most linux games are using that
14:39 danyspin97: I don't develop applications that use graphics, it is more a packager issue
14:39 linkmauve: danyspin97, Freeglut already works on Wayland though AIUI.
14:39 karolherbst: AIUI?
14:39 linkmauve: At least the Subversion version.
14:40 linkmauve: As I understand it.
14:40 danyspin97: freeglut-scm doesn't build without Xorg
14:40 hakzsam: jekstrand: let me have a look at radv
14:40 jekstrand: hakzsam: I think I've got it
14:40 danyspin97: but have Wayland support
14:40 jekstrand: no, I don't
14:40 linkmauve: Never tried to build it without Xorg, the only thing which matters to me is that it runs natively on Wayland. :)
14:40 jekstrand: hakzsam: I think we just need to merge everything manually and CI will be fine at the end
14:40 jekstrand: hakzsam: That or a combined branch
14:41 jekstrand: hakzsam: Is everything in your branch reviewed?
14:41 hakzsam: jekstrand: yes
14:41 danyspin97: thinking forward, if there will be a Wayland compositor for a Linux phone
14:41 jekstrand: hakzsam: I'm pulling your MR into mine
14:41 hakzsam: ok
14:41 daniels: danyspin97: those do exist
14:41 linkmauve: danyspin97, like the Pine phone, SailfishOS’s, KDE’s, and probably various other ones?
14:42 bl4ckb0ne: who handles the waffle release ?
14:43 jekstrand: hakzsam: The problem is vkCmdDrawIndirectCountAMD which is aliased to the non-KHR version.
14:43 jekstrand: hakzsam: The ANV scripts are able to handle it but the turnip and radv ones can't
14:43 danyspin97: daniels, linkmauve: Yes, and does it makes sense to have Xorg there?
14:43 hakzsam: jekstrand: this is something we have to fix then
14:44 danyspin97: the applications that runs are relatively new, and almost all have Wayland
14:44 jekstrand: hakzsam: That also means you're likely exposing an entrypoint you shouldn't be
14:44 karolherbst: danyspin97: you could patch freeglut to build without X
14:44 jekstrand: hakzsam: Well, I've got turnip hacked up to build and if I have your branch, radv builds
14:44 danyspin97: karolherbst: yea, I just need to find the time
14:44 hakzsam: jekstrand: great
14:44 danyspin97: I have only one big issue
14:44 jekstrand: hakzsam: But, yes, it needs to be fixed long-term.
14:44 linkmauve: danyspin97, most phones won’t have hardware support for modern OpenGL features anyway, at most GL 3.1 but already cheating a bit.
14:45 hakzsam: jekstrand: sure thing, I will have a look
14:45 danyspin97: i need to preload libEGL
14:45 karolherbst: why?
14:45 linkmauve: All phone applications using 3D will be written at GLES feature set.
14:45 linkmauve: Usually GLES 2.0 for maximum compatibility.
14:45 jekstrand: hakzsam: I think what we want to do is figure out how to pull the guts out of the ANV scripts and make them common
14:45 jekstrand: hakzsam: They're the most correct and they also have the capability for multi-versioned entrypoints
14:45 linkmauve: libGLESv2.so doesn’t carry this GLX dependency, so that’s fine.
14:46 jekstrand: hakzsam: We just need to figure out how to generalize them a tiny bit more.
14:46 jekstrand: We probably should have done this as part of turnip bring-up but -EPEOPLEARELAZY
14:46 linkmauve: If you care about phones, what you could do is help the desktop applications you care about work fine on GLES. :)
14:46 hakzsam: jekstrand: yeah :)
14:46 danyspin97: karolherbst: idk
14:46 danyspin97: some applications needs it to run
14:47 karolherbst: then those applications should be fixed
14:47 danyspin97: the other day was alacritty
14:47 danyspin97: I am not sure
14:47 danyspin97: it happened with gzdoom that uses SDL2, I filed a report to SDL2 about this
14:47 karolherbst: it's usually the applications fault
14:48 karolherbst: messing up linking or other weird stuff
14:48 jekstrand: hakzsam: Now that ANV properly only exposes entrypoints that are enabled, we can probably always codegen everything if that makes things simpler.
14:49 danyspin97: karolherbst: which is the fix?
14:49 karolherbst: don't link against gl libs
14:49 karolherbst: SDL2 already handles all of that itself
14:50 danyspin97: SDL2 have this problem
14:50 karolherbst: SDL2 dlopens
14:51 danyspin97: Ah, I see
14:51 danyspin97: I have musl
14:51 karolherbst: mhh, yeah.. could be some weird libdl thing going wrong
14:52 karolherbst: but SDL2 usually checks the environment and dlopens the proper gl libs it wants to use
14:52 karolherbst: I've written some gl apps with SDL2 with no linking to any gl libs and no egl/glx calls
14:52 karolherbst: and that works perfectly fine
14:52 danyspin97: i have alacritty runt with LD_PRELOAD
14:53 danyspin97: gzdoom needs it too
14:53 linkmauve: alacritty doesn’t use SDL2.
14:53 linkmauve: It uses glutin.
14:53 danyspin97: I know, but they share the same problem
14:54 linkmauve: Maybe your setup is the problem, try talking with whoever manages your distribution?
14:54 danyspin97: it's a source based with my custom flags
14:55 danyspin97: but it isn't a distribution problem imho
14:55 danyspin97: it's that with this setup, egl isn't loaded at all
14:56 karolherbst: mhh
14:56 karolherbst: running on wayland?
14:56 danyspin97: sway
14:56 karolherbst: weird
14:56 karolherbst: LD_DEBUG=libs ... might tell you something
14:57 karolherbst: maybe libEGL.so isn't found for ... weird reasons or so
14:57 danyspin97: libEGL.so isn't linked
14:57 karolherbst: doesn't matter if it's dlopened
14:57 danyspin97: in neither alacritty nor SDL2
14:58 danyspin97: dlopen has some problem on musl afaik
14:58 bl4ckb0ne: strace it to check what is dlopened
14:58 karolherbst: do they link against libGLX?
14:58 danyspin97: SDL is compiled without X support so no
14:58 karolherbst: bl4ckb0ne: you see that with LD_DEBUG as well
14:58 bl4ckb0ne: ah yeah, i always forgot this one
14:58 karolherbst: danyspin97: yeah, but if musl has problems with dlopen, then musl is broken and needs to be fixed
15:00 linkmauve: I haven’t had problems with musl in Void on my Wii U related to dlopen.
15:00 linkmauve: I can check if that’s relevant.
15:02 karolherbst: anyway, you should figure out whats wrong with the dlopen stuff, as this will probably fix all your issues
15:02 jekstrand: hakzsam, dj-death: Merged.
15:02 hakzsam: jekstrand: thanks!
15:02 kisak: congrats
15:03 danyspin97: karolherbst: I don't see any dlopen call
15:03 karolherbst: with strace? no wonder, you need ltrace for that
15:08 danyspin97: karolherbst: I've asked in #musl about dlopen
15:11 danyspin97: karolherbst: dlopen works in musl, so I guess this is related to Wayland setup
15:11 GyrosGeier: dlopen is usually just a thin wrapper around a function provided by ld-linux.so
15:11 GyrosGeier: or ld.so
15:12 GyrosGeier: so it can and will break if you're mixing C libraries
15:12 danyspin97: Can you please define mixing?
15:13 GyrosGeier: IIRC musl have their own libc
15:13 GyrosGeier: and their own dynamic linker, and these two work together
15:14 GyrosGeier: mixing would be "two different libc implementations in the same process"
15:15 bl4ckb0ne: isnt musl an implementation of libc?
15:15 GyrosGeier: that works well for things like malloc()/free(), because these just allocate from different pools, but it breaks down for dlopen(), because there is only one dynamic linker per process
15:16 danyspin97: bl4ckb0ne: yup
15:16 danyspin97: GyrosGeier: I am using a bootstrapped system so there is no miving
15:16 pcercuei: danyspin97: what's your problem?
15:16 pcercuei: TL/DR
15:17 bl4ckb0ne: found dlopen if you want to take a look https://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1984
15:17 danyspin97: pcercuei:applications that uses OpenGL such as SDL2 and alacritty needs LD_PRELOAD=libEGL.so to work
15:17 pcercuei: I reported (and send a patch) for this not so long ago: https://bugzilla.libsdl.org/show_bug.cgi?id=4891
15:17 danyspin97: otherwise, the display is failed to crraes
15:18 bl4ckb0ne: danyspin97: you're on alpine with sway right?
15:25 danyspin97: bl4ckb0ne: I am on Exherbo Musl
15:25 danyspin97: with sway
15:26 danyspin97: pcercuei: it is slightly similar
15:27 danyspin97: though the applications fail
15:29 bl4ckb0ne: i run alpine with sway on my laptop and i have no problem with sdl2 apps
15:36 pcercuei: danyspin97: the underlying bug might be the same. Since the "fix" in SDL2 was just swapping the order of loading the libraries, the actual bug might be in Mesa
15:37 danyspin97: bl4ckb0ne: I don't have Xorg though
15:38 danyspin97: pcercuei: I was thinking the same
15:38 pcercuei: same here, that was with the DRM/KMS backend of SDL2
15:38 danyspin97: It happens when a new Display is created
15:39 st3r4g[m]: could it be related to https://gitlab.freedesktop.org/mesa/mesa/issues/966 ?
15:41 danyspin97: st3r4g[m]: I don't think so
15:41 danyspin97: because there is no SIGSEGV related here
16:03 bl4ckb0ne: danyspin97: no xwayland ?
16:03 danyspin97: bl4ckb0ne: nope
16:03 bl4ckb0ne: oh wait wait wait
16:04 bl4ckb0ne: sdl is shitty with wayland
16:04 bl4ckb0ne: use SDL_VIDEODRIVER=wayland
16:04 bl4ckb0ne: i had that issue too
16:04 danyspin97: sdl works fine
16:04 danyspin97: apart from this
16:05 danyspin97: Ih this system almost everything works fine
16:06 danyspin97: I don't have Qt though
16:10 bl4ckb0ne: i need to find time to send SDL a patch about that wayland videodriver
16:14 danyspin97: bl4ckb0ne: are you using alpine?
16:14 bl4ckb0ne: yes
16:15 bl4ckb0ne: not currently though, i have it on my laptop at home
16:20 danyspin97: bl4ckb0ne: I don't like it, it actually doesn't care about the community
16:20 danyspin97: same with Void
16:21 MrCooper: bl4ckb0ne: IME SDL2 has issues with SDL_VIDEODRIVER=wayland as well, e.g. horrible colour banding (with neverball / neverputt)
16:23 linkmauve: MrCooper, if the issue is a mismatch between its GLX and EGL codepaths in ordering the fb configs, that’s part of the EGL spec.
16:24 linkmauve: It will give you RGB332 first if you ask for 1, 1, 1 instead of 8, 8, 8 when requesting the colour depth.
16:24 linkmauve: If my memory from my first port of anything to Wayland isn’t failing me.
16:31 bl4ckb0ne: danyspin97: idk, im satisfied so far
16:31 bl4ckb0ne: the wiki is lacking content but i had answers on the irc
16:36 daniels: linkmauve: nearly but not quite
16:36 daniels: 0 prefers smallest, >0 prefers largest of at least that value
16:36 daniels: so 1, 1, 1 would give you 10bpc
16:36 linkmauve: And 0, 0, 0 gives you 332?
16:37 linkmauve: Alright, so MrCooper you can increment these three variables in these two games to fix them. :)
16:40 bl4ckb0ne: sorry to re-ask the question, but who handles the release of waffle ?
16:41 MrCooper: linkmauve: thanks, but I'd rather leave that to bl4ckb0ne or someone else who cares more than me :)
16:41 linkmauve: Do they care about neverball and neverputt?
16:41 bl4ckb0ne: idk
18:48 anholt_: Kayden: thanks for tracking it down!
18:50 anholt_:is looking forward to getting back to turnip descriptors
18:55 imirkin_: Kayden: that's such an easy mistake to make =/ had my share of those with nouveau too
19:15 Kayden: anholt_: Yeah...sorry it took so long to figure out. The stupid thing is, I feel like I was closing in on that +45 the other day, but then convinced myself I'd just read the assembly wrong. :/
19:15 Kayden: the extra "simulator says you're reading way out of bounds" push to "no there really is a problem" helps
19:17 anholt_: I stared at that asm too, it was actually tricky.
19:17 Kayden: yeah, lots going on there
19:17 Kayden: it also helped to know the first sends was going wrong, so I could ignore the rest
19:17 anholt_: also, that test case is so upsetting to read.
19:18 Kayden: hehe, yes
19:18 Kayden: so many things in one test...and for a max resources test, it randomly picks ... 8
19:18 anholt_: "by 'max' we mean just the minmax from the spec, and we're not going to test them all just resource #0,5,7 or whatever."
19:18 Kayden: yeah
20:41 kisak: are the arm64 CI runners having a hard time?
20:41 kisak: (mesa gitlab)
20:49 kisak: n/m saw an active runner
20:54 anholt_: dcbaker: please use marge instead of setting automatic merge, it wastes CI resources that way.
20:55 anholt_: (though I guess on a stable branch, if you hand manage the merge queue then maybe it works out)
21:24 bnieuwenhuizen: anholt_: how does marge use less CI resources?
21:25 bnieuwenhuizen: oh nvm, by not interrupting the in progress marge thing
21:26 anholt_: by not having a thundering herd of devs pressing the button and having to rebase to win the race.
21:34 dcbaker: anholt_: I do use marge for master, for stable though there's usually ~1 MR a week and I just press automerge for the initial PR, so no rebasing needed
21:35 anholt_: another motivation is also to get the links back to the MR consistently appearing in the logs.
21:39 airlied:expects my vallium scripts are forked from broken ones, I'll have to rebase and test
21:39 imirkin_: heh. vallium. good name.