00:00 gfxstrand: I've got a pretty good stack of NVIDIA cards but my daily driver is still my trust XPS 13.
00:00 gfxstrand: I am a little annoyed at the lack of good NVIDIA laptops.
00:01 Company: I think gettng dual gpu laptops is probably a nice approach - because then people can fallback to intel and get work done if things are broken on nvidia somehow
00:01 gfxstrand: I had this fantastic 13 or 14-inch Razer a few years ago (had to give it back to Intel, sadly)
00:02 gfxstrand: Hrm... Razer Blade 14 might not be a bad choice...
00:02 gfxstrand: It's NVIDIA+AMD not NVIDIA+Intel
00:03 Company: that sounds like lots of fun with breakage can be had there
00:04 gfxstrand: TBH, having a laptop where I can hack on NVK and RADV at the same time doesn't sound like a bad thing.
00:05 Company: and you can fix all the dmabuf handoff problems between the 2 drivers
00:06 Company: I have 2 AMDs in my desktop atm, but once I start playing my first UE5 game, I'll need a new GPU
00:07 gfxstrand: Company: I don't need to fix dma-buf handoff in order to run CTS tests. :P
00:07 Company: gonna do the gaming on Windows most likely, so the driver is not the issue, and AMD vs nvidia will be a question of what allows me the best experiments when developing
00:08 Company: I should learn to write CTS tests at some point
00:11 Nefsen402: I was recently shopping for a new laptop and ended up going with the questional decision of putting asahi linux on it. I already have a x86 desktop with 2x AMD gpus for dev anyway
00:13 Company: people using asahi have been very useful already and found some dumb issues with gnome's GLES usage
00:14 Nefsen402: Only super custom thing I did to it was patch sway to teach it about the notch with fullscreen stuff
00:20 Company: The high-level problem I have is still that application developers have no clue about GPUs
00:20 Company: everyone learned to work with Cairo, and Cairo is all CPU
00:21 Nefsen402: but bezier curves on the GPU is hard
00:21 Company: and when they use a GPU, they all have Intel, so the assumptions made about performance and whatnot are all learned from using that
00:22 Company: most importantly, the GPUs are all integrated, so people assume no memory transfer time
00:22 Nefsen402: rip wayland compositors that transfer shm textures while blocking the main thread...
00:23 Company: for example
00:24 Company: also, Intel laptops (at least pre-xe) are noticably slower when running shaders than dedicated GPUs
00:25 Company: but that's not even the bad thing
00:26 Company: the bad thing is when people assume every GPU supports the same formats Intel does
00:26 Company: or when nobody notices that the AMD cursor plane is scaled with the AMD primary plane because the Intel one isn't
00:26 Company: and stuff like that
00:27 Company: and the more people you have around that you can ask "hey can you test my branch works on your gpu", the better the code is gonna be and the less likely people are to misdesign stuff
00:28 Company: like https://www.qemu.org/docs/master/interop/vhost-user-gpu.html#vhostusergpudmabufscanout
00:29 Company: just assuming 1 plane for dmabufs, because it's always RGB anyway and that's just 1 plane, right?
00:29 Company: on Intel, it indeed is
00:29 airlied: gfxstrand: I don't think we need 1.3 to ship it, I'm pretty happy with the feature set we have right now
00:30 airlied: like yeah DXVK is the end goal, but I'm fine with that taking a bit longer
00:30 Company: do nvtop or radeontop work with nvk?
00:30 airlied: do they talk to vulkan drivers?
00:30 airlied: I'd have though they talked to the kernel
00:30 Company: I have no idea
00:31 Company: I just want an app that I can tell random developers to run so they can see if their app is CPU or GPU limited
00:32 Company: nvtop is a simple one, radeontop is a complicated but really useful one
00:32 Company: because nvtop doesn't show the GPU clock speed, and AMD is shown at ~70% no matter how much load there is
00:33 airlied: I think that would take some kernel development with GSP, I don't think we have any idea how to get access to stats yet
00:34 Company: would be nice to have a tool that worked with all gpus and that was commonly available
00:34 Company: but I guess that's not a new idea
00:39 Company: gfxstrand: looking through the mesamatrix, it says nvk doesn't do VK_KHR_incremental_present - is that an oversight somewhere?
00:40 gfxstrand: airlied: I'm less worried about feature set and more worried about general stability and how comfortable I am dealing with bug reports and backporting patches.
00:40 gfxstrand: Company: probably
00:41 Company: it's kinda important for desktop apps (that actually use Vulkan)
00:46 airlied: gfxstrand: not too worried about backporting patches, we can just roll fedora forward to the next release, I don't think we have anything that really depends on vulkan yet in the distro normal paths
00:46 airlied: like maybe someday gtk vulkan will get made the default
00:47 gfxstrand: airlied: Would you split NVK into a separate package or roll all of Mesa forward?
00:48 airlied: gfxstrand: we generally just roll all of mesa
00:48 airlied: it's something we do semi regularly
00:49 gfxstrand: kk
00:49 airlied: it hasn't really been that scary since we got CI
00:50 airlied: the odd WSI or someone tried to load zink automatically again and screwed up
00:50 airlied: I think it'll be scarier if we try and make zink the default GL for nvidia GPUs
00:57 mareko: DemiMarie: you can put Mesa into Android and then you can have virtio and native context
01:00 Company: airlied: the main reason I'd want to default Vulkan on GTK is because Mesa devs think it's a good idea
01:00 gfxstrand: It's probably a good idea on NVIDIA. :P
01:01 airlied: yeah I'd rather gtk used vulkan
01:01 Company: I'm not really into GTK being the one to find all the bugs with Vulkan unless I get buy-in into fixing things
01:02 Company: but the new renderer (once I land it, which should be before christmas) is definitely faster with Vulkan
01:02 Company: it doesn't integrate well with all the external GL stuff though
01:02 Company: and it suffers from Vulkan not doing dmabufs without modifiers
01:03 Company: and lots of places still handing out those things
01:05 Company: it also doesn't help us as long as gnome-shell still uses GL
01:06 Company: and gnome-shell has a much harder time converting to Vulkan, because they have infrastructure where they printf-build their shaders at runtime
01:07 Company: so they either need to include some glsl-to-spirv compiler or they need to refactor their code
01:10 Company: airlied: fwiw, my assumption so far was that RHEL10 was not interested in Vulkan - or even: interested in not Vulkan
01:11 Company: which is why I didn't prioritize a Vulkan transition very much
01:13 Company: and the 3 arguments for Vulkan in GTK could be RHEL10 wanting it, GPUs having better support for Vulkan over GL (and of the new drivers only nvk could qualify for that, asahi went GL first) or GTK having any needs
01:14 Company: and so far the only thing that Vulkan can do that GL can't - or at least not as well - is allocate dmabufs, but we don't need to do that yet in our API
02:04 airlied: Company: yeah gnome-shell would be a major amount of lift, esp with cogl and clutter in the mix
02:06 Company: it seems my secret plan to split the shell into compositor + panel processes and redoing the panel in GTK is still alive
02:12 airlied: yeah redoing all the clutter/cogl stuff in gtk4 would probably make life a lot easier
02:12 airlied: though at what point a g-s reboot would have made sense before now I'm not sure :-P
02:17 Company: I think it was a good idea to keep things separate
02:18 Company: GTK3 had a ton of limitations that the UI designs of the shell would have bumped again
02:18 Company: and I'm not sure that GTK4 is good enough for certain things that the shell does
02:21 Company: but things are converging - in terms of UI designs not being too different, in GTK gaining the interesting features and most importantly in developers talking more with each other
02:23 Company: up until 4.0.0 - and probably a while later - we were mostly concerned with API design and how applications want to use what we put out
02:24 Company: I've since pivoted towards working with the lower layers again to figure out new features we can expose to apps - like for example the dmabuf stuff
02:26 Company: and people are learning that GTK is doing 100% of the rendering on the GPU, which is also interesting
02:27 Company: 90%, we still render the glyphs masks with cairo
02:53 alyssa: Company: fwiw i stand by my decision to go gl first, it was the right call afaict
02:53 alyssa: completely different set of constraints than nvk had
02:55 Company: why did you decide on GL?
02:57 airlied: GL is easier to get a driver started when you are RE'ing
02:57 alyssa: landscape 3 years ago when this started ... early r/e and needed something for r/e, easier to write a gallium driver than vk
02:58 alyssa: and then a year later .. wanted to get accellerated gnome/kde/etc into user hands asap, that was (is?) all gl
02:58 alyssa: (zink has improved a lot in 3 years, i'd also add.)
02:58 Company: would you decide differently today?
02:58 alyssa: Not sure.
02:59 alyssa: the other issue is... I know how to write gallium drivers, not yet vk drivers
02:59 alyssa: being able to ship competent gl very very fast was a sure thing for me
02:59 alyssa: being able to ship competent zink on vulkan... much less sure
03:00 alyssa: (similarly the vk runtime is a LOT better now than 3 years ago. thanks to gfxstrand's heroic nvk work)
03:01 alyssa: anyway, once all the hard problems are solved for gl, theoretically adding vk should be "easy"
03:01 alyssa: and then we'll have everything and yeah
03:01 alyssa: we're all going to the same place, just different order to get there
03:01 Company: and then you can delete the gl driver and switch to zink!
03:01 alyssa: probably not
03:02 alyssa: our gl driver is competent and takes advantage of hw that can't be exposed in vk
03:02 alyssa: i don't see any reason to drop it even if zink+agxv is at feature parity
03:02 alyssa: even for nvidia, writing a fresh gallium driver is very much in the cards
03:03 alyssa: ^a possibility
03:03 alyssa: zink solves real problems
03:03 alyssa: it just doesn't solve any of mine right now
03:04 Company: zink is excellent at showing me I did something wrong, when the GL version of my renderer is faster with zink than my Vulkan version
03:04 alyssa: lol
03:06 Company: it's a really interesting comparison - native GL vs zink vs Vulkan
03:06 Company: it's how i figured out that Mesa is (was? I didn't check in a while) better at compiling GLSL than it is at compiling spirv
03:08 Company: but I take it that we've still not quite reached the point where Vulkan is preferred over GL - both on the app and the driver side
03:08 Company: any day now, but not yet
03:10 airlied: alyssa: what hw features are there not exposed btw?
03:22 mareko: it would be difficult to outperform zink with vulkan API in some cases
03:25 mareko: where zink doesn't do well is when it needs to emulate something for Vulkan that the underlying hw can do
03:26 mareko: it's fixable
03:27 mareko: is zink+nvk faster than nvc0? or do they both target completely different hw?
03:29 airlied: I think nvc0 has a lot of problems, so I suspect zink will be faster
03:29 airlied: but once you add in having a competent compiler, I think saving nvc0 will be hard
03:29 mareko: I quite suspect the same thing
03:30 airlied: if I thought it was worth it I'd write a new gallium driver
03:30 mareko: zink also uses all of the multithreading in the common code that nvc0 doesn't
03:30 mareko: and other fast paths
03:30 airlied: I'd hate to try and enable any of that in nvc0
03:32 airlied:is just trying to get zink/nvk closer to GL 4.6 conformant now
03:34 mareko: I guess nvc0 removal is also on the table
03:34 airlied: I think it will live forever pre-kepler
03:35 airlied: maybe I'll feel like doing a crocus on it someday :-P
03:41 mareko: I should run viewperf on zink some day, it might be interesting
03:43 mareko: and same for aco
05:42 gfxstrand: Yeah, beating nvc0 is not a high bar....
05:42 gfxstrand: TBH, that's the only reason why Zink is a viable plan for nouveau
05:43 gfxstrand: If we had a competent GL driver, we probably wouldn't be nearly as quick to talk about tossing it.
05:43 gfxstrand: But nvc0 is NOT a competent GL driver by any means.
05:44 gfxstrand: And, yeah, AGX constraints are very different from NVK constraints.
05:44 gfxstrand: AGX is "We have nothing and we want GNOME running ASAP" while NVK was "We have a shitty GL driver that runs your desktop fine but people want to be able to play games."
05:45 gfxstrand: With the second, "Vulkan + DXVK or bust!" is a reasonable take. With the former, it's way less clear that that's a competent plan.
05:45 gfxstrand: IDK that REing GL is any easier than Vulkan.
05:45 gfxstrand: But getting GNOME to run on native gallium is a hell of a lot easier than GNOME on Zink on Vulkan.
10:43 melissawen: hi, I'm always unsure of where to apply a patch. Should I apply this drm fix: https://lore.kernel.org/dri-devel/20231108163647.106853-2-harry.wentland@amd.com/ to drm-misc-fixes or drm-misc-next?
10:45 mripard: melissawen: my personal metric is whether or not it actually fixes something, or if it's theoretical
10:47 mripard: so if it's tied to a bug or breakage, it goes to -fixes
10:47 mripard: if it's just something that was noticed but doesn't really affect anyone, -next
10:54 melissawen: mripard, got it. Thanks for explaining. I checked who is using this function and indeed I need an ack from msm people too.
10:55 melissawen: it seems they put conditionals to zero values that prevent the bug in their side
11:08 tnt: In vulkan compute shader, is several thread of a local group writing to the same shared variable a defined behavior ? I have a shared bool initialized to false and then threads can set it to true but seems if several do it, it ends up none of the write succeed and it keeps being evaluated to false.
11:12 dj-death: tnt: likely undefined
11:12 dj-death: tnt: use atomics if you write to the same location using multiple threads
11:13 tnt: dj-death: thanks, I'll look into that. (the bool is a termination condition so the shader is while (!g_done) { ... do something that might set g_done ... }. )
13:12 hakzsam: cwabbott: would you be able to take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25590#note_2135679 ?
13:50 sima: mripard, so one think I realized while doing my fri workout is that drm_atomic_commit could have a risk for a commit_commit function name
13:51 sima: but the few I checked look all good, like drm_atomic_check|commit|nonblocking_commit
13:51 sima: but if we have a really awkward one then maybe atomic_update and more renaming could be the winner instead
14:01 mripard: jani: thanks for the follow-up patch
14:02 mripard: sima: I think it'll work out with commit, and yeah, worst case scenario we can catch it during review
14:02 pq: hwentlan__, I finally took the time to go through your colorop series. Please, take everything I said as observations and suggestions, and nothing more.
14:53 jani: mripard: np, I hope it fixes the CI issues we're having
23:44 mareko: daniels: FYI, kernel 6.5 (or 6.4?) has a new mitigation for an AMD CPU security vulnerability in Zen 1-4 (Speculative Return Stack Overflow), which can double the time for piglit to finish in CI
23:45 mareko: we haven't seen any notable difference in GLCTS and dEQP run times except dEQP-EGL, which can take 10x longer to finish
23:46 mareko: booting with spec_rstack_overflow=off disables the mitigation
23:47 daniels: mareko: thankyou! that’s really helpful
23:47 daniels: DavidHeidelberg: ^
23:49 mareko: dEQP-EGL = 10x longer, piglit = 2x longer, others = not much difference