06:47 yusisamerican: This call to refrence the bufctx to the pushbuf is taking half as long as the entirety of buffer validation on gallium nouveau: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c?ref_type=heads#L940. Maybe its some weird cache miss bug on my cpu....profiled 327.5k draw calls to 535.8k draw calls per seccond
06:47 yusisamerican: bweh?
07:04 ad__: Lyude: thanks, no hurry. Yestarday night collapsed on the keyboard. only think i have ssen is that, in nv50_backlight_init(), nvif_outp_bl_get(&nv_encoder->outp) returns -22
07:04 ad__: https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/nouveau/nouveau_backlight.c#n242
07:06 ad__: nv_encoder->outp shows a value (not null), but it's as it is a wrong outp type, backlight cannot be retrieved
07:08 fdobridge: <a​huillet> ad__: seeing my messages now?
07:09 fdobridge: <a​huillet> it's strange, it seems I have to be on IRC for you to read me
07:09 ahuillet: ad__ : seeing this now?
07:24 ad__: ahuillet: did some debug yesterday, this is happening on my ADA, nvkm_udevice_info() card type 400
07:25 ad__: ahuillet: now yes, i can read you
07:43 fdobridge: <d​adschoorse> now that fp16 for nak is merged, I guess someone could work on 16bit tex/image load/store
07:49 yusisamerican: dadschoorse: or maybe someone could do hmma?
07:49 yusisamerican: I tried it in codegen but that was when I was in middle school so its probably complete garbage
07:51 fdobridge: <m​arysaka> yusisamerican: I am working on cooperative matrix
07:52 yusisamerican: marysaka: oooooh
07:53 yusisamerican: For nvidia devices?
07:53 fdobridge: <m​arysaka> yes
07:54 yusisamerican: wondering how we will expose it through gallium's interface for tensors...maybe a modification to teflon?
07:55 yusisamerican: To use nir instead of the gallium interface
07:55 fdobridge: <m​arysaka> I'm only implementing VK_KHR_cooperative_matrix
07:58 yusisamerican: oh! but are you still using the {b/w/i}mma thing that rtx gpus have to accelerate it? If so then maybe I would be intrested in porting gallium to use nak...
08:03 ahuillet: ad__ : so, your system ideally should go through the GSP thing I pointed yesterday. Did you try to figure why it was not?
08:03 ahuillet: As far as I can tell, however, the blob within GSP does something similar to your MR, which is why you're getting results with your current patch, except it does it correctly and in a way guaranteed to work.
08:26 fdobridge: <m​arysaka> yusisamerican: it use IMMA/HMMA yes, BMMA doesn't map to anything with Vulkan so far I think
08:33 ad__: ahuillet: thanks, ack, this evening will try to go deeper
08:34 ahuillet: I'm very new to this, trying to figure out how you'd get into these functions in the first place vs. the backlight stuff you've been patching. :)
08:36 ad__: ahuillet: so i bought a Lenovo Legion Pro 5, and backlight with nouveau was not working, screen black. I tried the acpi fallbacks (as vendor, native etc, no luck, still screen black)
08:36 yusisamerican: marysaka: seems intresting, never knew about the vulkan extension...that could be a gateway to zink support for teflon...buts thats for the future to decide
08:36 ad__: ahuillet: so i installed mainline kernel, in the hope there was some fix, but not
08:37 ad__: ahuillet: finally i grepped in the nouveau code, and find out nouveau_backlight_init() as the place where backlight ws initialized (nouveau_backlight.c)
08:37 yusisamerican: ad__: Wait a minute, I had that device for a while before deciding to return it
08:38 yusisamerican: I never had that issue (⊙_⊙)
08:39 ad__: ahuillet: i realized that the switch/case in that function was stoped at NV_DEVICE_INFO_V0_AMPERE, there was no NV_DEVICE_INFO_V0_ADA, and my device->info.family was NV_DEVICE_INFO_V0_ADA, so i worked to patch from that point
08:39 ahuillet: r535_sor_bl_set does what I think you want. it's plugged into a nvkm_ior_func_bl structure, but I am not sure what path is taken to call these as opposed to what you're patching
08:40 ad__: yusisamerican: this laptop can work into 2 ways, discrete (nvidia) and switching (amdgpu + nvidia), i am now in discrete (nvidia/nouveau driver only)
08:40 yusisamerican: Oh, that explains it
08:41 ad__: ahuillet: i have seen, i cannot bint to that function directly, also, that is only a bl_st, all the backlight init should be from r535 i believe
08:41 ad__: *bl_set
08:43 ad__: if those r535 methods are there, i will try to figure out how they should be called
08:44 ahuillet: nvkm_uoutp_mthd_bl_set this is what calls them I think?
08:45 ad__: actually, from my patch, only thinh unclear is that drm detects a 8 bit pwm (so 256 max_brightness) while max seems to be 4096 (12bit). I cannot access eDP specifications (pdf) to check this.
08:45 yusisamerican: Whatever backlight thing is used, it *reallly* should be exposed through drm_connector properties, there are plans to expose that to userspace
08:46 fdobridge: <a​irlied> did you try acpi_backlight=native nvidia-wmi-ec-backlight.force=1 combo?
08:46 yusisamerican: ad__: Uhhhh maybe thats because maxes of greater than 256 through /sys/class/backlight or whatever break userspace?
08:46 ad__: yusisamerican: drm apis is what i have used in my patch, they works
08:47 ad__: yusisamerican: well i hardcoded 4096, it works, so 256 is not a limit
08:47 fdobridge: <a​irlied> apparantly newer laptops with dynamic mux gpus are quite broken for backlight with Linux and nvidia is meant to be looking into it
08:47 yusisamerican: ad__: You misunderstnd, the nvkm_uoutp_mthd_bl_set thing should be exposed through drm, it doesnt seem to be currently
08:48 ad__: mmm, i am totally a newby here. What is nvkm ? I see it enbds up to some system calls (ioctl)
08:49 yusisamerican: nvidia modesetting folder
08:49 yusisamerican: I think
08:51 ad__: ah no sorry, confused nvkm with "nvif" that seems to be a ioctl based interface
08:54 ad__: well, this evening will dig further into ahuillet r535 way and nvkm_uoutp_mthd_bl_set
08:54 ad__: now unfortunately had to complete some main job tasks
08:54 ad__: thanks for the support
08:54 yusisamerican: Oh
08:55 yusisamerican: im completely wrong, it is exposed through drm_connector they were using nvif_outp_bl_set and I looked in the wrong place
08:55 ahuillet: yusisamerican : can you share a file:line?
08:56 ahuillet: (was struggling to find the same)
08:56 yusisamerican: nouveau_backlight
08:56 yusisamerican: .c
08:56 yusisamerican: I deleted emacs one sec, ill give you the line
08:56 ahuillet: in nv50_set_intensity() ?
08:56 yusisamerican: ye
08:57 ahuillet: I don't think this actually calls into the r535 stuff though
08:57 yusisamerican: It should no?
08:57 ad__: looks not going that direction, it binds to proper set/get
08:57 yusisamerican: ret = nvif_object_mthd(&outp->object, NVIF_OUTP_V0_BL_GET, &args, sizeof(args));
08:58 ahuillet: mmh actually yes it goes to nvkm_uoutp_mthd_bl_set
08:58 ahuillet: and I think that should end up in the r535 stuff. ad__ : it's worth tracing where that is falling apart
08:58 yusisamerican: ahuillet: Dont you need serial for that? :p
08:59 ahuillet: ?
08:59 ad__: if (nvif_outp_bl_get(&nv_encoder->outp) < 0 || fails with -22
08:59 ahuillet: yusisamerican : serial what?
08:59 yusisamerican: oh you can use printk, im sorry for being stupid
08:59 ad__: this is why i implemented the patch without calling that
08:59 yusisamerican: ad__: ENODEV I think
08:59 ad__: right
08:59 ahuillet: now we're talking
09:01 ad__: so i suspect in find_encoder()
09:01 ad__: https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/gpu/drm/nouveau/nouveau_backlight.c#L306
09:01 ad__: to be finding an encoder that is not the right onw
09:01 ahuillet: 22 is EINVAL?
09:01 yusisamerican: Oops.....
09:01 ad__: it's EINVAL, sry
09:03 ahuillet: who's actually failing though? would be good to prink till the failure point
09:04 yusisamerican: Are there any (drm_encoder)s connecting?
09:05 ad__: failure point is that nv50_backlight_init returns 0. so nouveau_backlight_init() attempts a fall back to acpi, that is not working anyway, so no backlight. There is no fault/oop.
09:06 ad__: i tried to check what encoder types are processed from find_encoder(), there is a huge amount of type 6 and some 2
09:06 ahuillet: that's not the failure point, it's the top level failure point
09:06 ahuillet: I meant to printk the hell out of this until you find the deepest point where things start to fail
09:07 ad__: well, dmesg shows a lot of BL_GET: -22
09:08 yusisamerican: So nouveau is trying to run nvif_outp_bl_get? and nv50_get_intensity? Didnt you say that it(initialization) failed?
09:09 ad__: all i know is that the initial point of failure is nvif_outp_bl_get(&nv_encoder->outp) returnig -22
09:09 ad__: but before that, also, there is another point.
09:10 ad__: why the switch/case stops to case NV_DEVICE_INFO_V0_AMPERE: ?
09:10 ad__: i had to add case NV_DEVICE_INFO_V0_ADA:
09:10 yusisamerican: because someone forgot to put it there
09:10 yusisamerican: or because no one tested it
09:10 ahuillet: most likely it didn't even exist then?
09:10 ad__: or becouse it was considered better to fall back to acpi
09:11 ad__: so if never existed, good, i am patching correctly so
09:11 ahuillet: look at the git history, case NV_DEVICE_INFO_V0_AMPERE: //XXX: not confirmed
09:11 ahuillet:
09:11 ahuillet: even GA10x was barely tested then and it was one without display
09:11 ahuillet: so, wait, since when do we actually have GSP stuff, Turing right?
09:11 yusisamerican: Since 6.7
09:11 ahuillet: I mean the NV HW generation
09:11 yusisamerican: covid
09:12 ahuillet: (sorry, we = NVIDIA... I'll need to get my first person pronouns sorted out)
09:12 yusisamerican: 2019
09:12 yusisamerican: I think
09:12 yusisamerican: September 20, 2018
09:12 ahuillet: anyway I'm just guessing at this point and making more noise than I should, but it doesn't seem obvious to me that the GSP stuff for setting backlight is actually plumbed all the way
09:14 ad__: well, ok, this evening i will dig further into that. Right now i have no more precise findings, except that the patch i sent works great, but is likely not the right way to go.
09:14 ahuillet: ad__ : I hope airlied or Lyude can advise
09:15 ad__: yes, will check for their replies :)
09:15 yusisamerican: airlied's reply is that dynamic mux gpus are broken and nvidia is looking into it
09:16 yusisamerican: Is dri-prime subprime for your needs?
09:16 ahuillet: do you have a link to the reply? I'd want to dig up internal bug numbers/employee names
09:16 yusisamerican: ahuillet: Today's chat log
09:20 ahuillet: oh, yeah, I wouldn't take it to imply that ad__'s problem can't be fixed, since he's reporting that the blob works fine
09:23 yusisamerican: ahuillet: Is there anything similar in the blob commit log to this regarding ampere/ada?
09:26 ahuillet: I'd need to know what I'm looking for ;) git-log --grep "Ampere" would be a bit unwieldy
09:26 yusisamerican: Something in nvidia-drm-encoder.c???
09:26 yusisamerican: since he said find_encoder was returning EINVAL?!?!?!? bit of a shot in the dark though
09:28 ad__: the gpu i have is ADA, but Mobile MaxQ variant, so AD107 but GN21-4 variant
09:28 ad__: *GN21-X4
09:28 ad__: i think is different from other previous ADA
09:29 yusisamerican: oooh
09:30 yusisamerican: not related to your thing but the blob seems to be using the percentage mode in its backlight_properties
09:31 ahuillet: https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia-modeset/src/nvkms.c#L6682 ?
09:32 yusisamerican: yeah
09:32 yusisamerican: looks neat
09:32 yusisamerican: Ah! maybe we can use this instead of your magic max_brightness
09:35 ad__: yusisamerican: let me try it
09:36 ahuillet: so actually... there's some Ada specific stuff in the blob
09:36 yusisamerican: ad__: We still need to figure out whats wrong with the drm_encoder thing before venturing into making everything device gucci
09:36 ad__: ok
09:37 yusisamerican: ahuillet: Are you allowed to go on according to your obligations?
09:37 ad__: where did you read airlied replies ?
09:38 ahuillet: allowed, maybe, able, definitely not, I'm a UMD driver engineer who has never touched backlight before :)
09:39 ahuillet: https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/common/inc/displayport/dpcd.h#L1105
09:39 yusisamerican: ad__: fdobridge is the bridge between discord and irc, I dont think you can read their messages for some reason though...
09:40 ahuillet: as I mentioned alread, the blob writes to these registers which seems to kinda match what the DRM stuff is doing
09:40 ahuillet: but, "kinda" is one thing, and that's why you need to use GSP for setting brightness stuff, because there's some specific logic to decide what to use and how
09:41 ahuillet: not much more to add really, you don't want to poke these registers directly even if it can be gotten to kinda work because there's no deeply complex magic in there
09:42 ahuillet: (the Ada+ stuff btw seems to be the use of PWM vs. AUX, but that seems like an implementation detail)
09:43 ad__: what is AUX ?
09:44 ahuillet: your guess is as good as mine, I think it's display port auxiliary channel used to convey information? something like that?
09:44 ahuillet: not relevant to your problem anyway.
09:46 ad__: Well, i debugged into drm_edp_backlight_probe_max() and ad PWM width it gives 8bit (max brightness 255), but seems i need 4096 as a max (12bit).
09:47 ad__: So maybe that function is not managing properly the pwm for this chip
09:48 ahuillet: that may be true, but I believe that approach to be a dead end anyway (maybe the Nouveau maintainers will feel otherwise, but I would be surprised)
09:48 ad__: This function is for eDP, btw. Would be great if you know a way to download a DPCP spec for eDP (that is different from DP)
09:48 ahuillet: I'm reasonably certain it's not public
09:49 yusisamerican: I think the main thing you should be worrying about first is seeing why the 800 calls to drm_encoder_init in nouveau arent giving you your drm_encoders. Your max brightness woes can be solved by using percentage mode and modding the kernel a bit probably.
09:49 ahuillet: ad__ : but my link above has fairly explicit define names, so you can infer a lot from that
09:50 ad__: ok. Well, i need to study on this, only studying deeper the layers and nouveau will help
09:50 ad__: tonight next stage :;)
09:50 ahuillet: it might be a case of Nouveau not finding our output (encoder? not sure how it's called) and therefore not exposing the interface you need
09:51 yusisamerican: ahuillet: Im think its DRM not finding the output, if find_encoder is failing in nouveau
09:51 ad__: ahuillet: that looks like, from the -22
09:51 ahuillet: yusisamerican : ENOPARSE
09:52 yusisamerican: ahuillet: are you throwing that exception? See: https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/gpu/drm/nouveau/nouveau_connector.c#L378, and whats called by it and returning -22, https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/gpu/drm/nouveau/nouveau_backlight.c#L306
09:55 ahuillet: I don't want to speculate, because I feel that Lyude is going to take a look and solve the problem in 20 seconds while I'll have spent hours making wild hypotheses that amount to nothing :)
09:56 yusisamerican: probably...
09:56 ad__: same for me :) i miss knowledge
09:56 ad__: but it's cool to dig inside this driver, very complex
09:56 ad__: i generally work on embedded stuff, quite simplier
09:59 ahuillet: GPUs... the more you learn, the more you learn about things you don't know
09:59 ahuillet: and since the tech evolves pretty fast, you can't ever catch up
09:59 yusisamerican: ahuillet: Thats the same for everything, not just tech or gpus
09:59 ahuillet: true, that applies to life in general certainly
09:59 ad__: but closed blobs helps :)
10:01 ad__: i mean, if you cannot see datasheets/specs, some open code helps to understand
10:02 yusisamerican: ad__: Sorry if this comes across as yapping but, most of the hw init, modesetting, command submission and 3d initialization code is simple, its just that the drivers tend to be highly generalized and big
10:04 ad__: yusisamerican: aha ok. Seems huge amount of stuff, but may be generally simple, sure.
10:04 ad__: i work on drivers that are generally 1 single .c
10:05 airlied: did you try acpi_backlight=native nvidia-wmi-ec-backlight.force=1 combo?
10:05 airlied: is what i said
10:05 airlied: our rh backlight dev said it was all a big mess
10:06 ahuillet: https://lore.kernel.org/all/20230217144208.5721-1-hdegoede@redhat.com/ I assume?
10:07 ad__: airlied: can try it, just give few minutes. Btw, i am not sure nvidia-wmi-ec driver applies to this gpu, since i don't see it loaded
10:08 airlied: part of the story,just had an internal email about it
10:09 airlied: ahuillet: daniel dapas on nvidia side knows more apparantly
10:09 ahuillet: cool. is it generally preferred to use ACPI or the native driver?
10:09 ahuillet: thanks, I'll ping him if needed (same team)
10:10 yusisamerican: It seems Hans wants some sort of drm interface for backlight long term
10:11 airlied: i think there is now acpi, ec and native
10:20 ad__: airlied: https://pastecode.dev/s/iixp8h2z
10:21 ahuillet: ad__ : and, does it work? :)
10:21 ad__: no
10:21 ad__: black screen as usual
10:21 ad__: i have built nvidia-wmi-ec-backlight but it gets not loaded
10:23 ahuillet: there's some ACPI firmware errors in your dmesg, is your bios up to date? highly unlikely to make a difference but it might not hurt...
10:24 ad__: ahuillet: yes, just updated few days ago
10:24 ad__: was the first thing i did
10:37 airlied: can you ssh in and play with sysfs files?
12:14 ad__: airlied: yes
12:15 ad__: sry was out for lunch, just let me know what to do, sure
12:15 fdobridge: <a​huillet> I'd assume he means for you to play with /sys/class/backlight stuff?
12:16 ad__: mm, i see now that cat /sys/class/backlight/ is empty
12:17 ad__: typically happening here with acpi_backlight=native
12:50 ad__: i suspect in some Lenovo issue, or bios issue
12:51 ad__: this PC has 2 video cards, i am wondering how the control of the display through a single eDP connector is shared
12:52 ad__: right now. gpu-controlled bachlight with my patch works, while acpi is not, whatever i set, vendor, native orr video
17:56 fdobridge: <g​fxstrand> Ugh... The OpenGL CTS ran for 22 hours and then hit a VK_ERROR_DEVICE_LOST on a test it's already passed 20 times in that run. 🤦🏻‍♀️
18:00 fdobridge: <g​fxstrand> It was a spurrious timeout so I suspect it might be that IRQ issue that @airlied was hunting.
18:09 fdobridge: <z​mike.> gotta love the "try 500 different fb configs" requirement for conformance
18:16 fdobridge: <g​fxstrand> Yeah
18:17 fdobridge: <g​fxstrand> At least with the Vulkan CTS bloat, the different combinations might matter. No, running the fragment shader fp64 tests per-fb-config does not actually test anything interesting. 🤦🏻‍♀️
18:18 fdobridge: <g​fxstrand> If your implementation of fp64 add changes based on whether or not there's a depth buffer, something has gone horribly wrong.
18:22 fdobridge: <!​DodoNVK (she) 🇱🇹> Fixing the cause of it will help with driver stability even further
18:22 fdobridge: <g​fxstrand> Yeah, but something that takes 22h to reproduce isn't easy to fix. 😢
18:22 fdobridge: <a​huillet> what sort of error dump do you get along with the device lost?
18:25 fdobridge: <g​fxstrand> ```
18:25 fdobridge: <g​fxstrand> [147692.776876] nouveau 0000:17:00.0: cts-runner[145054]: job timeout, channel 64 killed!
18:25 fdobridge: <g​fxstrand> [147692.777387] nouveau 0000:17:00.0: cts-runner[145054]: error fencing pushbuf: -19
18:25 fdobridge: <g​fxstrand> ```
18:25 fdobridge: <g​fxstrand> dmesg is otherwise clean
18:25 fdobridge: <a​huillet> awesome
18:27 fdobridge: <g​fxstrand> @airlied was chasing an issue at one point where IRQs seemed to just get lost sometimes. I think he fixed some of it with some of the locking and waitlist stuff but I suspect we still have a deep race somewhere.
18:28 fdobridge: <g​fxstrand> I've seen other spurrious timeouts
18:33 fdobridge: <g​fxstrand> Yeah, that's drm_scheduler kicking us
18:43 fdobridge: <m​agic_rb.> This has been probably fixed, im running 6.8 and some random mesa commit. But when switching workspaces, map/unmap arma3 consistently crashes. Think its related to VK\_ERROR\_DEVICE\_LOST since minecraft did that too with Zink but it was `ZINK_DEVICE_LOST` or smth. I can dig further if this rings no bells, but i cant bump kernels because ZFS
18:43 Lyude: airlied: looking at the memory fragmentation issue with nouveau I managed to hit yesterday during runtime suspend - you mentioned doing a vmalloc allocation instead of a level 7 coherent allocation. Seeing as that change would be in nvkm_gsp_mem_ctor() - would we want to just change that function or figure out how to only do vmalloc() with the allocation that was failing?
18:44 Lyude: FWIW: the allocation failure was in drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c in r535_gsp_fini()
18:48 Lyude: (if you need more context to remember what I'm talking about let me know, I've still got the log sitting around)
18:52 airlied: Lyude: i think we would vmalloc always, but the code to make the radix3 stuff might need adapting
18:52 Lyude: also i'm curious, I know what a radix trie is but what is it's significance here?
18:53 Lyude: I assume it's some sort of bookkeeping for mappings?
19:10 fdobridge: <a​irlied> It's just a page table format NVIDIA uses, radix3 is it's name
19:12 fdobridge: <!​DodoNVK (she) 🇱🇹> And speaking of page tables Vita3K seems to fail on NVK when using the page table for memory mapping (there's a segfault somewhere in the DRI render device map according to /proc/maps)
19:19 Lyude: gotcha
19:56 airlied: Lyude: got link to complete backtrace again?
19:57 Lyude: airlied: sure thing, gimme a sec. BTW - just to make sure I understand this code correctly
19:59 Lyude: r535_gsp_fini allocates a section of coherent memory on the host's side of things and maps it to make it accessible to the GPU, this memory is used to communicate to the GPU where to migrate all of it's vram to in preparation for shutting down the GSP firmware and vram - and we then kick off the migration with r535_gsp_rpc_unloading_guest_driver() right?
19:59 Lyude: also airlied https://paste.centos.org/view/f5fe9fa8 full backtrace