00:32 airlied: jenatali: your printf branch does need rebasing
00:33 jenatali: airlied: Yeah, it does
00:33 jenatali: I'll add that to my to-do list
00:34 airlied: I think it's just trivial vtn->glsl type
00:34 jenatali: karolherbst also had some good points about the buffer format
00:34 jenatali: airlied: https://github.com/microsoft/OpenCLOn12/issues/5
02:08 airlied: jenatali: what happens the format strings with your printf lowering
02:12 jenatali: airlied: Right now, the pointer-to-string is written into the buffer, and the runtime is responsible for retrieving/interpreting the format string
02:18 airlied: jenatali: ah okay, so it will end up being in the constant buffer
02:19 jenatali: Right
02:45 airlied: jenatali: did you consider a 32-bit handle?
02:50 airlied: karolherbst: just fyi the non-nir printf code isn't great for nir (you might have known that alreday)
02:50 airlied: llvm printf formats seems to encode all the arg sizes and then the format string
02:54 jenatali: airlied: I'm not opposed. Originally I was assuming the lowering I wrote was going to be for CLOn12 only, but if minor tweaks get us to share code, that's great
02:55 jenatali: airlied: That's one of the solutions to one of the problems I linked -- that way the handle can map to more than just the string, but also include the arg sizes, just like llvm
02:59 airlied: jenatali: ah yes just read that now
02:59 airlied: okay so maybe we can just reuse the llvm formats
03:01 airlied: I'm going to just hack things up to work with the current code so we have a baseline
03:23 jenatali: airlied: I'm not married to what's there now, so if you get it working with llvmpipe I'm happy to adapt
04:42 pmoreau: @airlied Not 100% sure; I would like to try Karol’s suggestion of storing the IL in the same vector as the source, as we shouldn’t need to store both at the same time, but I’ve been lacking the time to make that change.
04:58 airlied: pmoreau: seems like an optimisation that could be done later if valuable
05:21 airlied: jenatali, karolherbst: https://gitlab.freedesktop.org/airlied/mesa/-/commits/llvmpipe-cl-printf
05:21 airlied: starts to pass the first few printf tests
05:21 airlied: I didn't bother with strings, and I need to free some ram
05:22 airlied: stored the metainfo in a struct, and have idx to them
05:23 airlied: big storm approaching so need to power down for a while
06:24 airlied: oh I have to write module serializer support for it
08:20 danvet: tzimmermann, bbrezillon [PATCH] drm/shme-helpers: Fix dma_buf_mmap forwarding bug <- review/testing on this would be really good, it's a regression in 5.9
08:23 tzimmermann: danvet, i looked at it, but i'm not sure i'm really qualified
08:23 tzimmermann: the mmap codepaths are still a blackbox to me
09:04 danvet: airlied, this review extortion scheme!
13:14 danvet: siqueira, just noticed that neither vblank support nor writeback support in vkms is configurable
13:15 danvet: I thought we had that somewhere (as module options)
13:15 danvet: at least for vblank there was tons of discussions to properly detect whether vblank support exists in igt or not I thought
13:36 siqueira: danvet We had a mechanism for configuring wb and cursor via module parameter; however, during the review, we decided to keep both options always enabled by default. A long, long time ago, I made a patch that allowed vkms to change its configuration via sysfs on the fly, including wb and cursor settings. However, in the review, you pointed out that
13:36 siqueira: many other steps must be done before enabling such a mechanism. Maybe now it is time to revive that feature? Could you elaborate more on what you thinking?
13:37 emersion: why would you want to disable write-back?
13:39 danvet: emersion, just to test compositors
13:39 danvet: siqueira, for vblank it seems a bit like a loss, since supports vblank y/n is a big difference in how kms works
13:39 emersion: hm, right
13:40 danvet: might be nice to resurrect that and give it a spin on igt
13:40 danvet: and yeah maybe we get an outreachy to implement configfs this winter
13:41 siqueira: oh... do you mean the "virtual mode"? No vblank at all? If so, we don't have it yet; maybe this is a good outreachy project as well.
13:41 siqueira: we had issue with the first implementation and we never finished it.
13:43 danvet: siqueira, yeah the virtual mode thing
13:43 danvet: it should just work I thought, since we started out without vblank support
13:43 danvet: but I guess didn't quite work out
13:44 danvet: siqueira, do you remember the patches or anything like that?
13:45 siqueira: actually we started directly with vblank support, and the plan was enable virtual mode after that... however, we found a couple of issue, after that an Outreachy student tried to finish it, but in the end we never really completed it.
13:45 siqueira: I can try to find the original patches
13:51 siqueira: danvet My first attempt was this one: https://patchwork.freedesktop.org/series/48469/ (I managed to get some IGT changes accepted as a preparation for this work) and the Outreachy student attempt is this one: https://patchwork.freedesktop.org/series/75648/
13:51 siqueira: and this was my configfs implementation https://patchwork.freedesktop.org/series/63010/
13:52 danvet: Sumera83, ^^ fyi some good initial stuff that might be useful
13:53 siqueira: I think the virtual mode is close to finish, but we need to make sure that IGT test does not break with that.
13:54 danvet: oh right the composer work is tricky without vblank, I forgot about that
13:56 jenatali: airlied: Awesome, doesn't look too bad at all
13:57 danvet: yeah the virtual_hw patches look reasonably close, needs some polish around locking and code organization
13:57 danvet: but otherwise lgtm I think
15:17 karolherbst: airlied: yeah, because it's AMD specific code :p
15:18 karolherbst: but I mentioned that on the MR as well
16:31 ajax: hmph. we're not doing any test coverage against an expliclt gles2 profile, are we. just whatever llvmpipe gives you.
16:49 sravn: danvet: If we drop the acceleration support in gma500 then we have another user coming for the generic fbdev emulation, right?
16:49 danvet: sravn, maybe
16:50 danvet: I think there's a few more drivers that could be converted still
16:53 sravn: Yeah, especillay after tzimmerman's patches goes in. Most reamining drivers with their own fbdev emulation uses drm_fb_helper_cfb* and Thomas already said he wanted to take a look
16:54 ajax: istr the acceleration was the only thing that made gma500 console usable
16:54 ajax: for whatever value of "usable" you ascribe to a poulsbo
17:03 NiksDev: I have recently subscribed to dri-devel mailing list
17:03 NiksDev: Whenever I send any email to the list, I do not get my own email, is this some kind of optimization
17:03 NiksDev: How can I get all the emails, even the ones I sent?
17:06 vsyrjala: aren't most of the known bugs in the software fbcon code? not sure how making everything use that is going to help
17:10 ajax: NiksDev: i believe that's one of the subscription options you can change from (near the bottom of) https://lists.freedesktop.org/mailman/listinfo/dri-devel
17:22 NiksDev: ajax, thanks, I logged in and my setting "Receive your own posts to the list?" shows "Yes"
17:22 NiksDev: but I never received emails sent by myself
17:24 jcristau: some mail providers (hi gmail) hide those
17:36 NiksDev: I am subscribed to other lists (e.g. jailhouse-dev@googlegroups.com) and there I get all the patches and replies I send
18:41 danvet: ajax, they're all pretty much slideshow on older machines
19:11 airlied: karolherbst: rewrote it now so the amd/llvm stuff is kep in the llvm backend
19:12 airlied: https://gitlab.freedesktop.org/airlied/mesa/-/commit/50fcbfd8a71b338aa096d61589d4e26ed5c58e5a
19:30 jenatali: airlied: Feel free to take over the MR I started or create your own, either way
19:31 jenatali: Once you're ready of course
19:34 airlied: jenatali: I'll likely make a super MR from yours and the amd/llvm one
19:35 jenatali: Sounds good
21:47 LiquidAcid: hello, i did an interesting observation on a iGPU/dGPU system with firefox natively on wayland; compositor is sway, the dGPU is card0, the iGPU is card1, sway/wlroots is instructed to only use card1
21:47 LiquidAcid: now firefox's own compositor process runs on card1 (as it should be), but apparantly it pushes all the rendering to card0
21:48 LiquidAcid: this can be verified via debugfs and inspecting the the clients of each cards
21:48 LiquidAcid: my question: is this maybe related to mesa, or attributed to some behaviour of firefox?
21:49 LiquidAcid: fun fact: thunderbird also runs on card0
21:52 LiquidAcid: i would guess that the firefox sandboxes just create their own EGL context where the default device then is card0 (probably because of the numbering)
22:17 Venemo: LiquidAcid: what happens if you run Firefox with DRI_PRIME
22:18 LiquidAcid: Venemo, yeah, also my first thought
22:18 LiquidAcid: actually changes nothing
22:18 Venemo: sounds like the processes to which Firefox offloads the rendering don't respect it then
22:19 LiquidAcid: i'm currently using DRI_PRIME=pci-0000_08_00_0, which is the tag for the iGPU, still everything except the compositor thread are located on the dGPU
22:20 LiquidAcid: another fun fact: firefox itself claims (in about:support) that it uses the iGPU
22:20 Venemo: interesting
22:21 Venemo: probably it's unintentional
22:21 Venemo: why does this bother you, btw?
22:22 LiquidAcid: power consumption
22:22 LiquidAcid: also i'd would like to be the one to decide which gpu is used and when
22:23 Venemo: I see. then, I think best file a bug report against Firefox
22:23 LiquidAcid: sure, this is nice and all, but at least i'd like to configure things and that doesn't appear to be possible
22:26 jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7356
22:26 jekstrand: I'm just going to leave that there ^^
22:26 Venemo: jekstrand: \o/
22:27 Venemo: LiquidAcid: the problem appears that Firefox doesn't respect your settings, and it doesn't seem to be a bug in mesa.
22:28 Venemo: jekstrand: are there even CTS tests for that stuff? also, what HW is supported?
22:28 jekstrand: Venemo: Khronos has a bunch CTS tests. They'll be released with the spec.
22:28 jekstrand: Venemo: For HW, see the FAQ in my e-mail. :)
22:30 bnieuwenhuizen: nice
22:31 jekstrand: I should probably drop the WIP from the SPIR-V MR
22:31 Venemo: jekstrand: does Tiger Lake's Xe work? sorry I'm not familiar with what HPG means there.
22:31 jekstrand: Venemo: HPG I think stands for "high-performance GPU" or something like that. It means discrete.
22:32 jekstrand: Venemo: No guarantee about exactly what discrete cards will support it though.
22:32 jekstrand: Well, no guarantees that I can tell you about. :)
22:32 Venemo: okay, sure
22:32 bnieuwenhuizen: huh, so that is why you were working on CL :P
22:32 jekstrand: bnieuwenhuizen: Yup. :)
22:33 jekstrand: bnieuwenhuizen: Those BVH building kernels are nasty!
22:33 jekstrand: Generic pointers for everything. 64-bit subgroup ops. SPV_INTEL extensions. Generally absolutely massive.
22:34 bnieuwenhuizen: jekstrand: you planning to use CL SPIR-V for the BVH building?
22:34 jekstrand: bnieuwenhuizen: Yup
22:34 bnieuwenhuizen: how do you plan to work with source control for that?
22:34 Venemo: I don't fully understand how CL connects to ray tracing
22:34 jekstrand: Venemo: CL doesn't really connect so much. It's that we have to build the acceleration structures somehow. That "how" is a pile of OpenCL kernels.
22:34 jekstrand: bnieuwenhuizen: What do you mean?
22:34 bnieuwenhuizen: Venemo: building BVH trees is complicated compute work. Better do it in a source lang than build it all in nir builders
22:35 Venemo: I thought the app builds the acceleration structures
22:35 bnieuwenhuizen: jekstrand: are you committing the SPIR-V for that or do you have the source + now a CL C compiler as part of the build process?
22:35 jekstrand: Venemo: It does by calling vkCmdBuildAccelerationStructuresKHR. :-)
22:35 Venemo: so it... doesn't? but rather, just asks the driver to build it
22:35 jekstrand: bnieuwenhuizen: My current plan is to have a build-time requirement on SPIRV-LLVM-Translator.
22:35 jekstrand: Venemo: Yup
22:36 jekstrand: Venemo: All the details of the BVH data structure are HW-specific.
22:36 bnieuwenhuizen: how well do the intel CL extensions hold up vs vulkan subgroup ones?
22:36 jekstrand: They're different.
22:37 bnieuwenhuizen: hmm
22:37 jekstrand: The shuffles take two sources and sort-of paste them together before shuffling.
22:37 jekstrand: So you can do circular shuffles and stuff like that with them.
22:37 bnieuwenhuizen:thinks writing the BVH building in CL C might be a bit nicer than in GLSL
22:37 bnieuwenhuizen: and if we have the right build dep anyway ...
22:38 jekstrand: We'll have to see what things look like as time goes on. We might be able to share some of the BVH building.
22:38 Venemo: that's some really well thought out work, jekstrand - i'm currently searching for my jaw.
22:39 jekstrand: Venemo: Oh, my branch hasn't always looked that nice. That history is a total lie. :-)
22:39 bnieuwenhuizen: in all fairness I haven't really looked at good algorithms yet ... Getting something running is still our first priority
22:39 Venemo: that's how it always is for all of us, isn't it
22:39 bnieuwenhuizen: I'm not Connor but I'll take a look
22:40 jekstrand: bnieuwenhuizen: Any review is appreciated.
22:40 jekstrand: bnieuwenhuizen: The SPIR-V and core NIR bits should be anyone's game
22:42 jekstrand: And... Phoronix!
22:43 bnieuwenhuizen: wow that was quick, did you have a press release or something?
22:43 LiquidAcid: Venemo, look what i found: https://bugzilla.mozilla.org/show_bug.cgi?id=1588904
22:43 LiquidAcid: MOZ_WAYLAND_DRM_DEVICE to the rescue!
22:44 jekstrand: bnieuwenhuizen: No. I sent e-mail to mesa-dev. Michael reads it. :-)
22:44 jekstrand: AFAICT, he doesn't watch gitlab very closely but he watches mesa-dev like a hawk.
22:44 bnieuwenhuizen: I guess that is almost as good now that there are no patches anymore :P
22:47 jenatali: jekstrand: Aha! Now it all makes sense :)
22:49 jekstrand: jenatali: :)