00:04 jenatali: gfxstrand: I don't know too much about what Vulkan can do, but DXIL at least can do 4-component vectors of 16bit, 32bit, 64bit for SSBOs, and 16-byte UBO (4-component 32bit, 2-component 64bit, 8-component 16bit)
00:04 jenatali: UBOs need to always be 4-byte-aligned currently
00:05 jenatali: But yeah I think just letting the callback return 0 makes more sense
00:10 gfxstrand: jenatali: So would you want it to take a (bit_size, num_components) pair as input, then? So you can tell the difference between a u8vec4 and a u32?
00:10 jenatali: gfxstrand: It doesn't matter as long as it has alignment
00:10 gfxstrand: kk
00:10 gfxstrand: Ugh... I'm now remembering why I made it in bytes
00:11 jenatali: At 1-byte alignment, we can load nothing :P, at 2-byte alignment we can load up to 8 bytes, etc
00:11 gfxstrand: jenatali: Ah, makes sense.
00:12 gfxstrand: jenatali: Well, with the latest version of that MR (Yeah, I know, I keep adding stuff), you can look at a 1B alignment and 6B of data and say "use a u32vec4" and it'll do all the things.
00:12 gfxstrand: jenatali: No support for doing that via stores yet. You'll have to write that.
00:13 jenatali: Yeah, I'll port the stores aspect over
00:13 jenatali: ... eventually
00:13 jenatali: Today's been crazy, you good if I re-review on Monday?
00:15 gfxstrand: Oh, sure
00:15 gfxstrand: It's 6PM here anyway
00:17 jenatali: Cool. I'll probably forget, but feel free to ping me (or just push more stuff to it so I get emails about it again :P)
00:24 gfxstrand: kk
15:47 alyssa: "[Zink and MoltenVK would] also finally bring OpenGL 4.6 support to macOS, which is currently held back to OpenGL 2.1."
15:47 alyssa: no they wouldn't
15:52 kchibisov: macOS OpenGL is 4.1 if it matters.
15:53 jenatali: Even with compat?
15:53 kchibisov: it's 2.1, 3.3, or 4.1.
15:53 kchibisov: Basically you have 3 such flags when building a context.
15:54 kchibisov: The macOS CGL is pretty bad API.
15:57 kchibisov: jenatali: https://learn.microsoft.com/en-us/dotnet/api/appkit.nsopenglprofile?view=xamarin-mac-sdk-14
15:57 jenatali: Right so the only compat version the legacy one?
15:57 kchibisov: yes.
15:58 jenatali: Which explains the remark in the X-Plane blog
15:58 jenatali: Since they apparently rely on compat
15:58 kchibisov: At this point they can use ANGLE if they want something old?
15:58 zmike: they exposed the entirety of the desktop GL api for plugins to use
15:59 zmike: ANGLE is irrelevant
16:00 jenatali: Yep. Similar reason we picked Mesa instead of ANGLE, even though we had ANGLE experts
16:01 hch12907: ANGLE exposes only GLES, no?
16:01 kchibisov: Yeah, I lack context of what you want with macOS. Though, there's an MGL which targets 4.6 on macOS, sad it's a different API.
16:03 zmike: mesa 💪
16:04 jenatali: zmike: agreed
17:26 bwidawsk: How does the kmsro kms_fd normally get setup? It looks like it should be automatic, but I can't seem to figure it out
17:30 bwidawsk: vc4 seems to be the only driver with a specific path for it
17:36 DavidHeidelberg[m]: Please check this magnificent beast MR. It's about using sections trough all devices, builders, runners.. etc. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20272 (CI passed in mine fork, now it's running in the mesa/mesa)
17:39 DavidHeidelberg[m]: I would love to merge it monday, tuesday, since it's complex and needs rebasing against main often :)
17:41 bwidawsk: like, what's supposed to call kmsro_drm_screen_create()?
17:42 bwidawsk:is lost in drm-helper magic
19:07 robclark: bwidawsk: see drm_helper.h
19:30 bwidawsk: robclark: I still don't see how it's supposed to get called
19:31 robclark: from pipe_kmsro_create_screen()
19:32 robclark: ptr to that ends up in a `struct drm_driver_descriptor`
19:35 cmeissl[m]: Hi, bwidawsk is helping me understand if and how direct scan-out should work for wayland clients when etnaviv is in use on the i.mx6. So far I can tell that dmabuf feedback is sending a scan-out tranche with linear and the driver re-allocates from a tiling format to linear. But in the compositor the call to drmModeAddFB2 with the imported buffer from gbm always fails (drm log shows "Failed to lookup GEM object"). PIPE_BIND_SCANOUT is set
19:35 cmeissl[m]: in templat->bind for etna_resource_alloc, but screen->ro is NULL. But I am unsure if this is needed at all for making drmModeAddFB2 work or if gbm import should already be enough.
19:37 cmeissl[m]: The reason why I was looking at that specific code in etnaviv is the MR this https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12018
19:42 emersion: cmeissl[m]: that'd be a mesa bug
19:43 emersion: gbm_bo_get_handle is supposed to return a handle for the gbm_device's FD
19:44 robclark: so, if I had to take a guess, screen->ro is a hint that the etnaviv driver is created from drm/etnaviv rendernode and not the kmsro (display) device node
19:44 emersion: hm yeah it's weird
19:44 robclark: (also, austriancoder might have more experience with this)
19:44 emersion: these bugs with bad handle usually happen when screen->ro!=NULL
19:45 emersion: because in that case there are multiple DRM FDs and it's easy to mix these up
19:45 robclark: yeah.. this case sounds more straightforward ;-)
19:46 robclark: how does mesa get the device fd in the wayland case? Is it passed from the compositor?
19:46 emersion: no
19:47 emersion: the compositor sends the device dev_t
19:47 emersion: mesa uses drmGetDeviceFromDevId
19:47 cmeissl[m]: from what I can tell the fd is retrieved in dri2_initialize_wayland_drm, I stepped into it and it pointed to renderD128
19:47 robclark: ok.. I guess the compositor is sending the wrong dev-id?
19:50 emersion: why?
19:50 robclark: somewhere in the drm_helper/loader code it will use drmGetVersion() and then pick the driver (in this case either etnaviv directly or indirectly via kmsro) based on the reported driver name
19:50 emersion: ah, for scanout,. yeah that'd be the wrong device
19:50 emersion: which compositor?
19:50 robclark: if the reported name is etnaviv it will skip kmsro
19:52 cmeissl[m]: emersion: What I currently do is to send the renderD128 (etnaviv) as the main device in the tranche and card1 (imx-drm) in the scan-out tranche. Later the dmabuf is imported through gbm created from card1.
19:52 cmeissl[m]: Compositor is based on smithay (where I contribute regularly, specifically direct scan-out and dmabuf feedback).
19:53 emersion: yeah that's fine
19:55 cmeissl[m]: ok, good to know, I already tried all combinations because I suspected I do something wrong in the compositor with the tranche devices
19:55 robclark: hmm, if the etnaviv render node is the one sent, I'm not sure how mesa would know how to create scanout capable surfaces
19:56 cmeissl[m]: right before DRM_IOCTL_MODE_ADDFB2 which prints "Failed to lookup GEM object" I can also see a call to DRM_IOCTL_PRIME_FD_TO_HANDLE returns -22
19:57 emersion: robclark: the wayland protocol sends different devices for scanout and not-scanout
19:58 emersion: maybe the driver doesn't check that DRM_IOCTL_PRIME_FD_TO_HANDLE succeeds?
19:58 cmeissl[m]: robclark: I am not 100% sure because I am already debugging that stuff for hours, but I am pretty sure I saw etnaviv as the reported name
19:58 emersion: which would explain the GEM lookup failure
20:02 cmeissl[m]: I thought it must have something to do with kmsro because the tranche scan-out flag results in PIPE_BIND_SCANOUT getting set for allocating the resource and etnaviv only uses that flag when screen->ro is not NULL
20:03 cmeissl[m]: I also tried to directly call drmPrimeFdToHandle and if IIRC that also returned an error
20:05 cmeissl[m]: There is https://gitlab.freedesktop.org/mesa/mesa/-/issues/5099 but that has been fixed
20:06 cmeissl[m]: I also tested with gstreamer waylandsink (decoding through v4l) and that works fine, the dmabuf is imported gets assigned to a overlay plane.
20:06 robclark: I guess the platform_wayland code in mesa needs to create the screen using the display dev instead of the render dev?
20:09 cmeissl[m]: I think I already tried to use card1 for the main device in the feedback, but I can try that again
20:11 robclark: I'm not familiar enough w/ the platform_wayland and wl proto stuff to know quite how this _expected_ to work.. but screen->ro==NULL is a big red flag that the fd the pipe-loader stuff uses to instantiate the screen is etnatviv rather than the display device
20:15 cmeissl[m]: I am actually not sure the code path that would set screen->ro gets called from the wayland egl platform, it does not look like that. So even if I send card1 it will also provide NULL for ro.
20:17 bwidawsk: robclark: but this is supposed to work today on freedreno for example
20:17 bwidawsk: Pretty sure daniels told me it does
20:18 robclark: cmeissl[m]: screen->ro is set in etna_screen_create() when called from kmsro_drm_screen_create()
20:20 robclark: bwidawsk: in almost all cases freedreno does not use kmsro... the exception is freescale imx5 things which have what (after acquisition from ati) became a2xx.. and I guess there aren't a whole lot of those things still in circulation
20:20 robclark: drm/msm covers both display and gpu in all other cases
20:21 cmeissl[m]: robclark: yeah, but I never see kmsro_drm_screen_create getting called, I always directly land in etna_drm_screen_create which always passed NULL for ro
20:26 robclark: right, which implies the screen is created from the render device, and not the display device
20:34 cmeissl[m]: I just tested it again with setting card1 as the main device, but that does not seem to make a difference. I still land in etna_drm_screen_create.
20:35 cmeissl[m]: Hm, dri2_initialize_wayland_drm doesn't seem to be happy with me sending card1 as the main device, because it is not a render node it falls back to wl_drm.
20:35 robclark: set a breakpoint in etna_drm_screen_create and step up the stack?
20:37 cmeissl[m]: Should wl_drm be initialized from card1 or render node? atm I initialize it from renderD128
20:41 cmeissl[m]: robclark: what shall I look at specifically? eglInitialize calls into dri2_initialize_wayland, which then lands in pipe_loader_create_screen, pipe_loader_create_screen_vk and finally in pipe_etnaviv_create_screen which calls etna_drm_screen_create
20:42 robclark: that is probably an emersion question.. but just looking at how kmsro and the pipe-loader stuff works, it looks like it is expected to be the display device.. that could be an xorg-ism, idk
20:50 bluetail: where do ALARM questions go ? (archlinuxarm)
20:53 bwidawsk: robclark: there's definitely something missing that seems to be in the glue. Looks like anholt_ also may be familiar
20:54 cmeissl[m]: robclark: I am not sure how to proceed, would it be best to open a issue in mesa and ping emersion and maybe austriancoder? The same code works on intel, amd, nvidia and vivante on i.mx8. (I did not test it myself, but someone reported that direct scan-out also worked with smithay on pine phone pro)
20:57 robclark: intel/amd/nv would all be single device providing scanout and render.. no idea how stuff works with vivante blob driver.. but yeah, open issue and cc emersion and maybe daniels.. I can only tell you why it isn't working.. but I can't tell you how it is supposed to work from wl standpoint
21:07 cmarcelo: is TGSI representation used by code outside mesa? I'm trying to understand if we have code that cares about TGSI_MEMBAR_ATOMIC_BUFFER individually (couldn't find evidence for this in mesa code), vs just handle MEMBAR ignoring the differences or assuming it is an SSBO.
21:09 robclark: cmarcelo, mostly no, except virgl.. which uses it in the guest->host interface (although possibly after some sanitizing?)
21:10 cmarcelo: robclark: is virgl code public? Ultimately I want to find out whether I need to plumb the atomic_counter barrier information down the pipes or not. (right now we just assume is a SSBO)
21:11 robclark: yeah, guest side is in mesa and host side is in virglrenderer
21:11 cmarcelo: cool. I'll take a look
21:12 robclark: I think we use (or at least support) ntt in the virgl case..
21:13 robclark: presumably if whatever happens on the core mesa side, we end up with same tgsi sent to host, then we are all good
21:16 cmarcelo: ok. virglrenderer will use that information to turn the TGSI_MEMBAR_ATOMIC_BUFFER back into GLSL memoryBarrierAtomicCounter().
21:22 robclark: right.. from an abi standpoint (ie. new guest on old host or visa versa) as long as we can ensure what mesa sends to the host is the same as before, everything should be happy