00:07uis: Any news about register alloc?
01:28airlied: skeggsb: why doesn't nouveau_ttm_tt_populate call ttm_populate_and_map_pages
01:30skeggsb: airlied: i'm not sure, there's no specific reason i can think of... bitrot?
01:31skeggsb: yeah, i can't see a good reason
01:32airlied: skeggsb: I'll send a patch
01:32airlied: I might even test it :-P
01:55airlied: skeggsb: https://paste.centos.org/view/f0710382
01:55airlied: that is without my patch
01:55airlied: drm-next on a rhel 8.2 (8.3) userspace
01:56airlied: skeggsb: the oops is at the end :-P
01:56airlied: or rather the WARN
01:57skeggsb: odd, is it a regression?
01:58skeggsb: i have a tu102 plugged in as the main board in my test system most of the time, and it's fine
01:59airlied: skeggsb: I haven't seen it under the RHEL kernel
01:59airlied: I haven't tested anything else on it up until now
01:59airlied: let me reboot into rhel again to confirm
02:02skeggsb: dmesg of nouveau.debug=debug might be interesting too, stuff did change in that area, but it shouldn't have caused this. probably good to confirm it's still loading all the right bits
02:02airlied: skeggsb: the rhel8.3 drm backport kernel seems fine
02:05airlied: skeggsb: I assume your machine isn't in runtime pm mode
02:08airlied: skeggsb: here's a debug one https://paste.centos.org/view/95a9b7d7
02:10skeggsb: no, but that should make literally zero difference for what changed
02:10airlied: oh maybe it's the pci bug that kherbst tracked down
02:11skeggsb: didn't that get reverted though? or hasn't made it to -next yet?
02:11airlied: skeggsb: it's in -rc7, but next is on -rc6
02:11airlied: but seems like it's that alright
02:11skeggsb: it's loading the correct firmwares still
02:11skeggsb: so, fingers crossed it's that :P
02:40airlied: skeggsb: okay patch boots at least, sent to dri-devel + you
02:41skeggsb: it was the pci regression then?
02:42airlied: skeggsb: yes
02:42skeggsb: you could probably just "return ttm_pop...()" there, but not terribly important, it's got my R-b if you want to pull it in, or i can take it and send
02:44airlied: just stick it in your tree, no hurry on it really
03:21airlied: skeggsb: not sure if it's a problem or not, but nouveau doesn't call set_placement_caching on vram->ram moves like amdgpu/radeon do
03:23airlied: sent a mail
03:25airlied: sent v2 of the other one with return cleaned up as well
06:50AndrewR: imirkin, pmoreau : so compiling git at nv50: Ask NIR to lower hadd operations in nv50_compute_support branch gives me my vdpau output colors back .. Obviously, there is no OpenCL support :} Probably for this branch I simply can disable vdpau state tracker, and just install over existing libs ...
10:03karolherbst: AndrewR: right... nir with nv50 is a bit.. broken :p Would be nice if somebody would be willing to fix the more obvious stuff or at least port over to what we do with nvc0 now
10:51pmoreau: AndrewR: Is that patch the first one which breaks the output in vdpau for you?
10:56pmoreau: The issue is most likely in https://gitlab.freedesktop.org/pmoreau/mesa/-/commit/e3ba1f604afb8e6955c4f3935289b2bb2285584d, https://gitlab.freedesktop.org/pmoreau/mesa/-/commit/6126e37055144a615a7a72b72a9e84a51c0dab73, or https://gitlab.freedesktop.org/pmoreau/mesa/-/commit/0e5a70896c9c93b7c7df9813b7f0190ab026767b.
10:57karolherbst: pmoreau: btw, you might want to rebase your nv50 stuff on master and clean up the nir_option mess :/ I sadlt didn't get to it yet
10:57karolherbst: it's much easier now to handle it anyway, check skeggsb patch for nvc0
10:58karolherbst: or rather https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp#L3215 and what's below
11:06pmoreau: I rebased that branch on master like yesterday, but yes I wanted to change the nir_option stuff.
11:09karolherbst: :) cool
11:09karolherbst: we might need to add the shader type as well and do a bit more dispatch though
11:09karolherbst: but that's more for the future
11:11pmoreau: Going to change the nir_option now, and split “WIP nv50 Enabling OpenCL support” into several commits.
11:12karolherbst: cool :)
11:12karolherbst: yeah.. maybe we should focus more on getting your bits upstreamed as well :)
11:13karolherbst: pmoreau: I was also talking with imirkin yesterday and it seemed like we could support GLES3.1 compute (but probably never expose 3.1 though)
11:13pmoreau: I saw that quickly
11:13karolherbst: but.. that might be a path forward for getting the GL bits tested at least
11:13karolherbst: and might be easier than dealing with compute
11:14karolherbst: we probably want to verify our ssbo/image handling is correct before we dig into how to write that up with spirv/nir
11:15pmoreau: The SPIR-V bits, like !5038 and !2078, would definitely be nice to get in. I don’t mind if the Tesla bits take longer.
11:15karolherbst: at least I left some comments ont !5038 :p
11:16pmoreau: I saw them, thank you for that! :-)
11:16pmoreau: And hopefully curro will also be taking a look at it.
11:16pmoreau: Once !5038 is in, !2078 should be fairly easy to add afterwards.
11:17pmoreau: So maybe only half a year. :-D
12:42pmoreau: I updated my nv50_compute_support branch with the new nir_option setup.
12:43pmoreau: AndrewR: I also split the big “WIP nv50 Enabling OpenCL support” commit into more atomic commits, which should hopefully help pinpoint which one is responsible for making vdpau fail. If you have the opportunity to bisect that branch, that would be great!
12:46karolherbst: pmoreau: but do we really want to use compute for vdpau in nv50?
12:46karolherbst: we disabled it for nvc0 afaik as well
12:47pmoreau: No idea
12:47pmoreau: I didn’t know we were using compute for vdpau. I was assuming I had broken some common code in one of my patches.
12:48karolherbst: pmoreau: nope.. somebody enabled compute for vdpau at some point
12:48karolherbst: and I think imirkin disabled it at some point
12:48karolherbst: or so
12:48karolherbst: I might be wrong though
12:53karolherbst: pmoreau: https://gitlab.freedesktop.org/mesa/mesa/-/commit/958390a9bf8904522a50f8e9c26c50c96179c183
13:00tarzeau: having a GeForce GTX 1050 with ubuntu 18.04 and nouveau drivers i keep getting these in syslog: disp: 0x000061ec: INIT_GENERIC_CONDITON: unknown 0x07 AND disp: outp 02:0006:0f82: training failed
13:01tarzeau: should i be worried? what is their meaning?
13:03karolherbst: the first one can be ignored as long as nothing bad happens, the second one is a bit more worrying
13:03tarzeau: i'm aware of inp/outp i did vga register programming on dos (20+ years ago)
13:04karolherbst: but your kernel is also old (and not a stable one as I guess it's 5.3)
13:04tarzeau: 4.15 kernel (18.04)
13:04karolherbst: even worse...
13:04tarzeau: but the next thing i'd try is hew with 5.4 (like ubuntu 20.04)
13:04karolherbst: yeah. 5.4 is the latest LTS branch
13:04karolherbst: and probably contains most fixes
13:04karolherbst: if not, 5.7 or 5.8 might be worth a shot
13:05tarzeau: i've got like 200 hosts, of which 50+ are nvidia hardware, and with 18.04 i had so many nouveau problems (it's linux desktops), that i switched them all to nvidia upstream cuda/drivers
13:05karolherbst: I guess most are pascal?
13:05karolherbst: pascal won't be fun with non LTS kernels as I don't think ubuntu backports all the fixes
13:05karolherbst: much better to rely on upstream LTS branches
13:05tarzeau: all run the 450 latest driver, and people need cuda and libcudnn (with pytorch and/or tensorflow 1.x/2.x)
13:06karolherbst: oh well, then you need the nvidia driver anyway
13:06tarzeau: yep, except some where the newest drivers don't support the latest drivers anymore (that's stuff that runs with 340/390 binary drivers)
13:07tarzeau: since i've had two machines that just kept freezing with nouveau
13:07karolherbst: right.. anyway, if there are problems, gving the latest kernel a try is always a good idea, in case there are still bugs, we can figure out what's wrong
13:07tarzeau: so nouveau ahd pre-kepler is great with latest linux kernels?
13:07tarzeau: i remember having had problems with nouveau + multiscreen (1 and 2 works, but 3 or 4 made problems)
13:07karolherbst: yeah, should be fine. At least we try to not regress and if so, we try to fix those
13:08karolherbst: 4 displays. mhh
13:08karolherbst: yeah.. that could cause issues
13:08karolherbst: it's not exactly tested much
13:08karolherbst: and might even require some tricks
13:08tarzeau: but nouveau drivers will only ever be for display, nothing with gpu stuff
13:08karolherbst: why is that?
13:09tarzeau: no idea, i'm asking
13:09karolherbst: well, we support OpenGL on all available generations now
13:09karolherbst: well.. I guess not the _very_ old ones
13:09tarzeau: but there's no free nvcc or soemthing that makes pytorch/tensorflow stuff work without cuda software from nvidia
13:10karolherbst: right, no CUDA support
13:10karolherbst: there are quite a lot of people wanting to have that, but that's not a goal we could achieve, as catching up would be a huge problem probably
13:10tarzeau: i see
13:11tarzeau: i haven't tried nouveau with 1080 ti/2080 ti, the two most popular we have (up 8 of them per node), but also a lot of NVIDIA Corporation GK107GL [Quadro K420] and a few single ones with like NVIDIA Corporation GF119 [NVS 310]
13:12tarzeau: NVIDIA Corporation TU117 [GeForce GTX 1650]
13:12tarzeau: if there's anything i can dump/test with that stuff, that could help development
13:13karolherbst: ohh.. we recently commited OpenGL support for Turing and will be part of mesa 20.2
13:13tarzeau: i know these cards also have flashable roms, and i know of flashrom (the tool) and coreboot... is any development into going that direction (dumping the nvidia vga rom, and flashing it?)
13:13karolherbst: giving that a shot and report bugs would be helpful
13:13tarzeau: i'm in the middle of migrating all machines from 18.04 to 20.04 (but still stuck for work@home)
13:14karolherbst: tarzeau: well.. the rom is used by the driver anyway
13:14karolherbst: but there is really no point in changing any of that there
13:14tarzeau: the vga bios rom? which is 16-bit code, provindg interrupt based api only for dos? is certainly not used in linux which switches to 32bit protected mode?
13:14karolherbst: the rom only contains some BIOS/UEFI code + scripts and atables
13:15tarzeau: i've always wanted to patch the stock vga fonts with something more beautiful...
13:15karolherbst: it's used by the firmware
13:15karolherbst: tarzeau: huh? what do you mean by more beatiful?
13:15tarzeau: the vga textmodes are bitmap fonts
13:15karolherbst: the rom itself doesn't do much
13:15tarzeau: 8x8, 8x14 and 8x16
13:15karolherbst: it just provides the framebuffer
13:15karolherbst: what the firmware does with it, is up to the firmware
13:15karolherbst: well.. at least with uefi
13:15tarzeau: it provides these fonts, that can be changed with setfont, but that only happens when linux is already started, not at boot time
13:16karolherbst: tarzeau: you might want to move all installations/machines to uefi then :p
13:17karolherbst: distributions started to take over the splash screen in the boot process
13:17karolherbst: like if there is a vendor logo or whatever
13:17karolherbst: and usually in uefi you also get the native resolution
13:17tarzeau: karolherbst: we have hardware of 0-10 years age
13:17tarzeau: not all of them support uefi
13:17karolherbst: right... no idea what to do with the bios one except not care and wait until they are replaced?
13:17tarzeau: i'm aware of that distro takeover
13:18karolherbst: dunno if it makes sense to spend much time on the legacy boot stuff
13:18tarzeau: i only know linux framebuffer is horribly slow
13:18karolherbst: but you can't really change that
13:18tarzeau: and the vesa fb stuff isn't maintained anymore? (linux kernel side)
13:18karolherbst: you could
13:18karolherbst: you could move the GPU driver into firmware code
13:18tarzeau: i don't even remotely think about it
13:18karolherbst: vesafb and uefifb are quite trivial
13:19karolherbst: they figure out where the firmware framebuffer lives and deal with it
13:19karolherbst: BIOS is just very limited and uefi allows for a bit more
13:19tarzeau: is the nouveau driver also used on non amd64/x86_64 hardware? not very popular i guess
13:20karolherbst: well.. there are the arm tegra boards
13:25tarzeau: that old stuff from 2009 is not needed anymore, or is it? nouveau-firmware
13:26karolherbst: nouveau-firmware was never "required"
13:26karolherbst: it just extracted firmware from the nvidia driver for video acceleration
13:26tarzeau: and where would i find the git(preferably github or gitlab) of nouveau? i'm too stupid for https://nouveau.freedesktop.org/wiki/
13:26karolherbst: for video decoding
13:26tarzeau: i see like video mpeg2/4 and so on?
13:26karolherbst: tarzeau: depends which part you look for. The kernel driver lives inside the kernel
13:26karolherbst: opengl/vdpau is provided by mesa
13:27tarzeau: ah that's linked xserver-xorg-video-nouveau
13:27tarzeau: and then there's not much else...
13:27karolherbst: that's just the Xorg driver, but there isn't much going on there
13:27tarzeau: that's linked too
13:27karolherbst: yep.. also irrelevant, just wraps around the kernel UAPI
13:27karolherbst: mesa: https://gitlab.freedesktop.org/mesa/mesa
13:27tarzeau: so the interesting thing is the xf86-video-nouveau
13:27karolherbst: nope, it's not
13:27tarzeau: mesa is only for 3d stuff
13:28karolherbst: "only" :p
13:28karolherbst: kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau
13:28karolherbst: mesa and the kernel bits are the most relevant bits
13:28tarzeau: well to play nethack, i don't need 3d/opengl
13:29karolherbst: well.. true, but most of the magic happens inside the kernel then
13:30karolherbst: the xf86-video-nouveau stuff does some displaying and some 2D acceleration
13:30karolherbst: but you can also get this with the modesetting one, some prefer nouveau, some prefer modesetting
13:30karolherbst: just depends on what kind of bugs you like to run into
13:31tarzeau: i don't understand what is modesetting one or nouveau
13:31tarzeau: what's the difference?
13:32karolherbst: nouveau uses native interfaces for 2D acceleration and modesetting uses OpenGL
13:32karolherbst: in the end it's all the same for the hw, just using OpenGL adds some CPU overhead and might trigger bugs you wouldn't see with nouveau
13:33karolherbst: but from an hw perspective it really doesn't matter all that much
13:33tarzeau: i see
13:33karolherbst: nouveau just has some hardcoded shaders and is more static
13:33karolherbst: and probably has less bugs
13:34tarzeau: https://nouveau.freedesktop.org/wiki/VideoAcceleration/ ahhh...
13:35tarzeau: what would be VP6+ ?
13:35karolherbst: maxwell and newer
13:41tarzeau: thanks for all the information and explanations
17:07AndrewR: pmoreau, I run git bisect, and result was: f4e689473d8067ec968b3a1799633915e41adc40 is the first bad commit, WIP nv50: Refactorise sampler binding, and support compute
17:08pmoreau: I see, thanks
17:09pmoreau: Not too surprised by that either; I just did as little as I could as I have not looked into images, just what was needed to not hit asserts when running basic OpenCL kernels.
17:12pmoreau: If you revert that one, does vdpau work again?
17:23AndrewR: pmoreau, git reset --hard 085bd782974517b344b907ed84dcba428b919274 restores vdpau, will try revert (from top of branch?)
17:24imirkin: pmoreau: if you send me a link, i can probably pinpoint the bug
17:29AndrewR: pmoreau, yeah, reverting also works, vdpau output is normally colored
17:29AndrewR: imirkin, git clone https://gitlab.freedesktop.org/pmoreau/mesa.git ?
17:30AndrewR: imirkin, and git checkout -b nv50_compute_support origin/nv50_compute_support after this ...
17:30imirkin: i meant a link to the commit
17:30imirkin: that i could view in a browser
17:30AndrewR: imirkin, https://gitlab.freedesktop.org/pmoreau/mesa/-/commit/f4e689473d8067ec968b3a1799633915e41adc40
17:32imirkin: nv50_context_shader_stage is wrong
17:32imirkin: or it's right, but it doesn't match what the old things did
17:33imirkin: it returns 1 for FP, 2 for GP
17:33imirkin: while the bind code expects 2 for FP, 1 for GP
17:33imirkin: i'd argue that the original code was wrong
17:33imirkin: but you should also update the other place that reads those arrays
18:08imirkin: pmoreau: --^
20:57pmoreau: I was wondering if it could be something wrong with the indices, when I looked at the patch again. I’ll add a todo to go and fix those.