01:42Company: I get a lot of "Bus error (core dumped)" when handing AMD drivers udmabufs
01:42Company: Is that a known issue? Is that even meant to bee supported?
01:42Company: I'm running testsuite stuff that usually uses llvmpipe, but I tend to forget the env var
01:43Company: *GTK testsuite stuff
06:35Lynne: AndrewR: version 4 is experimental
06:52Lynne: the software encoder also has this error
06:52Lynne: use -slicecrc 1 or -slicecrc 0
07:13MrCooper: Company: sounds like an amdgpu driver issue
07:21Company: so I'll check it's not actually my fault and then file it
07:55MrCooper: Company: what operation exactly triggers the bus error though?
08:02Company: MrCooper: I don't remember, it happened 2 or 3 times but I just added the llvmpipe env var and kept doing what I was doing
08:04MrCooper: presumably it involves mmap, does that use the dma-buf fd or the DRM fd?
08:06Company: it does - but I don't have mesa with debug symbols atm
08:07Company:just managed to reproduce
08:07Company: https://paste.centos.org/view/131abe17
08:07Company: not very useful though
08:08Company: that's that's with Mesa from Fedora packages
08:14Company: that's a 256x256 AR24 dmabuf, so the most standard you can get
08:14MrCooper: AFAICT Mesa uses the DRM fd for mmap, so still pointing to amdgpu
08:14MrCooper: guess it might end up being a udmabuf issue though
08:15Company: I've only seen it with udmabufs
08:16Company: but llvmpipe and AMD Vulkan deal with it fine
08:16MrCooper: AFAIK the importing driver is supposed to forward mmap to the exporting driver, so in principle it could be an issue in either of them
08:17Company: do you have a GTK main checkout?
08:18MrCooper: I can easily get one
08:19Company: lemme see first if this reproduces on main
08:20Company: https://paste.centos.org/view/e5e43d47
08:20Company: save as foo.node, then run:
08:20Company: GSK_RENDERER=cairo build/tools/gtk4-rendernode-tool show --undecorated foo.node
08:20javierm: tzimmermann: any objections on pushing https://lore.kernel.org/dri-devel/20395b14effe5e2e05a4f0856fdcda51c410329d.1747751592.git.geert+renesas@glider.be/ to drm-misc-next ?
08:21tzimmermann: javierm, no, please go ahead
08:21Company: GSK_RENDERER=cairo forces a download of the dmabuf into host memory, and that's where GL comes in
08:21javierm: tzimmermann: Ok, thanks
08:21tzimmermann: sorry i forgot about that issue
08:23javierm: tzimmermann: no worries
08:24MrCooper: Company: reproduced
08:24Company: good
08:31dj-death: anybody knows why the iand/ior/etc.. opcodes have uint types in nir_opcodes.py?
08:32dj-death: sounds odd not to have them named uand/uor etc... ;)
08:38MrCooper: Company: can you file an issue at https://gitlab.freedesktop.org/drm/amd/-/issues ? I'll add a comment with my findings
08:38Company: sure
08:57Company: MrCooper: https://gitlab.freedesktop.org/drm/amd/-/issues/4267
09:02MrCooper: thanks, I added an empty line between <summary> and ``` in the description (this is needed for the ``` block to be formatted correctly in <details>)
09:06Company: and I thought I had checked the preview
09:07MrCooper: added a comment with my hypothesis and possible solutions
09:09Company: MrCooper: now I'm curious: Would that bus error happen with dmabufs imported from a 2nd gpu, too - say an intel igpu?
09:09MrCooper: if my hypothesis is correct, yes
09:09MrCooper: any dma-buf exported by a different driver
09:16glehmann: dj-death: I don't think there's a particular reason since signedness doesn't matter for those ops
09:17glehmann: does it cause an issue for you or are you just curious?
09:27Company: MrCooper: different GPU isn't enough I think - I used MESA_VK_DEVICE_SELECT to select my AMD igpu to create a dmabuf, but the dgpu imported that one without complaining
09:27MrCooper: yeah, same driver
09:29MrCooper: TTM refuses to fault in pages from a different driver
09:29MrCooper: s/pages/BOs/
09:42dj-death: glehmann: I think maybe it does, but I could also argue our backend isn't well designed :)
09:43dj-death: glehmann: types encode all kinds of conversions etc...
09:43dj-death: glehmann: it's very error prone for copy propagation etc...
09:45MrCooper: Company: hmm, actually not sure if it's same driver or same device which matters for that TTM code, the latter would mean my hypothesis isn't quite right
09:48glehmann: dj-death: actually I think there might be a reason, some nir search helpers like is_pos_power_of_two depend on the type of the opcode (bad design if you ask me, but I guess it is what it is)
09:51glehmann: is intel's backend IR fully typed?
09:53dj-death: yeah
09:54dj-death: I think if we had virtual conversion opcodes it would help a bunch
13:12alyssa: dj-death: it's i because it's not specifically signed or unsigned
13:12alyssa: arguably it's imin/imax that should be renamed to smin/smax
13:12alyssa: (and ilt/ige to slt/sge, etc)
13:29dj-death: alyssa: thanks
13:30alyssa: ultimately it's not a super consequential bikeshed and conventions differ
14:39zmike: it's wild that all this insane gallium refactoring is managing to fix a nonzero number of bugs
14:53MrCooper: so long as it's not negative :)
14:53zmike: me? create bugs?!
14:53zmike: I would never
18:08AndrewR: Lynne, https://trac.ffmpeg.org/ticket/11612#comment:5
18:45AndrewR: Lynne, also does ffv1_vulkan support p010 pixel format? When I tried to just decode that HDR vid it said p010 not supported ...
18:46AndrewR: Lynne, also, does ffv1_vulkan support encoding from software decoders? I was unable to create working ffmpeg line ...
19:00Lynne: AndrewR: p010 is not supported
19:00Lynne: you need to use either p016 or yuv420p10
19:01Lynne: its a hardware encoder, you have to upload frames to it
19:02AndrewR: Lynne, problem is, AMDs decoder output p010 if video was hevc10 ...
19:03AndrewR: Lynne, do yu have ffmpeg line where ffmpeg decodes vi on cpu and upload to ffv1_vulkan ? I tried few hwupload,format strings but none worked for me ...
19:08Lynne: you can convert p010 to p016 or yuv420p10 with libplacebo
19:08Lynne: in hardware
19:08Lynne: you need format=,hwupload
19:14AndrewR: Lynne, ~/bin/ffmpeg8-vk -init_hw_device vulkan -i ~/0005.avi -vf format=yuv420p,hwupload -version 4 -strict -2 -an -c:v ffv1_vulkan test.avi -loglevel debug - just exit with code 0 o.O
19:15Lynne: why are you so bent on encoding subsampled content?
19:15Lynne: its not what the coder is popular for
19:15Lynne: nor the way its used generally
19:15AndrewR: Lynne, its VIDEO encoder after all
19:16Lynne: so is prores, but you don't see anyone using prores at anything but 422
19:16Lynne: remove the debug and -
19:17AndrewR: Lynne, ffv1 was recommended for video preservation. It will be silly to not use it on video .
19:17AndrewR: - ws just my way to indicate sentence structure. Without debug it just exit. No encoder statistics no nothing
19:24linkmauve: Why is 4:2:2 more popular than 4:4:4 for that usage, btw?
19:25AndrewR: linkmauve, smaller?
19:31Lynne: works fine here
19:32Lynne: do not use avi, under any circumstances, ever
19:44AndrewR: Lynne, this is file from 2003 ....
19:46Lynne: don't output to file formats popular from 25 years ago
19:46HdkR: Friends don't let friends AVI
19:46dwfreed:hands out some mkv
19:47ccr: the first few bytes are free?
19:48AndrewR: Lynne, same with mkv. Do you ahve 32-bit chroot? All this testing on my side hybrid 64/32bit system.
19:48Lynne: no
19:48Lynne: I'm not sure 32-bit systems would ever work though
19:49Lynne: vulkan requires 64-bit addresses
19:49AndrewR: Lynne, it works so far ...
19:49Lynne: you said it exits
19:49AndrewR: Lynne, hw pipeline with libpllacebo and vulkan decode and ffv1_vulkan worked. also vc2_vulkan encoder worked
19:50Lynne: then what is the problem?
19:52AndrewR: Lynne, sw decoder + ffv1_vulkan encode
20:12glehmann: alyssa: do you remember why you only added no_fp16 for browser on agx? do they not try to use mediump on other drivers on their own? https://gitlab.freedesktop.org/mesa/mesa/-/issues/13256
20:14alyssa: glehmann: there is so. much. broken. webgl content out there
20:15alyssa: and i haven't seen mediump actually help performance for things that aren't synthetic benchmarks
20:15glehmann: yes, I know, the issue might be one example of that. I'm just trying to think of a reason why it wouldn't show up in firefox on radeonsi
20:15alyssa: and because desktop drivers ignore mediump traditionally, people will report agx driver bugs for things that incorrectly use mediump
20:16alyssa: the driconf just brings us into alignment with the big kid drivers
20:16alyssa: I'm not sure where radeonsi fits
20:16alyssa: I also dunno if this is still relevant now that we ship gl4.6 which firefox will probably pick over gles3.2 (maybe?)
20:17alyssa: (and big GL never had mediump in the first place)
20:17glehmann: radeonsi just enabled mediump as fp16 in 25.1
20:17glehmann: alyssa: right, if they use proper GL, that would explain this
20:17alyssa: ah. you may regret that choice
20:18HdkR: So far I've only ever seen regret with fp16, I've never seen success.
20:18alyssa: Yeah..
20:18glehmann: not my choice 🙃
20:18alyssa: part of how we got here is my own personal journey
20:18jannau: firefox seem to use "OpenGL ES 3.2" based on WebGL 1/2 Driver Version in about:support
20:19alyssa: working on dinky mobile parts in 2020 when I started work on apple
20:19alyssa: and now running d3d12 games on a $2000 desktop
20:19alyssa: rather different, professional priorities
20:19alyssa: going all-in on mediump made more sense to my 2020 brain than my tired 2025 one
20:21alyssa: but yeah.. plumbing no_fp16 into radeonsi is probably sane.
20:21glehmann: HdkR: I think we've seen some success with fp16 now that vk/d3d12 have explicit fp16 and not just mediump
20:22alyssa: explicit fp16 is good, mediump is not
20:22HdkR: :D
20:22jenatali: +1
20:22alyssa: this is not a hot take
21:32AndrewR: Lynne, problem is, even ffmpeg 7.1.1 can't decode ffv1 produced by ffv1_vulkan. :( ffmpeg git itself works, but I do not think this is good idea to have shader-based encoder making effectively incompatible streams by default
22:21mattst88: can anyone decipher why https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35077 is failing?
23:20olivial: mattst88: looks like CI is having problems to me. I got the same error on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35154
23:21mattst88: okay, thanks