00:01 alyssa: Company: agx doesn't have ubo's or ssbo's :}
00:01 alyssa: we just have raw pointers and push constants
00:01 Company: hurray!
00:02 alyssa: push constants can be filled out with bulk loads, but also written by a preamble shader running before the main shader
00:02 alyssa: so that arbitrarily complicated uniform expressions get optimized away
00:03 alyssa: e.g. if you write `foo + sin(ubo->rotation)`, we'll calculate sin(ubo->rotation) ahead of time and then turn the shader into just `foo + push constant`
00:04 alyssa: honeykrisp implements all of vk push constants, UBOs, and SSBOs as raw pointers and relies on the preamble to promote things to hw push constants
00:04 alyssa: app can do whatever, it's all the same
00:04 alyssa: exception: if robustBufferAccess is enabled, then UBOs are significantly faster than readonly SSBOs since UBOs have much more relaxed alignment rules
00:06 alyssa: the tl;dr is "just use UBOs"
00:06 alyssa: i think that's good advice on almost all hardware
00:07 alyssa: vk push consts are probably worse on mali but, mali should simply not do that.
00:07 alyssa: s/worse/better
00:07 Company: that seems to be what everyone ultimately tells me
00:08 Company: did you see my comment above about llvmpipe on the M2 Ultra?
00:15 Lynne: forcing a trace in vkqueuesubmit2 results in such a bad GPU crash that the GPU outright resets the entire system somehow
00:17 Lynne: profiling? in compute? what was I thinking, of course this is unsupported, vulkan only exists for vertex+fragment shader draws and immediate presentation, as god intended
00:19 karenw: That's not true and you know it. Now implementations assuming that is true... Or worse, Implicit Layers.
00:20 zmike: smh trying to compute before the year 2050
00:21 Company: Lynne: AMD?
00:22 Lynne: I once sneezed 15 kilometers away and it crashed, so yeah, AMD
00:22 Lynne: I'm used to it
00:22 Lynne: but I just want to profile a compute shader
00:23 Company: the good news is that when it doesn't crash anymore, it likely won't crash anywhere else ;)
00:23 Lynne: we're not in 1995 you know?
00:23 Lynne: we don't just run a single program at a time with strictly fixed hardware state on init
00:24 Company: GTK 4.16 so far hasn't managed to crash a GPU I think
00:24 Company: and I wrote that code on AMD
00:25 Lynne: vertex+fragment shader only, nothing which was introduced past 2017 in the API, right?
00:26 Company: unless you count dmabufs and video stuff
00:27 Lynne: ✔️as god intended
00:27 Company: but then, I get to have my stuff run on semi-complete mobile drivers
00:27 karenw: If the linux AMD drivers can manage to keep my cursed setup working for everything but sleeping with SDDM, I call that pretty good.
00:28 karenw: (Dual graphics, low power/primary is radeon, high power/secondary barely sneaks through the minimum for amdgpu, with custom kernel params)
00:29 Company: we're all pampered anyway because we use Mesa - which is way less broken than most other drivers and it's open source
00:31 Company: the 2 worst Vulkan drivers for GTK 4.16 are nvidia - it kills dual-GPU setups on Wayland with 2 different nasty bugs - and amdvlk which doesn't get dmabuf transparency right
00:34 alyssa: Company: is hk a mobile driver
00:34 alyssa: (:
00:35 Company: sometimes
00:36 Lynne: I've never been able to crash nvidia GPUs
00:36 Lynne: though I'm always using the GSP firmware regardless of which drivers I run
00:37 Company: the worst thing about nvidia's drivers is the wsi
00:37 Lynne: and now to do something as common as profiling I'll have to install their tools at some point
00:39 Company: but when I did Vulkan stuff on nvidia in 2016, it was really forgiving compared to all the other drivers
00:39 Company: which was bad for development, because things would work fine until I tried them elsewhere
00:46 karenw: Vulkan validation is an awful lot better than 2016
00:46 karenw: Also NV doesn't have proper vsync/anti-tearing, but I'm told that's fixed upstream.
01:30 DemiMarie: Lynne: which driver?
01:31 DemiMarie: nevermind, didn’t scroll down far enough
02:53 serialsniffer: realexecution requires not to count bits at all in the encoder nor decoder. It's most important class is where 32invariant power states as 32 combinations is calculated by the combination calculator which is one of the most important class. So 32bit states are in digital notation, 1024*1024*1024*4-1 giving a maximum boolean one digits amount. so three first 1024's are operands and carry
02:53 serialsniffer: in ieee1164 , so if sequences of 1's needs to be counted only by hw it would carry to another position, hence the third *4 notation is intraoperand truth table. which means that four rounds of packing/encoding shows that we can use to get to 32invariant weights of powers at base32 with encoder that has 3power and 3overit powers bits, it is just that you never inspected the calculator's
02:53 serialsniffer: bit states and their corresponding decimal digital values and it appears you never delt with combinations and permutations lecture in maths.Hashed/checksummed Execution is super easy theory.
06:24 tzimmermann: airlied, sima, please don't forget to merge last week's PR for drm-misc-fixes https://lore.kernel.org/dri-devel/20240926121045.GA561653@localhost.localdomain/
06:26 airlied: tzimmermann: did I just push that out?
06:30 tzimmermann: airlied, apologies, i didn't notice.
06:30 tzimmermann: dim status now says it's been merged
06:30 tzimmermann: thanks
06:31 tzimmermann:promises to not use irc before having the first coffee in the morning
10:00 Shibe: Hi, I have a 7800x3d and am trying to do AV1 encode. But vainfo does not indicate AV1 encode support, only decode: VAProfileAV1Profile0 : VAEntrypointVLD (no encslice). Is this a bug because it says online av1 encoding is supported and apparently it works with AMF too
10:02 K900: AV1 encoding is RDNA3 and up I'm pretty sure
10:07 Shibe: oh, well that's dissapointing. thank you!
10:51 Caterpillar: what a coincidence, I am right now browsing radeonsi code to check why H264 is not enabled on my RX480, and perhaps try to start working on a patch
10:52 Caterpillar: (RX480 vainfo https://paste.centos.org/view/7628a724 )
10:53 Shibe: are you on fedora by any chance?
10:56 Caterpillar: Shibe: yes F40
10:56 Shibe: Caterpillar: fedora doesnt include vaapi drivers for proprietary codecs by default, you need to install the freeworld drivers
10:56 Shibe: https://rpmfusion.org/Howto/Multimedia#Hardware_codecs_with_AMD_.28mesa.29
10:56 Caterpillar: Shibe: thank you very much, I will look at it immediately
10:56 Shibe: but i have a polaris card and hardware video is pretty hit or miss anyway
10:58 Caterpillar: Shibe: I now installed the mesa from rpmfusion, I am now rebooting to enable them
11:05 Caterpillar: Shibe: it works, look at the new vainfo output ! https://paste.centos.org/view/0fd6c2fb Thank you very much, you saved me a huge amount of time I would have spended in investigating this
13:20 bbrezillon: mripard, mlankhorst, tzimmermann: I have a few fixes I'd like to see in -rc2, could we merge 6.12-rc1 into drm-misc-fixes?
13:21 bbrezillon: actually, I also need a backmerge in drm-misc-next
13:22 tzimmermann: bbrezillon, i won't have much time today
13:23 tzimmermann: ping me tomorrow, if the problem persists
13:35 bbrezillon: tzimmermann: let's see if mripard or mlankhorst can help with that, otherwise I'll ping you tomorrow
13:38 bbrezillon: BTW, is there a rotation between you three, and if there is, is this documented somewhere?
13:53 DemiMarie: Caterpillar: You can also use Flatpaks for the programs that need patent-encumbered codecs.
13:56 Caterpillar: DemiMarie: thank you
14:13 Lynne: I don't know if it's just me or anything but for the past 2 months zink has instantly crashed amdgpu regardless of what it's used for
14:14 Lynne: even glxgears crashes the gpu
14:14 Lynne: not sure if it's a radv or a zink regression
14:14 Lynne: it's not a kernel regression though
14:54 marc2377: Hey guys. Which is faster / more modern? fbdev or vesa? (My hardware doesn't seem to support uvesa because it's VBE version 1)
14:54 marc2377: I'm compiling and about to test drm-openchrome (and its DDX driver), but want a fallback to my Via Unichrome Pro chip
14:54 marc2377: (Sent this to the wrong channel just now)
14:55 marc2377: Guess this is the correct place to ask
15:13 DemiMarie: Lynne: If you are logged in via SSH, can you recover the GPU?
15:15 DemiMarie: My understanding is that if the GPU locks up until reboot, that is a driver or firmware bug.
15:16 MrCooper: Company: dma-buf fds have been used for sharing buffers for over a decade
15:17 Company: yeah, but not as widely
15:19 Company: that screen sharing via pipewire ends up with a fully dmabuf pipeline through gstreamer ending with getting the dmabufs imported into the application is a pretty new thing
15:28 MrCooper: ah, PipeWire, you didn't qualify that before
15:28 MrCooper: it's used with DRI3, which has been the default for direct rendering on X for about a decade
15:35 Ermine: marc2377: to the best of my knowledge the most modern way on your hw should be simpledrm
15:39 marc2377: Ermine: Thank you for making me aware of that. I'm looking into it.
15:39 mlankhorst: bbrezillon: got any justification I can use?
15:40 mlankhorst: For -fixes I usually try to fast-forward and leave it be, unless there is a specific fix that only matters in rc2 for example
15:43 Company: MrCooper: that was just an example - I've seen ephy switch to dmabufs, the qemu-dbus stuff uses dmabufs (though I guess virtualization used it before, too) and GStreamer's dmabuf stuff was mainly part of 1.24. No idea how long ago ffmpeg started using it and if mpv can do dmabufs already
15:44 Company: MrCooper: dmabufs existed in the fringes - v4l produced them and libva did - but until recently those were almost immediately put into GL textures and then people shuffled GL textures around
15:45 MrCooper: a matter of perspective I guess, DRI3 isn't fringe to me :)
15:45 mlankhorst: It was even more obscure when I first used them. O:)
15:46 Company: inside the freedesktop world, dmabufs were invented, so I expect you to have used them for a while
15:46 mripard: mlankhorst: I still think we should forward it, because it looks like our -next tree isn't live
15:46 Company: but outside of X/Wayland/Mesa, they've recently taken off
15:47 marc2377: I'm still very curious about whether fbdev or vesa is more modern and preferred. I see vesa support was added in kernel version 2.6.20 (2007-02-04), and fbdev was added in 2.1.109 in 1999. That's the most info I could find
15:48 marc2377: I don't know if any of those are obsolete
15:49 K900: Do you mean vesafb?
15:49 K900: Or what?
15:50 Company: MrCooper: and I've excluded our use in GTK so far, but that's obviously also a part of it that by accident coincided with the general increase. I think GTK is also one of the (few?) clients that uses linux-dmabuf-v1 outside of Mesa
15:53 marc2377: yep, vesafb
15:54 K900: vesafb and fbdev are not some mutually exclusive things
15:54 K900: vesafb is a driver in the fbdev subsystem
16:06 bbrezillon: mlankhorst: yep, sorry, that's for https://patchwork.freedesktop.org/patch/615226/
16:06 marc2377: K900: Thanks for clarifying. But, there is 'xf86-video-vesa' and 'xf86-video-fbdev' on Arch Linux
16:06 bbrezillon: it fixes at bug introduced in by tree-wide change, and this bug only exists in Linus tree at the moment
16:07 bbrezillon: it makes panthor unusable on 6.12-rc1
16:07 DemiMarie: marc2377: Neither should be used. If you must use Xorg, use simpledrm with the modesetting driver, but if you can use Wayland that would be even better.
16:07 K900: marc2377: The xf86-video drivers are ancient and dead
16:07 K900: You should not be using any of those
16:08 marc2377: Thank you folks
16:08 DemiMarie: Company: Does that mean that GTK4 does not use the Vulkan WSI?
16:08 marc2377: Now just out of curiosity, which is more ancient and "worse"? lol
16:09 bbrezillon: mlankhorst: fast-forward works for me, if that's an option
16:10 bbrezillon: I just needs what's in -rc1
16:10 DemiMarie: marc2377: vesa
16:11 marc2377: _danke!_
16:11 mlankhorst: bbrezillon: pushed a backmerge of drm-fixes
16:13 bbrezillon: mlankhorst: thanks!
16:22 Company: DemiMarie: (ignoring for a moment that GTK can use either GL or Vulkan) GTK's offloading tries to attach application-provided dmabufs directly to the wl_surface
16:32 MrCooper: Company: FWIW, apparently that's not allowed with Vulkan WSI, it assumes total control of the wl_surface
16:32 Company: we use different surfaces
16:32 Company: for that very reason
16:33 MrCooper: good
16:33 Company: the good thing is that we can place subsurfaces above/below the main surface, so a lot of tricks are possible
16:34 Company: but yes, I try to make very sure that we don't switch who "owns" a surface to avoid things tangling up
16:34 Company: so the error 71 stuff is never my fault ;)
23:13 ngcortes: zmike, ping?
23:14 Sachiel: don't think he's around now
23:47 Company: airlied: llvmpipe or lavapipe?
23:47 Company: or in other words: for software rendering, should GTK use GL or Vulkan?