00:27Lyude: drm-tip broke, fixing it
00:32airlied: Lyude: I'm in the middle of fixing it
00:33airlied: Lyude: just waiting on a build to finish
00:33Lyude: airlied: aaaah-cool, was just about to say "oh wait this does not look trivial"
00:33Lyude: airlied: will leave up to you then, thanks!
00:34Lyude: 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:44bl4ckb0ne: thanks for the quick review ajax
02:17bl4ckb0ne: is there a LAVA admin around? https://gitlab.freedesktop.org/bl4ckb0ne/mesa/-/jobs/6803613
03:06marex: anholt: is there some test for that pointcoord indirect ?
04:49ishitatsuyuki: 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:50airlied: ishitatsuyuki: core vs compat context?
04:51ishitatsuyuki: I guess you are right
04:52airlied: it ony support 3.1 compat contexts, 4.5 core context
04:52ishitatsuyuki: ok, now I have clues about this. thanks
09:29danvet: MrCooper, was just typing the same
09:29danvet: pq, ^^
09:29MrCooper: ninja'd :)
09:32pq: 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:33danvet: pq, I'm assuming the reason nouveau needs to know which objects are exported are for sync reasons
09:33danvet: nouveau (like other drivers) doesn't do implicit sync by default
09:34danvet: only when you export
09:34MrCooper: 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:34danvet: so if you export behind its back, there's going to be unhappiness
09:34pq: danvet, aha, that's yet another thing I've never heard of before. cc emersion
09:35MrCooper: the amdgpu winsys also needs to know this for GPUVM address space tracking
09:35emersion: that's the reason why it needs to know when you do handleToFD right?
09:36pq: I thought everything that need to be done was done in the ioctl
09:37MrCooper: not possible I'm afraid
09:37danvet: yeah, we have drivers in userspace :-)
09:37danvet: for rendering
09:37danvet: for kms it's everything, but then all of kms is in the kernel
09:42MrCooper: danvet: "global gem handle" aka "GEM name" :)
09:42danvet: oh right that's the name
09:42pq: what's flink then? :-p
09:42danvet: create a gem name
09:42danvet: we're not that good at consistent naming
09:42pq: aha, so "flink handle" is not a thing
09:44pq: btw. why does libgbm.so link to libwayland-server.so?
09:47emersion: pq: wl_drm?
09:47emersion: there's some WL_BUFFER in there
09:48MrCooper: according to objdump -t it references wl_buffer_interface, wl_resource_instance_of & wl_resource_get_user_data
09:49emersion: you can import a wl_drm buffer into GBM
09:49lynxeye: yep, you can import a wayland buffer into GBM for, ummm... historical reasons
09:49pq: oh for *that* API
09:50emersion: it's not great
09:51danvet: uh which api?
09:52emersion: danvet: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gbm/main/gbm.h#L281\
09:52pq: it's from an era when zwp_linux_dmabuf_v1 did not exit, and wl_drm was a Mesa internal implementation detail.
09:53emersion: we also have GBM_BO_IMPORT_EGL_IMAGE apparently…
09:53pq: so this was the API to get a gbm_bo from a client buffer, for KMS purposes
09:53emersion: probably because the EGL export ext didn't exist
09:54danvet: ah, I think I missed that entire story before the egl extensions
10:36sumits: 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:37danvet: sumits, you have commit rights for drm-misc
10:37danvet: and jstultz too
10:37danvet: aka "not my problem"
10:37danvet: I did drop some comments on early versions to make sure it's neatly integrated and all, but that's it
10:38sumits: danvet :) - asking because the drm patch changes core drm_file and drm_vblank, so I thought it'd go via drm main.
10:38sumits: danvet, and yes, thanks much for the review comments on the early versions
10:39danvet: sumits, drm-misc is gathering ground for all that stuff
10:39sumits: danvet, ack. I'll push
10:39danvet: drm.git is pretty much just taking pulls from subtrees
10:40danvet: sumits, this has been going like this since years by now, and MAINTAINERS is also up to date
10:41sumits: danvet, understood, will take care in future - I've not merged patches for drm* in some time, guess that's why the question.
11:09daniels: bl4ckb0ne: thanks for the notification, that's getting fixed and you shouldn't be seeing them
13:36danvet: tzimmermann, typed up something for the todo.rst
13:36danvet: I'll be on vacations next week, so if you like maybe just merge outright
13:45alyssa: daniels: what's the process for creating a group on gitlab.fd.o?
13:46alyssa: (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:47danvet: alyssa, nice, was just about to ask whether this is for asahi
13:48alyssa: danvet: otherwise I'd just throw it on my gitlab userspace, which is now littered with, uhh
13:48danvet: alyssa, I think process is just "ask on #freedesktop" or file a ticket against freedesktop
13:49danvet: top level group is the only thing that needs admins
13:49emersion: alyssa: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/new
13:49danvet: well one of the only things
13:49emersion: there's a "new project" template
13:49alyssa: ack, thank you :)
13:53alyssa: "freedesktop.org maintains a unified Code of Conduct"
13:54alyssa: Asahi has its own CoC, I guess there might be ~licensing~ CoC incompatibility issues uhhh
13:55danvet: well on github it's called "Terms of Service"
13:56emersion: as long as they don't contradict themselves should be ok?
13:57danvet: or maybe that happens at account creation
13:57alyssa:had not realized there were so many formalities
13:58danvet: fd.o has become somewhat professional
13:59alyssa: *gasps* :p
13:59danvet: plus it's better to be open about this stuff than TOS-ban people after the fact like everywhere else
14:00danvet: and with fd.o you can actually vote the people out if you don't like them!
14:00emersion: i dunno
14:00emersion: i like my CoC, which is "be nice"
14:01emersion: i must admit i'm never found of formalities
14:09daniels: it's not so much a formality as just making it very explicit what 'nice' means
14:09daniels: because some people have very skewed ideas about that
14:09danvet: also, fd.o has some money and there's some laws
14:09daniels: the CoC isn't a legalised checklist really, it's just setting very concrete expectations which are then interpreted and applied with discretion
14:10daniels: alyssa: as others have said, as long as there's no fundamental conflict then I don't see a problem with it
14:11alyssa: daniels: ack
14:21HdkR: That looks like a pretty okay CoC
15:50lynxeye: 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:58bl4ckb0ne: daniels: thanks!
16:03daniels: 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:04daniels: 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:04lynxeye: daniels: Sure, we all have a lot on our plates. Just wanted to make sure it doesn't get totally stuck in limbo.
16:11daniels: lynxeye: thanks for chasing up, sorry for the delay
17:05dcbaker: kusma: 8c7d971666 and 45bebc7a9c are nominated for 21.0, but don't apply cleanly, the conflicts are small but look significant
17:15jenatali: 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:15jenatali: Any advice? :)
17:19imirkin: jenatali: i think bugging people for reviews is perfectly reasonable
17:19jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8485 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8619
17:20jenatali: I just know it's not something anybody here really cares about so I feel bad bugging people
17:20dcbaker: 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:20imirkin: yeah. in this case it's dd.h, so kinda central
17:20jenatali: Yeah these are core Mesa though, but just dealing with preprocessor behavior for Windows
17:20imirkin: also ... lol at the stuff you end up having to do
17:20dcbaker: I know, just throwing it out there
17:20jenatali: Makes sense
17:21imirkin: jenatali: the MemoryBarrier thing screws up stuff like "ctx->Driver.MemoryBarrier" right?
17:21imirkin: not to mention "void (*MemoryBarrier)" heh
17:21jenatali: Yeah. For x86 it's fine, for x64 since the #define is everywhere it's just a weirdly named function
17:22jenatali: 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:24imirkin: jenatali: arm64 defines _M_X64??
17:25jenatali: Arm64EC does, yeah... it's a weird thing...
17:25imirkin: what's Arm64EC, and how does it differ from Arm64?
17:26jenatali: 99% of code should think that it's x64, and then the compiler backend just generates arm64 instructions
17:26imirkin: but not for sse intrinsics?
17:26imirkin: what a cluster%*&!
17:26jenatali: 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:27imirkin: (not one of your doing, i understand, but still)
17:27jenatali: 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:29jenatali: 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:42alyssa: jenatali: wat.
17:42kusma: dcbaker: OK, I'll see if I can create an MR for the stable-branch
17:42jenatali: alyssa: Yep
17:42dcbaker: kusma: thanks!
17:51kusma: dcbaker: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8655
17:52kusma: np, thanks for pinging me :)
17:53MrCooper: mutter has gone nuclear: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488
19:17airlied: alyssa: kinda sounds like userspace controls the page tables directly on the M1 somehow
19:17airlied: if the GPU directly uses those 64-bit handle tables or not I suppose is the question
19:18alyssa: airlied: Yeah, without peeking at the kernel side it's hard to tell.
19:18alyssa: I don't know which explanation is more horrifying.
19:42agd5f_: 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:43agd5f_: like the way ROCm works on older APUs
19:44alyssa: ok but why is userspace controlling that :p
19:44alyssa: that's the part I have a problem with ;P
19:46agd5f_: 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:50robclark: heh, userspace controlled pgtables.. would could posibl go wrong
20:48pcercuei_: 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:49pcercuei_: (without assuming things about the nature of the bridge and its driver)
22:33cmarcelo: 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:33cmarcelo: (I'm referring to Gitlab CI)
22:36imirkin: i've been getting it too
22:37imirkin: "ignore" unless you care about win64
22:37imirkin: the vmware guys will fix it eventually
22:38anholt: cmarcelo: yeah, the ! is the compromise for "devs shouldn't have to worry about scons", just ignore it.
22:39cmarcelo: cool thanks
23:02dcbaker: I have a ptache for that
23:03dcbaker: an MR, actually
23:15jenatali: Did their appveyor CI get shut down again? I expected to see an email about how it's broken
23:16alyssa:stil doesn't understand what the point of spending CI cycles on something everyone ignores is
23:17dcbaker:either, but me is trying to be nice
23:56alyssa: $ nice -n dcbaker
23:56alyssa: $ nice -n 10 dcbaker
23:56alyssa: there, I helped