00:10 gfxstrand: Testing the new nick...
00:12 psykose: test passed
00:13 gfxstrand: \o/
00:13 gfxstrand: Now if only I can get my bouncer fixed...
00:14 jenatali: Oh no, that's going to get confusing
00:14 gfxstrand: ?
00:14 zmike: who do I ask about compute shaders now if you're only doing gfx
00:14 jenatali: I'm just going to forget lol
00:15 gfxstrand: Hehe, fair.
00:15 gfxstrand: I've still got a highlight for jekstrand
00:15 gfxstrand: Or will, once I fix my bouncer
00:15 gfxstrand: grrrr
00:15 airlied: is [m] you the bouncer?
00:18 danvet: maybe irc should grow a .nickmap or something
00:18 danvet: like this isn't really a hard problem
00:18 daniels: irc should a lot of things
00:18 Lyude: we just need to move over to matrix already :), or I need to get that started rather
00:18 danvet: yeah maybe it's a hard problem for irc ...
00:19 jenatali: +1
00:19 danvet: also I should sleep
00:19 zmike: elbowdrop-meme.png: irc should get X feature! elbow-drop: irc is older than I am!
00:19 Lyude: don't worry, we'll make it to ircv4 in a couple decades
00:57 gfxstrand: Ok, bouncer back up. :D
01:24 karolherbst: yo, hey gfxstrand, new new huh...
01:57 karolherbst: *name actually, but whatever :D
01:59 gfxstrand: "new new" works. :P
02:00 karolherbst: heh
02:00 mbrost: The Xe gitlab project is now public: https://gitlab.freedesktop.org/drm/xe/kernel
02:01 gfxstrand: \o/
02:01 gfxstrand: Congrats!
02:01 karolherbst: cool stuff
02:01 kisak: mbrost: not public here
02:02 mbrost: hmm, I thought I made change, 1 sec
02:02 kisak: also might be some level of caching
02:02 karolherbst: ahh yeah.. it also appears at private for me, but I can access it
02:03 mbrost: ah, try it again
02:03 kisak: there it is
02:04 daniels: mbrost: can you please re-do the CI to use the GitLab kernel CI stuff we've already been working on?
02:05 daniels: mbrost: as is, installing the deps every time is quite inefficient, and not using ${FDO_CI_CONCURRENT] is a DoS on the runners
02:05 mbrost: Probably, I wasn't involved in setting that up
02:06 daniels: demarchi: ^
02:06 mbrost: yep, demarchi is who you should talk to
02:06 mbrost: I can bring up this up with the entire Xe team too
02:10 karolherbst: what's the situation with hosting kernel projects on gitlab now anyway? Wouldn't that fill up storage real quick if everybody forks to submit MRs? Or is that considered fine now? (also ignoring that it takes ages to fork anyway)
02:10 karolherbst: (just wondering how we can ditch emails for kernel devel here anyway)
02:10 daniels: I think we're ok for storage
02:11 daniels: mbrost: yeah, if you could please ask them to just follow the rest of the kernel CI work, as in e.g. drm-msm, that would be great please
02:11 daniels: karolherbst: I don't see a real blocker to moving kernel stuff to GitLab; the only risk is that we overwhelm the infrastructure and need to ask our hosts for more
02:11 karolherbst: right..
02:12 karolherbst: but having to fork the kernel repo for an hour before you can submit an MR is also kind of annoying if the alternative is to send an email out in 5 seconds, but that's nothing _we_ can fix and is in the hands of gitlab itself
02:13 jenatali: karolherbst: I don't think the forks are full forks, assuming it works like GitHub, I think it's just a namespace for branches
02:13 karolherbst: anyway.. if drm-msm is atm the most advanced project in regards to CI and stuff, I might be up to move to gitlab for nouveau as well, just... that makes it annoying because we still have to consider emails, because we can't tell users to do the gitlab dance instead :/
02:13 karolherbst: jenatali: well.. did you try to fork a kernel on gitlab?
02:14 karolherbst: last time I tried, it took like an hour
02:14 jenatali: That seems insane
02:14 karolherbst: I'm thinking the same
02:14 karolherbst: maybe it's better now...
02:14 karolherbst: could fork xe/kernel and see what happens
02:15 mbrost: I fork Xe all the time, it takes like 5-10 minutes
02:16 karolherbst: right.. but the thing is, on github it's almost instantly
02:16 mbrost: to be clear this our internal project, we plan on moving to the mailing list model soon
02:16 karolherbst: don't bother with mailing lists 🙃
02:16 mbrost: In perfect world yea I'd like to use gitlab as I much prefer that flow vs. mailing lists
02:16 karolherbst: just do it 🙃
02:17 jenatali: 5-10 minutes still seems crazy. I wonder if it is doing a real fork. That seems like bad design
02:17 karolherbst: afaik it is doing a real fork
02:17 mbrost: rodrigovivi is driving our strategy for getting Xe upstream / the upstream development flow
02:19 karolherbst: rodrigovivi: pls don't bother with a mailing list 🙃 (I'd totally love if drm would be the first subsystem to be like: "you sent a what? just use gitlab like normal people!"
02:19 daniels: it is doing a real fork, but it's not duplicating storage
02:20 karolherbst: why does forking take so long then?
02:20 daniels: mostly building indices afaik
02:21 karolherbst: ahh yeah.. it took like 5 minutes indeed
02:21 daniels: x.org has a contact with gitlab community people, could always take it up with them
02:21 karolherbst: maybe I just did cursed things with the nouveau one... let's see
02:25 karolherbst: btw, does drm-msm has some patchwork updating stuff set up? Otherwise I'll try my stuff out with nouveau and see how that works out
03:04 demarchi: daniels: currently there is only 1 runner allowed to run and it already has all deps installed, so not a big issue. Now that it's public, iff we want to use the fdo runners (should we?) we could rethink that
03:44 demarchi: daniels: mbrost_ but should probably talk with DragoonAethis / Radek. Not sure what the plans are for the CI... the gitlab setup is not being used for running tests, that is done in jenkins
03:48 demarchi: mbrost_: and Maciej... not sure if they are in this channel
05:15 anholt: wonder why dxvk doesn't like my RADV_PERFTEST=gpl :/
08:26 tzimmermann: mripard, mlankhorst, danvet, i'm trying to update drm-misc-next-fixes . wasn't this supposed to be as simple as 'git merge --ff-only drm-misc/drm-misc-next' ? that command fails
08:27 danvet: tzimmermann, two patches only landed in drm-fixes aftera drm-next took off
08:27 danvet: so ff not possible
08:27 danvet: I guess we could backmerge or you just force the update
08:28 tzimmermann: thanks, i do the backmerge
08:28 danvet: those 2 patches only made it into -rc3
08:28 danvet: well drm-next also hasn't moved yet
08:28 tzimmermann: danvet, is there a git option to show such conflicts?
08:28 danvet: git log drm-next..drm-misc-next-fixes
08:29 danvet: well drm-misc-next..drm-misc-next-fixes
08:29 tzimmermann: oh, too easy :D
08:29 danvet: :-)
08:29 danvet: airlied, ^^ should we backmerge?
08:39 airlied: danvet: yeah might be a good time
08:42 danvet: airlied, ok will do since I guess a bit late on your end
08:42 danvet: tzimmermann, ^^ you get a ping, might be a bit since I have meetings starting now
08:43 tzimmermann: don't worry
08:46 danvet: tzimmermann, maybe also backmerge into drm-misc-next so it's not out of sync too much either
08:47 tzimmermann: of course
09:29 cwabbott: gfxstrand: looks like I'm gonna have to add interval trees to your rb tree thing
09:29 cwabbott: ofc this is like 15 steps removed from some other project
11:31 bluetail: so if I compile mesa-git with 'gallium-drivers=virgl', how can I use it then in virt-manager? I am confused by the instruction given at https://wiki.archlinux.org/title/QEMU#virtio and I would be happy for a pointer. Hopefully this is the right place to ask
11:32 bluetail: I wonder though, it doesnt steal the vga from the host, as in pcie passthrough, right?
11:33 HdkR: Correct
11:33 HdkR: It's API passthrough using a virtualized GPU effectively
11:34 bluetail: Cool. Any pointers in how to use it in virt-manager ? I am just very confused by the instruction given.
11:34 javierm: bluetail: you need to add a virt-gpu device
11:35 bluetail: oh. that makes sense. thanks
12:11 bluetail: I did those things. But virt-manager running windows 10 still seems stuttery.
12:11 bluetail: is the acceleration working even at all with win 10?
12:15 bluetail: I think I did do something wrong. Cause virtio-vga is not listed in dmesg
12:16 bluetail: but I was able to select virtio with 3d acceleration and my 6950xt ...
12:29 bluetail: nvm... "the guest needs a driver for virgl, which as someone mentioned was never fully written for windows"
12:33 danvet: tzimmermann, backmerge pushed, I had some fun with the fb helper conflicts :-)
12:33 tzimmermann: danvet, thanks a lot
12:33 danvet: airlied, agd5f_ tursulin dolphin jani rodrigovivi ^^ fyi drm-next is now at -rc6
12:50 bluetail: hmmm https://github.com/virtio-win/virtio-win-pkg-scripts/blob/master/README.md
12:52 javierm: bluetail: ah, I only used Linux both as host and guest, have no idea how to do it with Windows as a guest
13:22 DragoonAethis: demarchi, mbrost, daniels: I'm here, just rarely visiting IRC - regarding CI we're in the middle of a cleanup project that should make it easier to work across mailing lists and GitLab, but in general most of it won't be driven from GitLab
13:23 DragoonAethis: It should be able to report results in a nicer way to GitLab though, instead of just posting loose comments as it does now
13:24 DragoonAethis: Re: drm-msm CI, is https://gitlab.freedesktop.org/gfx-ci/drm-ci the correct repo for that?
13:29 eric_engestrom: danvet: re ".nickmap", we have https://dri.freedesktop.org/wiki/WhosWho/
13:30 eric_engestrom: a bit more manual, but that about as much as you can do with irc
14:15 X512: What does DRM modifier mean? Tiling settings?
14:17 X512: Why DRM modifier is not supported for RADV driver and SI GPUs?
14:20 MrCooper: X512: yes tiling parameters, and because nobody has invented modifiers suitable for pre-Vega AMD GPUs
14:21 X512: Is it possible to introduce DRM modifier for Radeon SI? What is the problem? Tiling parameters do not fin in 64 bits?
14:22 emersion: there was a draft for it, but didn't get merged
14:22 emersion: requires more work
14:23 X512: Link to draft?
14:23 emersion: good question
14:25 emersion: bas wrote it
15:05 Ristovski: bluetail: I know there was some proof of concept work, but afaik the development has stagnated - https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/viogpu
15:05 Ristovski: There is also https://gitlab.freedesktop.org/spice/win32/virtio-gpu-wddm-dod, but idk how related that is
15:05 bluetail: javierm it turned out to be not good enough. Although then I had 60fps and 1920x1080, it was still too choppy and I couldnt get my audio stuff working and so chose another path.
16:24 Ristovski: Related to the questions asked by X512, is there some document outlining missing features for hardware? I feel like some of them could be "low hanging fruit" for people who would like to put in some time to improve their old hardware support
16:27 Ristovski: For example, I learned that amdgpu on SI (and CIK?) does not support VAAPI hw simply because no one ported over the required bits from radeonsi (I am sure it would be tedious due to differences in the driver architecture). I am sure there are other such examples
16:27 Ristovski: As they say, never underestimate the motivation of a bored person :P
16:29 kisak: "ported over the required bits from radeonsi" radeonsi being the mesa OpenGL driver does not make sense for a topic on vaapi. Did you mean radeon kernel module to amdgpu kernel module?
16:30 Ristovski: kisak: oh oops, yes
16:32 X512: UVD handling was recently added to kernel amdgpu driver for SI GPUs.
16:33 Ristovski: But not VCE, iirc
16:34 X512: Why radeon driver is still enabled as default for SI GPUs, not amdgpu? radeon driver do not work with RADV.
16:34 MrCooper: Ristovski: DRM modifiers aren't really low hanging fruit, the video acceleration issue was more complicated than that as well (related to the required microcode)
16:34 Ristovski: vainfo on my old machine seems to agree, only UVD is implemented on amdgpu
16:36 Ristovski: MrCooper: sorry, I gave a bad example for arguments sake as I couldn't remember anything else off the top of my head. However the point of "more documentation is better" still holds :P
16:37 MrCooper: X512: amdgpu doesn't support all the same functionality as radeon for older GPUs, and there's a high risk of regressions due to the huge number of systems running with radeon in the wild
16:37 X512: What kind of documentation do amdgpu developers refer? Something under NDA?
16:37 agd5f: X512, most developers work for AMD
16:37 MrCooper: I'd say better than switching the default would be making it easier for users to switch explicitly
16:37 Ristovski: I would assume so, the public information (stuff like ISA documentation) is quite lacking, especially for something like registers and other firmware related docs
16:38 emersion: they have some kernel docs
16:38 emersion: mostly high level overviews though
16:39 emersion: headers have registers
16:39 X512: It seems almost no documentation for low level GPU control such as loading firmwares, setup ring buffers, initalize RLC (not sure what is it exactly).
16:40 X512: Wrong GPU initialization order cause weirld issues like whole PC freeze.
16:41 Ristovski: emersion: I wouldn't really call those useful for anyone who isn't intimately familiar with the HW. A huge list of register names and their offsets (or values for chicken registers et al) without a note stating what they are for is hardly useful
16:46 agd5f: Ristovski, the vast majority of them are not really relevant to SW developers either. The driver only touches a small handful of them. The vast majority are really only interesting to HW designers.
16:47 kisak: Probably should point out the PDFs in the Open GPU Documentation section of https://developer.amd.com/resources/developer-guides-manuals/
16:47 X512: I am interested in Radeon GPUs low level documentation for implementing Haiku support.
16:47 emersion: ah yes
16:47 emersion: forgot about these as well
16:48 agd5f: there are links to various documents here as well: https://www.x.org/wiki/RadeonFeature/
16:49 X512: This seems newest relevant information available: https://amd.wpenginepowered.com/wordpress/media/2013/10/R5xx_Acceleration_v1.5.pdf
16:50 agd5f: X512, this one is newer: http://developer.amd.com/wordpress/media/2013/10/si_programming_guide_v2.pdf
16:50 agd5f: that said, the programming model hasn't really changed
16:51 agd5f: and this one: http://developer.amd.com/wordpress/media/2013/10/R6xx_R7xx_3D.pdf
16:51 alyssa: machine readable register names+offsets and reference code driving them is often more useful than docs ......
16:59 Ristovski: Oh the xorg wiki is not on gitlab? :/
17:05 Lyude: Ristovski: no, but we'd love it to be if someone has the time :)
17:05 Lyude: "make the website not crusty" has been on our todo list for quite a while
17:13 Ristovski: Lyude: In that case, how could someone help with that? I've always wondered why there isn't any "central" wiki for all of graphics instead
17:13 robclark: mmind00: any chance I could get you to look at a simple rockchip UAF fix, https://patchwork.freedesktop.org/series/113122/
17:14 Lyude: Ristovski: send an email to board@foundation.x.org
18:01 daniels: Ristovski: you could also take the nouveau wiki bits which generate a GitLab Pages tree from ikiwiki source, which is exactly what we need
18:01 daniels: that can be done from a personal repo
18:07 alyssa: mareko: anholt: It looks like, if SHAREABLE_SHADERS are supported, shader_has_one_variant is just checking desktop GL support
18:08 alyssa: Is shader_has_one_variant expected to be true for GLES contexts on GLES drivers (that otherwise rely on mesa/st variants for big GL)?
18:08 airlied: danvet: thanks!
18:08 alyssa: e.g. for vertex shaders, it checks clamp_vert_color_in_shader, lower_point_size, and lower_ucp
18:09 alyssa: none of which should be required on GLES
18:09 alyssa: (but which are set directly based on the CAPs without checking the API)
18:10 alyssa: ditto for fragment shaders (provided the driver doesn't need flatshading lowered or persample forced)
18:10 anholt: alyssa: anything I might have known about that is long since forgotten
18:10 alyssa: anholt: 100% valid
18:10 alyssa: thanks anyway :)
18:11 alyssa: hmm my drivers do need flatshading lowered, but maybe that's big GL only
18:11 alyssa: I know Mali architecturally isn't supposed to require variants for anything in GLES or VK
18:12 alyssa: right flatshade lowering is only for ShadeModel == GL_FLAT which afaik is a big GL only thing
18:12 alyssa: so yeah, my drivers ought to qualify for the fast path in GLES contexts, if not for the checks
18:15 alyssa: oh, but we precompile a default variant anyway
18:15 alyssa: that check is just about avoiding some hashing/lookups at bind time
18:15 alyssa: less interesting ^^
18:35 kusma: alyssa: glShadeModel(GL_FLAT) exists in GLES 1, and is supported in HW on at least earlier Mali GPUs...
18:43 kusma: Ah, but you might still need to lower that to the shader...
19:02 kusma: For gles, we should be able to do that in the ff shader generator...
19:09 anarsoul: kusma: out of curiosity, is it supported on Utgard?
19:24 alyssa: kusma: i mean GLES2/3 by GLES here
19:25 alyssa: "no shader variants for GLES2/3" is probably a design goal for Mali
19:25 kusma: Yup
19:25 alyssa: which Panfrost achieves on Bifrost and newer...
19:25 alyssa: on Midgard we have some rare variants when EXT_framebuffer_fetch is used with funny framebuffer formats
19:26 alyssa: but, close enough, nothing but the CTS hits that yet ;p
20:12 gfxstrand: Does Lyude not have a gitlab account?!?
20:17 danvet: gfxstrand, lyudess
20:18 alyssa: Lyude: we have an MR that needs your crAcked-by
20:20 gfxstrand: 😂
20:25 alyssa:needs to stop designing Vulkan drivers for AGX and do her homework
20:26 alyssa: ella-0: i blame u <3 uwu
21:05 alyssa: g
21:07 gfxstrand: q
21:42 gfxstrand: Does any hardware actually support write masks for global stores? I kinda don't think so.
21:48 pendingchaos: GCN/RDNA AMD hardware doesn't support write masks for global stores
22:09 gfxstrand: I kinda think no one does.
22:09 gfxstrand: I'm thinking about how to generalize brw_nir_lower_mem_access_bit_sizes.c
22:10 gfxstrand: Intel is weird because it can do an unaligned scalar of 8, 16, or 32 bits or a dword-aligned dword vector of up to 4 components.
22:10 gfxstrand: IDK how to express that.
22:12 gfxstrand: I'm kinda thinking the callback should return a tuple (bit_size, max_comps_per_op)
22:14 gfxstrand: Intel has some weird restrictions around load/store_scratch too. Need to figure those out.
22:46 hays: Is there a way to compile libEGL, libGBM, libGLESv* as one .so file
22:46 emersion: no…
22:48 hays: it seems theoretically possible, but maybe the organization of the makefiles make it impractical
22:49 emersion: why would you ever want that anyways…
22:50 hays: to implement a horrendous workaround
22:52 psykose: sounds better to fix the other thing
23:17 jenatali: Hm, is it expected that nir_intrinsic_load_push_constant doesn't have alignment info?
23:19 jenatali: That seems like an oversight
23:19 jenatali: gfxstrand: ^^ I think this is your domain
23:27 gfxstrand: Uh... No reason why we can't add it.
23:27 jenatali: Fair. Just was surprised it wasn't there. I assumed there was a good reason
23:27 gfxstrand: No one needed it yet. 🤷‍♀️
23:28 gfxstrand: bah. stupid terminal not knowing all the characters.
23:28 gfxstrand: I guess maybe I should consider using an IRC client from this millenia. 😅
23:29 gfxstrand: jenatali: Yeah, we should probably add it. The push constant space is an explicit layout space.
23:29 jenatali: Sounds good
23:30 jenatali: I want DOOM Eternal to work with Dozen, which means I get to add 16- and 8-bit type support. Except of course it doesn't follow CL alignment rules so now I have 6-byte alignments for stuff
23:30 gfxstrand: woof
23:30 jenatali: So I get to revisit all of the godawful lowering I had to write. Plus now push constants. Hooray
23:31 jenatali: But on the bright side I'm much smarter now than I was before :P
23:31 gfxstrand: :D
23:32 jenatali: I was also surprised that there's no alignments set on the casts from load_vulkan_descriptor
23:43 gfxstrand: In ANV, we go through and set them as part of anv_nir_apply_pipeline_layout
23:43 gfxstrand: In order to generate them in spirv_to_nir, we'd need to have the min alignments from the API plumbed through to spirv_to_nir().
23:43 gfxstrand: I guess we could do that.
23:43 gfxstrand: What's the worst that happens? Someone doesn't set them and gets zero?
23:44 gfxstrand:writes a patch
23:53 jenatali: I've got a patch for Dozen that adds them, yeah
23:54 jenatali: But I agree it'd be nice to do it in vtn rather than a "lowering" pass after the fact
23:55 gfxstrand: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21027
23:55 gfxstrand: jenatali: Let's see if that blows up Intel. If not, it's way cleaner.
23:55 gfxstrand: IDK why I didn't do that from the get-go, TBH.
23:56 gfxstrand: IDK.... That Jason guy made some really bad calls. So glad he's gone. :-P
23:56 jenatali: :P