06:14 fabcal: Karol, do you see a chance to help me at this point in relation to my actual NOUVEAU/Xwayland fault?
08:16 awilcox: [116166.342631] [drm] Initialized nouveau 1.4.0 for 0000:01:00.0 on minor 1
08:16 awilcox: it actually booted-ish!
09:12 karolherbst: fabcal: which one was it?
09:14 fabcal: karolherbst: if you take a look above, there was a conversation between DodoGTA and me in relation to the NOUVEAU crash
09:14 fabcal: Karolherbst: Oct 29 17:33:29 lenovo-p3-debian gnome-shell[5313]: Xwayland: ../nouveau/pushbuf.c:730: nouveau_pushbuf_data: Assertion `kref' failed.
09:15 karolherbst: mhhh
09:15 karolherbst: sooo
09:15 karolherbst: this isn't a crash as you might think it is
09:16 karolherbst: the GPU accesses invalid memory and nouveau destroys the GPU context, and the assert is just a symptom of it
09:17 karolherbst: `fifo: fault 00 [VIRT_READ] at 0000000000561000 engine 40 [gr] client 02 [GPC1/T1_2] reason 02 [PTE] on channel 2 [01ff8f4000 Xwayland[5313]]` is the main thing here
09:17 fabcal: Karolherbst: what am I doing wrong?
09:17 karolherbst: Do you have your Xorg server logs somewhere?
09:18 karolherbst: ehh wait
09:18 karolherbst: that's XWayland
09:19 fabcal: Karolherbst: the crash arises constantly only if I configure my linux-login using Xwayland
09:19 karolherbst: Right.. so XWayland is accelerating 2D through OpenGL and I suspect it simply hits a different path or something
09:20 karolherbst: What GPU is that on?
09:20 fabcal: Karolherbst: double graphic cards
09:20 karolherbst: mhhhhhh
09:20 fabcal: Karolherbst: onboard Intel + nVidia
09:21 karolherbst: are you running it explicitly on the nvidia GPU though?
09:21 karolherbst: because normally gnome shouldn't even use it
09:21 fabcal: Karolherbst: no clue
09:21 karolherbst: I know there are issues when the desktop decides the nouveau GPU to be the main one, but that shouldn't ever happen in the normal case
09:22 karolherbst: might pastebining the output of `glxinfo` once on an X11 and once in a wayland session?
09:23 fabcal: Karolherbst: pls. how do I use correctly "pastebin"?
09:23 karolherbst: I mean, a website to paste the output, so the IRC channel won't be spammed
09:23 fabcal: Karolherbst: I shall try that
09:24 karolherbst: my expectations is, that it could be the intel one on X11 and nouveau on wayland..
09:25 fabcal: Karolherbst: and this could be the reason why Xorg X11 does work perfectly without any crashes?
09:25 karolherbst: yeah
09:25 karolherbst: the nouveau crash should be fixed regardless, but there are other reasons your desktop shouldn't use the nvidia gpu for random things
09:26 karolherbst: mostly power consumption
09:26 karolherbst: and heat
09:26 karolherbst: which also means more silent fans
09:26 fabcal: Karolherbst: "glxinfo" is not there on my linux Debian 12: should I install first "mesa-utils"?
09:26 karolherbst: yeah
09:28 fabcal: glxinfo: nable to open display
09:28 fabcal: Karolherbst: Error: unable to open display
09:28 karolherbst: oh X11?
09:29 fabcal: yes, I am now running "Gnome X11/Xorg",but not Xwayland
09:29 karolherbst: weird...
09:29 karolherbst: that's on a terminal opened through the GUI?
09:30 karolherbst: does `DISPLAY=:0 glxinfo` change anything?
09:30 fabcal: Karolherbst: could it be that Xwayland is not able to handle to different monitors? (multi-monitors)
09:30 karolherbst: ohh display is a different thing here
09:30 fabcal: Karolherbst: I see
09:30 karolherbst: basically means it can't find your X server
09:31 fabcal: `Display=:0 glxinfo` : Error: unable to open display
09:32 phodius[d]: hi, on lastest mesa am getting MESA: error: ZINK: failed to choose pdev
09:32 phodius[d]: libEGL warning: egl: failed to create dri2 screen
09:32 phodius[d]: how can i fix this?
09:34 karolherbst: are vulkan drivers installed?
09:34 karolherbst: fabcal: odd....
09:34 phodius[d]: yeah, it when running zink
09:34 fabcal: Karolherbst: pls. how could I check that?
09:34 karolherbst: fabcal: I didn't mean you
09:35 karolherbst: phodius[d]: so vulkaninfo works perfectly?
09:35 karolherbst: like it gives you a GPU and all that?
09:36 karolherbst: fabcal: mhhhh.. it sounds like something is messed up on your end, but not quite sure what...
09:36 phodius[d]: vulkaninfo works when not using it under zink
09:36 karolherbst: fabcal: so if you open a terminal through the GUI, what's the output of "set | grep DISPLAY"
09:37 karolherbst: phodius[d]: so it's zink failing to load on the compositor side?
09:37 phodius[d]: oh no it works under zink as well just checked there
09:37 karolherbst: okay
09:37 awilcox: okay, so doing a full power off and reboot: my big endian system successfully loads the firmware for the GT 1030, does all the connector stuff properly, and it even turns the backlight on the DVI-connected monitor! however, the drmfb doesn't ever have any text, and when I try to start X it Oopses, so it seems like there's still some more work to go
09:38 fabcal: Karolherbst: set| egrep -i 'DISPLAY' ---> no output at all, nothing
09:38 karolherbst: awilcox: yeah... people don't really care about big endian, because practically speaking GPU support is dead on big endian
09:38 karolherbst: it has no future, and fixing stuff for the one or two remaining users isn't really worth it sadly
09:39 karolherbst: There are many reasons why you can't properly implement GL on big endian systems
09:39 awilcox: I am doing the fixes where possible, and aarch64_be exists and is not going anywhere (the pi 3/4/5 all support it, rockchip boards from pine support it, etc)
09:39 awilcox: full dmesg is at https://foxkit.us/linux/nouveau-dmesg-20241102-0438.txt
09:39 karolherbst: sure, but there are many limitations
09:40 karolherbst: I think display support is a fine goal here
09:40 karolherbst: just anything on top will get super messy
09:40 karolherbst: nvidia GPUs used to have an endian switch
09:40 karolherbst: and that got removed
09:40 awilcox: yeah, this is one of them (Pascal was the last gen with the switch)
09:40 karolherbst: and before it got removed, it was also broken
09:40 karolherbst: yeah, it's broken on pascal :)
09:41 awilcox: ah, in what way?
09:41 karolherbst: you can't implement certain GL features, because the hardware can't abstract it away properly
09:41 karolherbst: might be good enough for GL 2.1 or so
09:41 awilcox: drm fb + GLESv2 for weston/sway would be enough for me
09:41 karolherbst: there are features like mapping GPU memory to userspace, and the persistent mapping stuff
09:42 karolherbst: can't really support it without a lot of pain
09:42 karolherbst: yeah.. might be doable
09:42 phodius[d]: should i downgrade mesa to match my kernel? it appears it just when running compositor, glxgears and vkcube work under zink
09:42 karolherbst: I don't really remember all the details, but it's gonna be a lot of work if you want GL 4.x to run :D
09:42 karolherbst: phodius[d]: nah, that shouldn't matter
09:43 karolherbst: there was a big rework on how zink loads stuff
09:43 karolherbst: or mesa in general
09:43 karolherbst: might be a regression from that
09:43 karolherbst: fabcal: yeah...... I think something is very wrong on your system
09:44 awilcox: GL 4 would be a dream but I'm trying to crawl before I walk before I run before I fly before I go to outer space :P
09:44 karolherbst: fabcal: might want to check the X server logs
09:44 fabcal: Karolherbst: but it was a brand new Debian 12 installation
09:44 karolherbst: yeah, but DISPLAY has to be set
09:45 karolherbst: it's a bit weird that anything starts at all tho...
09:45 karolherbst: maybe it's just something about the terminal emulator you are using?
09:47 fabcal: Karolherbst: set | egrep -i 'DISPLAY' : DISPLAY=:0
09:48 karolherbst: fabcal: what did you change?
09:48 fabcal: Karolherbst: I did restart my Linux Debian 12 :-)
09:48 awilcox: karolherbst: one thing I would like to ask, if you don't mind - do you think it would be better/easier for me to work 'up' to pascal? or is it more 'appealing' to start with pascal? I'm hoping that, if my changes are not invasive, to land them upstream
09:49 fabcal: Karolherbst: name of display: :0
09:49 fabcal: display: :0 screen: 0
09:49 fabcal: direct rendering: Yes
09:49 fabcal: server glx vendor string: SGI
09:49 fabcal: server glx version string: 1.4
09:49 fabcal: server glx extensions:
09:49 fabcal: GLX_ARB_context_flush_control, GLX_ARB_create_context,
09:49 fabcal: GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile,
09:49 fabcal: GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
09:49 fabcal: GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample,
09:49 fabcal: GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile,
09:49 fabcal: GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB,
09:49 fabcal: GLX_EXT_get_drawable_type, GLX_EXT_libglvnd, GLX_EXT_no_config_context,
09:49 fabcal: GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
09:49 fabcal: GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method,
09:49 fabcal: GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
09:49 awilcox: I actually have cards of every generation down to Tesla, but I figured if I put a tesla in and started fixing it, everyone would just say 'see, BE users have 15 years old systems', and this is a Power9 from 2018, so I thought I'd start with the newest possible card that would work (pascal; I have an ampere but yeah, the endian switch is gone, and it.. is very angry)
09:49 fabcal: GLX_SGIX_visual_select_group, GLX_SGI_make_current_read,
09:49 fabcal: GLX_SGI_swap_control
09:49 fabcal: client glx vendor string: Mesa Project and SGI
09:49 karolherbst: awilcox: not sure it really matters
09:49 karolherbst: but maybe
09:51 awilcox: well, I know kepler is not working as well, it had a channel error (dunno much beyond that) - if it's possible that fixing that could also fix basic other things, it might be worth it to start there instead of going all-in on pascal at the beginning
09:51 karolherbst: the problem is, that mesa is pretty broken on big endian to begin with
09:51 awilcox: oh I'm well aware of that and will be working on that after I get the kernel-side working properly.
09:52 karolherbst: the only use case which people care about is, llvmpipe on s390x
09:52 karolherbst: and only to run GUI apps
09:52 karolherbst: but yeah...
09:52 awilcox: well, I don't know if I would quite say that's the only case 'people' care about, but it's what the paid maintainers care about
09:53 karolherbst: I mean, I'd be happy if somebody fixes it all
09:53 karolherbst: but I've spent some time on it myself
09:53 karolherbst: nah, it's really the only thing people care about
09:53 karolherbst: you get 0 vendor support, and users except a few exceptions don't care about BE either
09:53 karolherbst: it's a dead architecture
09:54 awilcox: the dozens of bugs filed against mesa by various people trying to run power macs, sparcs, and aarch64_be's seems to show the opposite. though I will admit, most of those users are amdgpu/radeon, not nouveau
09:54 awilcox: amdgpu's code is frankly terrifying, which is why I thought I'd work on nouveau first
09:54 karolherbst: I mean... people like BE for reasons, it's just a very small niche
09:54 awilcox: plus it seemed to have a nicer community
09:55 HdkR: Jenga niche. Stack the arm64_be on nouveu on top of x86 emulation
09:55 HdkR: nouveau*
09:55 karolherbst: yeah probably, I just now that the time spent on BE support in mesa was frustrating
09:55 karolherbst: it's all duct tape
09:56 awilcox: if it wasn't obvious, I am 1. one of those people, 2. going through fixing everything for everyone else - I already fixed rust, openjdk, gstreamer's orc, llvm mcjit, ocaml, firefox/spidermonkey.. the last bits are drm/gfx
09:56 karolherbst: yeah, and fixing GPU support is gonna be hell, I don't want to sugar coat it
09:56 karolherbst: be prepared for a lot of frustration and a lot of work
09:57 awilcox: and yes mesa is probably going to be a multi-month or longer project, but first I need to get the kernel side working, so that mesa can be fixed properly instead of all the duct tape
09:57 karolherbst: *multi-year
09:57 karolherbst: Ive worked on it long enough to know
09:57 awilcox: firefox has been six years, so yeah
09:57 awilcox: that wouldn't surprise me nor does it intimidate me
09:58 karolherbst: if you are aware and willing to do it, perfect :)
09:58 phodius[d]: how do i add zink to 24.09 mesa when compiling what the parameter? thanks
09:59 karolherbst: I don't want to say don't do it, just to be aware of the circumstances and the work it means, but if you are well aware, then yeah, go ahead and try to fix it. I think people would appreciate to replace the duct-tape by proper support anyway
09:59 karolherbst: phodius[d]: through gallium-drivers
10:00 awilcox: yeah that makes total sense to me.
10:00 karolherbst: awilcox: but yeah.. I think the first step might be to make mesa/gl support opt-in on big endian, so it only runs on GPUs were it's more or less verified to work
10:00 karolherbst: and so that users can reliably get a desktop running
10:00 karolherbst: llvmpipe _should_ work as a proper fallback, and that's within the upstream supported domain anyway
10:01 karolherbst: and then work out which GPUs work perfectly, what GL features to disable, etc...
10:01 awilcox: that's probably what I'll do when I get to the point where I can even do mesa
10:01 awilcox: I have a pile, literally, of gpus here, and none of them actually manage to get a framebuffer running at all
10:01 karolherbst: fabcal: ehh,.,. `glxinfo | grep -i device` should be more helpful here
10:02 awilcox: it's a lot worse than you probably realise :) it didn't used to be this bad, either
10:02 awilcox: even the 'reliable' radeon r600 doesn't work any more, it's just rainbow dust pattern on all outputs
10:02 karolherbst: awilcox: I mean.. that's what I'd expect how broken it is
10:02 karolherbst: there is 0 testing
10:02 karolherbst: which means everything is broken by default
10:03 karolherbst: I don't think any vendor supports GPU support on big-endian these days at all
10:03 awilcox: I suppose that makes sense yeah. but idk, normally the tty stuff doesn't get broken so badly.
10:03 awilcox: especially on old cards that don't get any updates anyway
10:03 karolherbst: right.. but code changes and breaks
10:04 karolherbst: I think to ensure ti doesn't one would need to do some kernel CI testing with GPUs
10:04 awilcox: well perhaps I should start with tesla, that was around when BE desktops still existed so it may have the best chance of not having churned around
10:04 karolherbst: and if nobody reports bugs, or no developer fixes those, things stay broken
10:04 fabcal: Karolherbst: while working on "Gnome Xorg/X11" (so not Xwayland): glxinfo | egrep -i 'device' ----> Device: NV167 (0x1ff0)
10:05 karolherbst: awilcox: yeah, sounds reasonable
10:05 awilcox: were there ever curie pcie cards? I don't have one, but I might be able to find a cheap one if it exists..
10:05 karolherbst: I don't think tesla supports those problematic GL features either... not sure
10:05 karolherbst: though it can map GPU emmory...
10:31 karolherbst: fabcal: mhh, yeah so that shouldn't happen at all
10:31 karolherbst: I think you are hitting this GPU selection bug
10:31 karolherbst: though mhhh...
10:32 fabcal: KarolHerbst: I did create the first "pastebin": could U see that at all?
10:32 karolherbst: mind uploading the entire output of `journalctl --dmesg --no-hostname` to pastebin or so?
10:32 karolherbst: fabcal: did you share the link?
10:33 fabcal: https://pastebin.com/XKnSWAt0
10:34 karolherbst[d]: there should be more output, but I'm only interested in the glxinfo | egrep -i 'device' part anyway
10:34 karolherbst[d]: from glxinfo that is
10:34 karolherbst[d]: I'm curious what the kernel logs are saying...
10:34 fabcal: Karolherbst: while working on "Gnome Xorg/X11" (so not Xwayland): glxinfo | egrep -i 'device' ----> Device: NV167 (0x1ff0)
10:34 karolherbst: yeah, I've seen that
10:34 karolherbst: that's why I asked for the journalctl one
10:35 karolherbst: but there is a lot of output and I'd need it all
10:35 fabcal: Karolherbst: working on journactl --dmesg
10:38 fabcal: karolherbst: https://pastebin.com/w5GY4eNH
10:38 karolherbst: that's not the entire output. You probably want to write it to a file and upload that one
10:39 awilcox: what distro? debian?
10:40 karolherbst: could be some fixes not backported...
10:40 karolherbst: I know we had some GPU selection bugs which were caused by the kernel
10:41 awilcox: you can install 'pastebinit' package on debian, and then run
10:41 awilcox: journalctl --dmesg --no-hostname | pastebinit
10:41 awilcox: and it will send the whole content to paste.debian.net
10:43 fabcal: awilcox: thank you very much indeed
10:43 awilcox: happy to help :)
10:43 fabcal: karolherbst: https://paste.debian.net/hidden/c7f49559/
10:44 fabcal: awilcox: much appreciated :-)
10:44 karolherbst: thanks
10:45 fabcal: karolherbst: thank you very much indeed; vielen herzlichen Dank
10:45 karolherbst: yeah... sooo "Nov 02 08:32:28 kernel: fbcon: nouveaudrmfb (fb0) is primary device" that's wrong :D
10:47 karolherbst: fabcal: you might want to check with fedora or some other distro using new kernel versions to see if you see the same issue there. Fedora 41 is just out and they use 6.10 I think
10:47 karolherbst: just to check if the bug is fixed there
10:47 karolherbst: otherwise it's a kernel bug to be figured out
10:47 karolherbst: but yeah...
10:47 karolherbst: the kernel selects the wrong primary GPU which should be your intel one
10:47 karolherbst: and that causes all other sorts of issues not really supported
10:47 fabcal: karolherbst: I am confused: because I am now working under Xorg/X11 and my VirtualBox does NOT crash at all
10:48 karolherbst: yeah, it's just an issue on wayland
10:48 karolherbst: but the problem is, that your nvidia GPU is always turned on
10:48 karolherbst: which... is terrible for battery lifetime on a laptop
10:48 karolherbst: don't get me wrong, that bug should be fixed, but you shouldn't run into this bug in the first place
10:48 fabcal: karolherbst: just using a Lenovo ThinkStation P3
10:49 karolherbst: ohh, it's a desktop?
10:49 fabcal: yes it is indeed
10:49 karolherbst: ahh mhhh
10:49 karolherbst: I guess in this case it makes sense 🙃
10:49 karolherbst: you might be able to flip the main GPU in the firmware maybe? as a temporary workaround
10:50 fabcal: karolherbst: if I knew how to do that, I owuld do it
10:51 karolherbst: yeah.. sadly it depends on the firmware and it's always different 🙃
10:51 karolherbst: but there should be some options about GPU support
10:51 karolherbst: there is often an option to e.g. disable the iGPU even
10:52 fabcal: karolherbst: so U R telling me to look into my UEFI-boot, aren' t U?
10:53 karolherbst: yeah, there might be an option to help you here.. maybe
10:53 karolherbst: I'll see if I can trigger the bug, but that's gonna wait until next week or so
10:54 fabcal: karolherbst: but generally speaking, if Xwayland is supposed to be the future, and X11 the past, why does XWayland don't "match" with fbcon?
10:57 karolherbst: it does, it's just not very well supported nor tested
10:57 karolherbst: it seems you have the same configuration on both X11 and XWayland
10:57 karolherbst: just running into a bug you only see with XWayland
10:57 fabcal: karolherbst: I see: this is called in German language: Versuchskaninchen :-)
10:58 karolherbst: more or less. I mean, I'm aware of the bug happening on laptops, and there the best approach is to make the intel one the main GPU anyway
10:58 karolherbst: you are probably the first hitting it on a desktop
10:58 fabcal: guinea pig
10:59 karolherbst: multi GPU is kinda a weird configuration causing all sorts of random issues
10:59 fabcal: karolherbst: I got you
11:00 fabcal: karolherbst: do U still need a Journalctl dmesg running under Ywayland?
11:00 fabcal: I ment XWayland
11:00 karolherbst: nope
11:01 fabcal: karolherbst: thank you very much indeed for all your support: very much appreciated
11:04 karolherbst: np
14:48 tiredchiku[d]: gonna be selling my funny hacked up rebar-on-turing laptop .-.
14:49 tiredchiku[d]: as much as I love it, it is getting older and less valuable and I'm interested in replacing it with something I actually will use, since it's just been the local dust gatherer for the last few months
14:50 karolherbst[d]: or... you keep it because you want to run CI stuff on it and then never do it anyway
15:16 dwlsalmeida[d]: avhe[d]: hey btw, trying your tracer here, it does log some things, but nothing on NVDEC :/
15:16 dwlsalmeida[d]: any tips?
15:17 dwlsalmeida[d]: `#define SHOULD_LOG_NVDEC 1` btw
15:19 dwlsalmeida[d]: using `nvidia-gpu-open` on arch btw, should I switch to `nvidia`?
15:19 avhe[d]: i use `nvidia` on arch for this, but i would expect the gpu-open version to work
15:20 marysaka[d]: Does your thing dump on kickoff?
15:20 avhe[d]: did you set the gpfifo define to the correct revision for your card?
15:21 avhe[d]: marysaka[d]: it injects a fake mmio map and intercept writes to GPPut
15:21 avhe[d]: same as envyhooks iirc
15:21 marysaka[d]: avhe[d]: hmm I think the way that is mapped is different with Volta+
15:22 marysaka[d]: I had to handle it differently to support lower gen if that's truly the issue :aki_thonk:
15:22 avhe[d]: i build and tested the repo successfully on my rtx3050 yesterday, so it should work
15:22 dwlsalmeida[d]: There's only `Volta` or `Kepler`
15:23 dwlsalmeida[d]: except, I am on turing
15:23 dwlsalmeida[d]: (RTX2060)
15:23 avhe[d]: then set it to volta (it really means volta+)
15:23 dwlsalmeida[d]: yeah, I already had Volta
15:23 dwlsalmeida[d]: lets try substituting `nvidia-open` with `nvidia`
15:24 avhe[d]: otherwise, send me whatever output you get and i'll take a look
15:26 avhe[d]: a possible reason i could see is that your kernel module was outdated with respect to the headers the preload stub was built with
15:27 avhe[d]: i updated my vm yesterday to test the stub, so the latest blob driver should work
15:31 dwlsalmeida[d]: yeah I assume arch has the latest already
15:31 dwlsalmeida[d]: trying to debug here
15:37 dwlsalmeida[d]: [h264 @ 0x632d9cb1ca80] Reinit context to 176x144, pix_fmt: yuv420p
15:37 dwlsalmeida[d]: Selecting decoder 'h264' because of requested hwaccel method cuda
15:37 dwlsalmeida[d]: ^ is this the right one?
15:37 dwlsalmeida[d]: I hate it when ffmpeg cant decode something so it just pipes the data through its software decoders silently
15:42 avhe[d]: dwlsalmeida[d]: yep should be
15:43 dwlsalmeida[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1302297161228353616/ffmpeg.log?ex=67279a3e&is=672648be&hm=b4053cdb630f6521bcf547aad46aa0c941896e533edf5c5f92c31725d5e0ad2c&
15:44 dwlsalmeida[d]: I enabled all the #defines, getting this ^
15:46 dwlsalmeida[d]: only thing remotely applicable would be this
15:46 dwlsalmeida[d]: ````
15:46 dwlsalmeida[d]: 1 Ioctl on 41 (/dev/nvidiactl): req 0xc030462b (type 70 'F', dir 3, nr 0x2b, size 0x30)
15:46 dwlsalmeida[d]: 0 Alloc: class 0xc4b0 (NVC4B0_VIDEO_DECODER), root 0xc1d00038, parent 0x80000012, handle 0x80000030, flags 0, alloc params: (nil), size 0
15:48 avhe[d]: ahh i see
15:48 avhe[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1302298374803820606/image.png?ex=67279b60&is=672649e0&hm=f8892ac8de3af4eff8cbeab4698b236135448c8ccb9d32f8b923619afa44c550&
15:48 avhe[d]: add TURING_CHANNEL_GPFIFO_A here
15:49 avhe[d]: i only ever tested this on maxwell and ampere so i never hit that issue
15:49 avhe[d]: probably all gpfifo classes should be added there
15:50 dwlsalmeida[d]: ok, this works now! 🙂
15:50 avhe[d]: 👍
16:11 asdqueerfromeu[d]: dwlsalmeida[d]: Is the next step decoding a single frame from a 144p YouTube video? 🚀
17:51 dwlsalmeida[d]: anyone has any guesses on what this does?
17:51 dwlsalmeida[d]: NvU32 luma_top_offset; // offset of luma top field in units of 256
17:51 dwlsalmeida[d]: NvU32 luma_bot_offset; // offset of luma bottom field in units of 256
17:51 dwlsalmeida[d]: NvU32 luma_frame_offset; // offset of luma frame in units of 256
17:51 dwlsalmeida[d]: NvU32 chroma_top_offset; // offset of chroma top field in units of 256
17:51 dwlsalmeida[d]: NvU32 chroma_bot_offset; // offset of chroma bottom field in units of 256
17:51 dwlsalmeida[d]: NvU32 chroma_frame_offset; // offset of chroma frame in units of 256
17:52 dwlsalmeida[d]: asdqueerfromeu[d]: I am working on progressively more complex streams, trying to at least decode one single frame right and take it from there
17:53 dwlsalmeida[d]: DPB is obviously screwed here, because anything with multiple frames just hangs
17:59 tiredchiku[d]: karolherbst[d]: nah
17:59 tiredchiku[d]: have my mini server machine for that
18:00 tiredchiku[d]: tho, no nv gpu there
18:02 tiredchiku[d]: also I'd rather have the hardware be used by someone who needs it instead of hoarding it
18:08 avhe[d]: dwlsalmeida[d]: it's for top/bottom interlaced fields
18:09 avhe[d]: if you leave them to 0, the fields will get interleaved
18:10 avhe[d]: dwlsalmeida[d]: dpb management is a bit tricky on h264, you need to make sure decoded frames remain fixed in the array for their entire lifetime
18:11 dwlsalmeida[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1302334180318904400/log_blob.txt?ex=6727bcb8&is=67266b38&hm=05780a8de0d482c9aa6a9b429215af28d81296bdc8fe3d8169cf056b412d19c1&
18:11 dwlsalmeida[d]: I am not even considering DPB anything for now
18:11 dwlsalmeida[d]: I just want to get one frame for the next video I am trying to decode right
18:11 dwlsalmeida[d]: this is the data I dumped using your tool btw,
18:11 dwlsalmeida[d]: I appended it with printf to actually dump the struct fields instead of just the hex
18:12 dwlsalmeida[d]: it seems to have values for luma_bot_offset and chroma_bot_offset
18:12 avhe[d]: ah, you wrote a deserializer? that's cool, i spent way too much time looking at hexdump because i was too lazy to do it
18:12 dwlsalmeida[d]: you can just ask AI to do it for you lol
18:13 dwlsalmeida[d]: "hey look at the struct definition, please write a gazillion printf calls to dump this"
18:13 avhe[d]: yeah i guess
18:14 avhe[d]: anyway the setup has field_pic_flag set to 0 so the field offsets should have no effect
18:14 dwlsalmeida[d]: they do
18:14 dwlsalmeida[d]: I've changed them ever so slightly and compared the results at every point
18:15 dwlsalmeida[d]: it does change the chroma plane somewhat
18:15 avhe[d]: huh strange
18:15 dwlsalmeida[d]: also I have no idea why the driver has 60 and 36 there
18:57 clangcat[d]: dwlsalmeida[d]: You don't even need "AI" really can always uses something like clangs dump struct tho anything works.
18:59 dwlsalmeida[d]: I was actually unaware that this existed
19:00 dwlsalmeida[d]: I've also been unable to find a way to build a debug version of the tracer using xmake
19:01 dwlsalmeida[d]: which I am trying to do because it segfaults if we use gstraemer
19:55 avhe[d]: you need to run `xmake config -m debug`, then rebuild with `xmake`
19:56 avhe[d]: output will be in build/linux/x86_64/debug/
21:54 dwlsalmeida[d]: gfxstrand[d]: hey I discovered something
21:55 gfxstrand[d]: Oh?
21:55 dwlsalmeida[d]: you said
21:55 dwlsalmeida[d]: that we should pass 1 << dst_img->planes[0].nil.levels[0].tiling.y_log2 as the GOB height to the GPU
21:56 dwlsalmeida[d]: I've been noticing that the chroma plane is broken for the two other videos I've been working on today
21:56 dwlsalmeida[d]: I noticed that `1 << dst_img->planes[0].nil.levels[0].tiling.y_log2 ` is 5 for plane[0]
21:56 dwlsalmeida[d]: but 4 for plane[1]
21:57 dwlsalmeida[d]: if we use plane[1] y_log2 value, we actually unbreak the chroma plane
21:57 dwlsalmeida[d]: but we then break the luma plane
22:01 dwlsalmeida[d]: We can only set one value, i.e.:
22:01 dwlsalmeida[d]: ````
22:01 dwlsalmeida[d]: NvU32 gob_height : 3 ; // Set GOB height, 0: GOB_2, 1: GOB_4, 2: GOB_8, 3: GOB_16, 4: GOB_32 (NVDEC3 onwards)
22:01 dwlsalmeida[d]: ````
22:01 dwlsalmeida[d]: So I wonder if there is a way to compensate somehow