00:27 Lyude: drm-tip broke, fixing it
00:32 airlied: Lyude: I'm in the middle of fixing it
00:33 airlied: Lyude: just waiting on a build to finish
00:33 Lyude: airlied: aaaah-cool, was just about to say "oh wait this does not look trivial"
00:33 Lyude: airlied: will leave up to you then, thanks!
00:34 Lyude: airlied: I did push something beforehand, figured I'd mention it since I'm not sure if you'd need to do a rebuild after or not
01:44 bl4ckb0ne: thanks for the quick review ajax
02:17 bl4ckb0ne: is there a LAVA admin around? https://gitlab.freedesktop.org/bl4ckb0ne/mesa/-/jobs/6803613
03:06 marex: anholt: is there some test for that pointcoord indirect ?
04:49 ishitatsuyuki: I've heard that LLVMpipe has supported OpenGL 4.x but when I run GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 glinfo I get GL_VERSION: 3.1 Mesa 20.3.3. Any idea why can this be happening?
04:50 airlied: ishitatsuyuki: core vs compat context?
04:51 ishitatsuyuki: I guess you are right
04:52 airlied: it ony support 3.1 compat contexts, 4.5 core context
04:52 ishitatsuyuki: ok, now I have clues about this. thanks
09:29 danvet: MrCooper, was just typing the same
09:29 danvet: pq, ^^
09:29 MrCooper: ninja'd :)
09:32 pq: MrCooper, the question is, what does Nouveau do in that case? Or did someone assume that GEM_CLOSE kills the FDs too and came up with an elaborate plan to work around it?
09:33 danvet: pq, I'm assuming the reason nouveau needs to know which objects are exported are for sync reasons
09:33 danvet: nouveau (like other drivers) doesn't do implicit sync by default
09:34 danvet: only when you export
09:34 MrCooper: I don't know what it does; what it should do is drop handle A from its hash table on GEM_CLOSE, then add handle B on FDToHandle
09:34 danvet: so if you export behind its back, there's going to be unhappiness
09:34 pq: danvet, aha, that's yet another thing I've never heard of before. cc emersion
09:35 MrCooper: the amdgpu winsys also needs to know this for GPUVM address space tracking
09:35 emersion: that's the reason why it needs to know when you do handleToFD right?
09:36 pq: I thought everything that need to be done was done in the ioctl
09:37 MrCooper: not possible I'm afraid
09:37 danvet: yeah, we have drivers in userspace :-)
09:37 danvet: for rendering
09:37 danvet: for kms it's everything, but then all of kms is in the kernel
09:42 MrCooper: danvet: "global gem handle" aka "GEM name" :)
09:42 danvet: oh right that's the name
09:42 pq: what's flink then? :-p
09:42 danvet: create a gem name
09:42 danvet: we're not that good at consistent naming
09:42 pq: aha, so "flink handle" is not a thing
09:44 pq: btw. why does libgbm.so link to libwayland-server.so?
09:47 emersion: pq: wl_drm?
09:47 emersion: there's some WL_BUFFER in there
09:48 MrCooper: according to objdump -t it references wl_buffer_interface, wl_resource_instance_of & wl_resource_get_user_data
09:48 pq: ummm...
09:49 emersion: you can import a wl_drm buffer into GBM
09:49 lynxeye: yep, you can import a wayland buffer into GBM for, ummm... historical reasons
09:49 pq: oh for *that* API
09:49 emersion: yeah
09:50 pq: ookay
09:50 emersion: it's not great
09:51 danvet: uh which api?
09:51 ccr:shudders
09:52 pq: gbm_bo_import(GBM_BO_IMPORT_WL_BUFFER)
09:52 emersion: danvet: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gbm/main/gbm.h#L281\
09:52 pq: it's from an era when zwp_linux_dmabuf_v1 did not exit, and wl_drm was a Mesa internal implementation detail.
09:52 pq: *exist
09:53 emersion: we also have GBM_BO_IMPORT_EGL_IMAGE apparently…
09:53 pq: so this was the API to get a gbm_bo from a client buffer, for KMS purposes
09:53 emersion: probably because the EGL export ext didn't exist
09:54 danvet: ah, I think I missed that entire story before the egl extensions
10:36 sumits: danvet: Reg "drm/drm_vblank: set the dma-fence timestamp during send_vblank_event" - I guess you'll take it via drm main tree, along with the corresponding dma-fence patch? I'll post my r-b / a-b on the two patches if that's ok with you?
10:37 danvet: sumits, you have commit rights for drm-misc
10:37 danvet: and jstultz too
10:37 danvet: aka "not my problem"
10:37 danvet: I did drop some comments on early versions to make sure it's neatly integrated and all, but that's it
10:38 sumits: danvet :) - asking because the drm patch changes core drm_file and drm_vblank, so I thought it'd go via drm main.
10:38 sumits: danvet, and yes, thanks much for the review comments on the early versions
10:39 danvet: sumits, drm-misc is gathering ground for all that stuff
10:39 sumits: danvet, ack. I'll push
10:39 danvet: drm.git is pretty much just taking pulls from subtrees
10:40 danvet: sumits, this has been going like this since years by now, and MAINTAINERS is also up to date
10:41 sumits: danvet, understood, will take care in future - I've not merged patches for drm* in some time, guess that's why the question.
11:09 daniels: bl4ckb0ne: thanks for the notification, that's getting fixed and you shouldn't be seeing them
13:36 danvet: tzimmermann, typed up something for the todo.rst
13:36 danvet: I'll be on vacations next week, so if you like maybe just merge outright
13:45 alyssa: daniels: what's the process for creating a group on gitlab.fd.o?
13:46 alyssa: (Was hoping to create gitlab.fd.o/asahi/mesa to keep the gfx side on-site in the long term, and in the short-term a contrbutor has expressed preferring gl.fd.o over github)
13:47 danvet: alyssa, nice, was just about to ask whether this is for asahi
13:48 alyssa: danvet: otherwise I'd just throw it on my gitlab userspace, which is now littered with, uhh
13:48 danvet: alyssa, I think process is just "ask on #freedesktop" or file a ticket against freedesktop
13:49 danvet: top level group is the only thing that needs admins
13:49 emersion: alyssa: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/new
13:49 danvet: well one of the only things
13:49 emersion: there's a "new project" template
13:49 alyssa: ack, thank you :)
13:53 alyssa: "freedesktop.org maintains a unified Code of Conduct"
13:54 alyssa: Asahi has its own CoC, I guess there might be ~licensing~ CoC incompatibility issues uhhh
13:55 danvet: well on github it's called "Terms of Service"
13:56 emersion: as long as they don't contradict themselves should be ok?
13:56 danvet: I guess the terms missing are the privacy policy
13:57 danvet: or maybe that happens at account creation
13:57 alyssa:had not realized there were so many formalities
13:58 danvet: fd.o has become somewhat professional
13:59 alyssa: *gasps* :p
13:59 danvet: plus it's better to be open about this stuff than TOS-ban people after the fact like everywhere else
14:00 danvet: and with fd.o you can actually vote the people out if you don't like them!
14:00 alyssa: :>
14:00 emersion: i dunno
14:00 emersion: i like my CoC, which is "be nice"
14:01 emersion: i must admit i'm never found of formalities
14:09 daniels: it's not so much a formality as just making it very explicit what 'nice' means
14:09 daniels: because some people have very skewed ideas about that
14:09 danvet: also, fd.o has some money and there's some laws
14:09 daniels: the CoC isn't a legalised checklist really, it's just setting very concrete expectations which are then interpreted and applied with discretion
14:10 daniels: alyssa: as others have said, as long as there's no fundamental conflict then I don't see a problem with it
14:11 alyssa: daniels: ack
14:11 alyssa: (https://asahilinux.org/code-of-conduct/)
14:21 HdkR: That looks like a pretty okay CoC
15:50 lynxeye: daniels: Any chance you get around to look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8106 or should I try to get someone else to review this?
15:58 bl4ckb0ne: daniels: thanks!
16:03 daniels: lynxeye: it's in my queue to review but I have some other pressing things I need to take of before/through the weekend; can we please say end of next week?
16:04 daniels: HdkR: yeah it certainly does look good to me, and I don't really see any incompatibility, apart from maybe the posting of an anonymous summary
16:04 lynxeye: daniels: Sure, we all have a lot on our plates. Just wanted to make sure it doesn't get totally stuck in limbo.
16:11 daniels: lynxeye: thanks for chasing up, sorry for the delay
17:05 dcbaker: kusma: 8c7d971666 and 45bebc7a9c are nominated for 21.0, but don't apply cleanly, the conflicts are small but look significant
17:15 jenatali: I've got some super minor preprocessor Windows arm64 support patches that I'd like to get in. I don't want to keep bugging people here to ask for reviews, but I also don't want to just have some unknown-to-you MSFT dev review it and call it good
17:15 jenatali: Any advice? :)
17:19 imirkin: jenatali: i think bugging people for reviews is perfectly reasonable
17:19 imirkin: link?
17:19 jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8485 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8619
17:20 jenatali: I just know it's not something anybody here really cares about so I feel bad bugging people
17:20 dcbaker: on the other hand, if the code only modifiers your driver though (like only src/microsoft/* are changed) then having some random microsoft dev is fine :)
17:20 imirkin: yeah. in this case it's dd.h, so kinda central
17:20 jenatali: Yeah these are core Mesa though, but just dealing with preprocessor behavior for Windows
17:20 imirkin: also ... lol at the stuff you end up having to do
17:20 dcbaker: I know, just throwing it out there
17:20 jenatali: Makes sense
17:21 imirkin: jenatali: the MemoryBarrier thing screws up stuff like "ctx->Driver.MemoryBarrier" right?
17:21 imirkin: not to mention "void (*MemoryBarrier)" heh
17:21 jenatali: Yeah. For x86 it's fine, for x64 since the #define is everywhere it's just a weirdly named function
17:22 jenatali: But for arm/arm64 since it's a function-like macro, you can't declare a function with that name, and the call sites end up invoking the macro instead
17:24 imirkin: jenatali: arm64 defines _M_X64??
17:25 jenatali: Arm64EC does, yeah... it's a weird thing...
17:25 imirkin: what's Arm64EC, and how does it differ from Arm64?
17:26 jenatali: 99% of code should think that it's x64, and then the compiler backend just generates arm64 instructions
17:26 imirkin: but not for sse intrinsics?
17:26 imirkin: what a cluster%*&!
17:26 jenatali: It's used for x64 emulation on arm64 devices. The result is a binary that can be loaded into the x64 processes, but that binary's code doesn't need to be emulated
17:27 imirkin: (not one of your doing, i understand, but still)
17:27 jenatali: The SSE intrinsics are a bit weird. IIRC there's emulation for some of them, but I think they might need a different header? I'm not 100% sure
17:29 jenatali: We've also internally got one for x86-on-arm64 which is even weirder (called CHPE), but we never publicly shipped a toolset for 3rd party code to build that way. The arm64ec toolset is going public soonish
17:42 alyssa: jenatali: wat.
17:42 kusma: dcbaker: OK, I'll see if I can create an MR for the stable-branch
17:42 jenatali: alyssa: Yep
17:42 dcbaker: kusma: thanks!
17:51 kusma: dcbaker: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8655
17:51 dcbaker: Thanks!
17:52 kusma: np, thanks for pinging me :)
17:53 MrCooper: mutter has gone nuclear: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488
17:54 emersion: nice
19:17 airlied: alyssa: kinda sounds like userspace controls the page tables directly on the M1 somehow
19:17 airlied: if the GPU directly uses those 64-bit handle tables or not I suppose is the question
19:18 alyssa: airlied: Yeah, without peeking at the kernel side it's hard to tell.
19:18 alyssa: I don't know which explanation is more horrifying.
19:42 agd5f_: alyssa, might be something like the ATS/PRI functionality in the PCI spec where the IOMMU can provide an unified address space for devices and the CPU
19:43 agd5f_: like the way ROCm works on older APUs
19:44 alyssa: ok but why is userspace controlling that :p
19:44 alyssa: that's the part I have a problem with ;P
19:46 jenatali: Efficiency?
19:46 agd5f_: alyssa, userspace doesn't control the page tables, it just provides pointer is a pointer functionality with devices. SO you can use CPU virtual addresses with devices
19:50 robclark: heh, userspace controlled pgtables.. would could posibl go wrong
20:48 pcercuei_: quick question: the ingenic-drm driver will search for connected bridges in its probe (through the devicetree graph API). When a driver for e.g. the HDMI bridge is not enabled, the ingenic-drm driver does not start as it always return -EPROBE_DEFER. Is there a way to somehow know whether the remote bridge's driver is enabled?
20:49 pcercuei_: (without assuming things about the nature of the bridge and its driver)
22:33 cmarcelo: scons-win64 in build-misc fails and gets into a exclamation mark state. is that failure expected/skipped? looking at the log the error seems unrelated to my MR, undefined reference to 'clock_gettime', seems either build sys or environmental issue.
22:33 cmarcelo: (I'm referring to Gitlab CI)
22:36 imirkin: i've been getting it too
22:37 imirkin: "ignore" unless you care about win64
22:37 imirkin: the vmware guys will fix it eventually
22:38 anholt: cmarcelo: yeah, the ! is the compromise for "devs shouldn't have to worry about scons", just ignore it.
22:39 cmarcelo: cool thanks
23:02 dcbaker: I have a ptache for that
23:03 dcbaker: an MR, actually
23:03 dcbaker: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8592
23:15 jenatali: Did their appveyor CI get shut down again? I expected to see an email about how it's broken
23:16 alyssa:stil doesn't understand what the point of spending CI cycles on something everyone ignores is
23:17 dcbaker:either, but me is trying to be nice
23:56 alyssa: $ nice -n dcbaker
23:56 alyssa: er
23:56 alyssa: $ nice -n 10 dcbaker
23:56 alyssa: there, I helped
23:58 dcbaker: lol