00:38 soreau: with latest mesa 114a4754 and mpv -vo=dmabuf-wayland on radeonsi RX580, the output shows the video but has a strong red tint. weston and wlroots show the same result
03:39 kurufu: Is there any better documentation on syncfile/syncobj interactions than https://dri.freedesktop.org/docs/drm/gpu/drm-mm.html#drm-sync-objects, this ever so brief doc suggests syncfiles are immutable and after import the syncobj shouldnt be able to signal them. But clients like mutter seem to depend on this behavior actually working?
07:40 airlied: kurufu: on the cpu side I think, fences can still get signalled by the hw
09:42 aleydojush: What would be useful is extended option rom of PCI-e on it's fpga fabric, I am pretty good in verilog and the FW is available (i add the entropy decoder into pcie switch fabric or more like 8b10b encoder fabric), we do not have to decode to the devices memory that way, fabric would do that, so flashrom should be suffiecient at this, and it would happen in lateboot when embedded controllers
09:42 aleydojush: have been brought up, and backup rom is laptop model specific though, but i have not looked at yosys for years, worst case we would need to use vendors netlist configuration tools to do that. It would load the fpga netlists, just yosys and compressed netlists for luts would be lot better to do this, but that could be something for the future. However hats off from computer engineers and sw
09:42 aleydojush: engineers as there is totally enough available to do it, in other words, i ain't gonna use DMA to decode and encode the things.
09:44 aleydojush: The real compressed netlists, regardless of the resources on that specific fabric, would anyways fit encoder decoder b8b10 or more band enabled encodings, plus anything that you would desire to be added like crypto validators etc.
09:48 aleydojush: what brings to the final question, i have one old HP laptop that has AGP port and r300 next to intels single core cpu, i am unsure as to how b8b10 if it was enabled on agp, and what would be the fabric to target there, perhaps someone would know better if such systems integrate fpga somewhere on it's switches.
09:59 aleydojush: drivers on intel are very good at the moment of not corrupting anything on very recent kernels , AMD ones are good too, so the mission is nearly acomplished as the code needed to be added is very short under any real programming criterias.
10:02 linkmauve: soreau, does amdgpu support modifiers on this device? IIRC it was the main blocker for proper dmabuf stuff.
10:03 linkmauve: Also make sure to use a recent mpv, stuff has been fixed.
10:07 memleak: hello. i was wondering, is there a way to adjust HDMI overscan like you can in windows with the AMD driver, in linux with the open source drivers?
10:08 memleak: i can fix it by using radeon.audio=0 but then i don't have hdmi audio.
10:09 memleak: oh holy crap, alyssa is in here?? the panfrost dev?
10:09 linkmauve: memleak, asahi and honeykrisp now. :)
10:11 memleak: ah alright
10:11 memleak: well still, she's a legend
10:12 memleak: the maynard james keenan of x.org development xD
11:01 aleydojush: https://www.amazon.com/StarTech-com-Express-Adapter-Card-PCI1PEX1/dp/B0037ECAM2?th=1 some weird products are available, anyways case closed as i do not think agp has programmable b8b10 fabrics on the chipset, caliban could be used too, but it's so complex, nothing about pci-to-pci bridge parts microcontroller isas are known to me, they are expedly very rarely having isa decoders on asics,
11:01 aleydojush: it's all fixed over pci commands.
11:02 aleydojush: that particular card is way too expensive.
12:08 zamundaaa[m]: memleak: yes, there's the underscan drm properties for that
12:11 memleak: zamundaaa[m], are these kernel params?
12:12 zamundaaa[m]: No
12:12 zamundaaa[m]: Whatever drm master you're using can set the drm properties
12:13 zamundaaa[m]: In KDE Plasma it's exposed in system settings, not sure about other desktops / compositors
12:13 memleak: ah ok
12:13 memleak: yeah lxqt and xfce doesn't have anything like that
12:13 memleak: no way to do it on command line with xrandr or something?
12:43 soreau: linkmauve: thanks, it's a card without modifier support indeed. with updated mpv, I get errors/warnings when playing but dmabuf-wayland works without the red tint
12:55 llyyr: soreau: what warnings? it might be inserting a cpu filter to convert pixfmt which kinda makes dmabuf-wayland not worth it
12:57 soreau: llyyr: [ffmpeg] AVHWFramesContext: Failed to write image to surface 0x1a: 22 (invalid VAImageFormat). [autoconvert] Converting vaapi[nv12] -> vaapi[bgr0]
12:58 soreau: when seeking there are more messages too, ending with 'Video: no video' but it still plays
12:59 llyyr: soreau: it's this https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32605#note_2717466
13:00 llyyr: well probably depends on what you tried to open with it, but that's one current issue that I know of
13:03 llyyr: you can force mpv to do the conversion with --vf=format=nv12 to get rid of the errors, if it's a format that can't be decoded with vaapi
13:03 soreau: llyyr: mediainfo for it https://pastebin.com/raw/SQJvyRz7
13:05 llyyr: yep seems like yuv420p, that won't work with mpv --no-config --vo=dmabuf-wayland, but will work if you add hwdec=vaapi.
13:05 llyyr: mesa va frontend claims to support uploading yuv420p directly, but it fails when applications actually try to do it
13:13 soreau: llyyr: well it's already using vaapi AFAICT ('Using hardware decoding (vaapi).' without extra options), so -hwdec=vaapi doesn't change anything
13:14 llyyr: you probably have it in your config? it should use vaapi by default
13:14 llyyr: shouldn't*
13:14 soreau: yes you're right, it's there in config
13:15 llyyr: the problem with that is, now it won't work for any formats that can't be decoded with vaapi. breaks on all images or vp8 or av1 (for older cards)
13:15 soreau: gpu-context=wayland and hwdec=vaapi
15:05 zamundaaa[m]: memleak: I think you can do it witth xrandr, but I don't know how
15:05 zamundaaa[m]: I haven't used Xorg in a long time
15:52 KungFuJesus: ok, finally bisecting my big endian issue today. I think I'll start with launching X with a nouveau that works and use the meson 'devenv' option to bisect the version glx breaks for me
16:26 memleak: KungFuJesus, wishing you the best!
16:30 glehmann: do we want (('fadd', a, a), ('fmul', a, 2.0)) in main nir_opt_algebraic? For amd, it's going to be better because it allows omod and otherwise fma if it's only used by fadd. I guess other hardware might have separate mul and add units where it's not as clear. Also I guess technically mul uses more power than add
16:31 glehmann: also I guess the constant isn't free on all ISAs
16:40 glehmann: but we should probably choose either a+a or a*2.0 for nir because I found some shaders that have both
16:57 KungFuJesus: it seems to have something to do with how swrast won't build without llvm enabled anymore. The result is a missing swrast dri module. I can start with modesetting and it loads nouveau properly but glx then fails to work
16:58 KungFuJesus: the only reason I was building without llvm to begin with is somebody in 2019 removed that use flag with a profile level keyword
16:59 KungFuJesus: in gentoo's portage, that is
17:01 KungFuJesus: when building and installing mesa 24.1.7, I get a kms_swrast dri module and a nouveau module. GLX seems to properly leverage nouveau with full hardware acceleration (with the ocassional render glitch with some X acceleration backed things that are probably longstanding endianness bugs)
17:02 memleak: if all you're doing is git bisecting for nouveau you can just disable swrast
17:02 KungFuJesus: right, that's what I had to do in order to build
17:03 memleak: ah ok
17:03 KungFuJesus: curiously, every 24.2 release after 0 won't even let me start x
17:03 memleak: i thought swrast was replaced anyway with llvmpipe/softpipe
17:03 memleak: they still have that classic driver in there?
17:04 KungFuJesus: that would make perfect sense for why it would require llvm but it doesn't make any sense why this would mess with nouveau
17:04 KungFuJesus: I don't even begin to understand the render pipeline for DRI, though
17:05 memleak: so you're using a big-endian cpu with nvidia?
17:05 KungFuJesus: my best theory right now is something hard switched over to LLVM and the TGSI or whatever IR to nouveau layers are gone?
17:05 KungFuJesus: yeah
17:05 memleak: which one, jc
17:06 KungFuJesus: ppc64
17:06 memleak: oh ok!
17:07 KungFuJesus: the annoying bit about trying to bisect this is that whatever the issue is it happens when DRI initializes, so I have to move DRI modules into my root and restart X
17:10 KungFuJesus: hmm, and now that I've built with llvm it appears to be trying to use zink with glxinfo?
17:12 KungFuJesus: something was deprecated somewhere I think, I just don't know what. I know my configuration uses the /dev/fb interface and I use the openfirmware framebuffer device. Was there something changed there?
17:33 KungFuJesus: hmmm, seems to be ok with latest from git when built with llvm. Maybe it really is just building without llvm is now impossible for nouveau
17:38 memleak: you can't build amdgpu without llvm either
17:39 memleak: you learn something new everyday!
18:01 KungFuJesus: hmm, think I'm off base there, the 9999 ebuild won't startx with llvm force enabled, either
18:10 KungFuJesus: hmm, wonder if it's this...https://gitlab.freedesktop.org/mesa/mesa/-/commit/6f6072448de54d37fe04661b623e9bc03ed0f55a
18:11 KungFuJesus: creating the screen is what fails for me
19:06 DemiMarie: Can non-LINEAR buffers be shared between GPUs from the same vendor?
19:15 zamundaaa[m]: Demi: sometimes
19:15 zamundaaa[m]: depends on the GPUs
19:18 DemiMarie: zamundaaa: Will it work for two identical GPUs?
19:18 DemiMarie: Also, if the modifiers match, will it work? Or are modifiers missing critical information, such as alignment requirements?
19:19 zamundaaa[m]: Alignment is missing from modifiers, drivers ensure that it somehow works out
19:19 zamundaaa[m]: With two of the same dGPU generation (at least on AMD) it should usually work
19:20 zamundaaa[m]: iGPU + dGPU same generation might be a bit more restrictive, specifically about alignment
19:24 KungFuJesus: what is libdril? It seems like when that came to be may have been the start of this issue
19:26 DemiMarie: zamundaaa: That's unfortunate. Can all GPUs on x86 handle linear buffers that are 256-byte-aligned and have ARGB or XRGB format?
19:27 zamundaaa[m]: I have no idea
19:28 zamundaaa[m]: Drivers reject importing buffers where it doesn't work out though. Or at least should
19:42 DemiMarie: zamundaaa: can I reliably count on them to do that, even in the face of malicious input? That’s my situation.
19:42 DemiMarie: If not, I have to fall back to a copy and accept the performance penalty that results.
19:44 DemiMarie: Is there a way to test how drivers handle this situation? Could I allocate dmabufs with various sizes, try to import them, write to then, and check that any data that should not been changed in fact has not been changed?
19:49 zamundaaa[m]: Right now, I would say no
19:49 zamundaaa[m]: For example https://gitlab.freedesktop.org/mesa/mesa/-/issues/9344 happened before
19:51 DemiMarie: zamundaaa: and is still open, yikes.
19:55 DemiMarie: Extra copy it is.
19:55 DemiMarie: marmarek: do you agree with that assessment?
19:57 DemiMarie: zamundaaa: Thanks for informing me of the bad news.