03:54imirkin: skeggsb: see ML for someone with issues with GF119 DP while running a DP training init script, it seems.
17:15imirkin: in case someone has nothing to do, making nvbios print the script addresses for the DP INFO table would be great. and also making it support earlier versions of the DP INFO table.
17:18linkmauve: Our server’s GPU is now up! https://drmdb.emersion.fr/devices/a9db5db58d07
17:18linkmauve: Now that I’ve done everything I planned for it, I can blacklist nouveau on this server. :D
17:19imirkin: lol
17:20imirkin: but don't you want to accelerate your web server workload on the gpu?
17:20imirkin: as we all know, gpu is faster than cpu, so ...
17:20imirkin: (why do they even bother sticking cpu's in, i honestly don't know)
17:21linkmauve: (Yeah, such a mystery!)
17:21karolherbst: imirkin: you are now joking about this...
17:21imirkin: only now?
17:21linkmauve: It has a bazillion CUDA cores so it must be faster than this stupid Xeon with its four cores!
17:22karolherbst: imirkin: there are people convinced that GPU only systems can exist :p
17:23imirkin: they can
17:23linkmauve: Even Broadcom didn’t manage to do so, they attached an ARM core to their Raspberry Pi GPU.
17:23imirkin: just a simple spelling issue
17:23imirkin: here's this Intel Xeon chip. it's a GPU. hooray!
17:26karolherbst: imirkin: btw, is the include/drm/nouveau_drm.h file somehow in sync with our drm/nouveau/uapi/drm/ bits or is that just a copied on demand from various header files?
17:26karolherbst: kind of looks a bit random
17:26imirkin: copied on demand
17:26karolherbst: k
17:26karolherbst: then I just add the things I actually care about
17:27imirkin: ideally should be an exact copy, but i guess something changed in one of the refactors
17:27imirkin: or something? dunno
17:27karolherbst: yeah..
17:27karolherbst: I think we split it or something
17:27karolherbst: anyway, the libdrm header contains stuff from various header files
17:28karolherbst: ohh
17:28karolherbst: NOUVEAU_GEM_CPU_PREP_NOBLOCK is gone
17:28karolherbst: where do we even use that?
17:28imirkin: no clue
17:28imirkin: questions for skeggsb i suppose
17:29linkmauve: Is it expected that CRTC gamma can only be 256, and not 1024?
17:29linkmauve: That would be an issue for 10-bit displays right?
17:29imirkin: can be 1024 too
17:30imirkin: the legacy gamma size is 256 though
17:30linkmauve: Oh, and we can change that using some DRM API?
17:30imirkin: too many issues if it's any other value
17:30linkmauve: Ah, the one displayed in CRTCs here is the legacy one?
17:30karolherbst: imirkin: there isn't anything besides mesa and xf86-video-nouveau, right?
17:30imirkin: linkmauve: dunno, but that's a thing that exists
17:30imirkin: karolherbst: nothing permanent. i'm sure ben and i have our series of hack-projects
17:31karolherbst: yeah well...
17:31imirkin: [as do you, i suppose]
17:31karolherbst: I mean I will just remove stuff if it's not used anywaay
17:31karolherbst: anywhere
17:31karolherbst: to have the files more in sync
17:31linkmauve: imirkin, ok, thanks. :)
17:32karolherbst: imirkin: what about NOUVEAU_DRM_HEADER_PATCHLEVEL?
17:32karolherbst: should I increase it or doesn't it matter
17:32imirkin: linkmauve: hm, i wonder if we should set GAMMA_LUT_SIZE and DEGAMMA_LUT_SIZE to 1024
17:32imirkin: karolherbst: no clue
17:32imirkin: linkmauve: what kernel is this? didn't always support 1024-sized luts
17:33linkmauve: imirkin, latest 5.4 LTS.
17:33imirkin: ok, 5.4 should almost certainly have that
17:33imirkin: (let's check)
17:34imirkin: commit 131992709dc4c6140cec3b352f820cb873f7dd50 -- in kernel v5.6-rc1+
17:34imirkin: o well
17:35linkmauve: I could update, but this is a server and I don’t plan on using Nouveau ever on it.
17:35imirkin: we also currently don't support 10bpc hdmi
17:35imirkin: only on DP
17:35imirkin: hdmi gets dithered down to 8bpc on the wire
17:36karolherbst: imirkin: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/67
17:36karolherbst: NOUVEAU_GEM_PUSHBUF_SYNC :)
17:41linkmauve: Ok.
17:41imirkin: (because i'm lazy)
17:42imirkin: (as are other people, apparently, since it's not like i'm the _only_ person who can do this...)
17:42karolherbst: imirkin: I think you are the only one with enough time for stuff like this .p
17:42imirkin: i have like ... zero time
17:42karolherbst: yeah...
17:42imirkin: anyways, if skeggsb likes it, i'm fine with it
17:43karolherbst: were you refering to the MR or 10bps HDMI support
17:43imirkin: MR
17:44karolherbst: ahh yeah. I can ask skeggsb about that one
17:44karolherbst: probably
17:44imirkin: although if he were to implement the 10 (well, 12 really) bpc HDMI stuff, i certainly wouldn't be opposed to it
17:44karolherbst: but it's really just copying the bits from nouveau over
17:44imirkin: i thought i had suckered Lyude into looking at it
17:44karolherbst: I am sure Lyude would like to look into it
17:45Lyude: yeah-it's on my todo list
17:45imirkin: linkmauve: btw, experimentation suggests that 10bpc fb's dithered down to 8bpc look a lot better than a plain 8bpc fb.
17:45linkmauve: Yeah, I know, I’m doing dithering in mpv for this reason.
17:46linkmauve: My current panel is 6bpc. ;_;
17:46imirkin: (it was a highly contrived test of course, but my eyes aren't quite as good as the high-end light meters...)
17:46Lyude: crunch time just happened to come a few days ago, but i should be back on nouveau soon
17:46imirkin: Lyude: ah cool. crunch away!
21:13Lyude: /finally/ managed to reproduce the latency issues that intel was seeing with the vblank worker stuff, so hopefully should be able to get that out of the way for nouveau crc support :) (next i'll probably look at the hdmi issues, -really- want to get crc into the kernel sooner then later)
22:47fincs: imirkin: Remember we found word[0] of the vertex shader header had 0x02000000 set when we were investigating the viewport mask stuff?
22:48fincs: Well I've found today that it apparently corrupts something related to shader inputs/outputs when there are more than 1 (?), so I disabled that bit
22:48fincs: So the safest thing to do is just to avoid setting it; I tested the viewport mask stuff with it cleared and it still works
22:48fincs: Just to let you know in case nouveau code is setting it
22:49HdkR: multiprojection related flags maybe?
22:49fincs: Doesn't seem to be related to multiprojection
22:49fincs: But like, my rainbow cube which had color as the second attribute, had the colors corrupted
22:49fincs: Same for my textured cube, which had the texcoords corrupted
22:49HdkR: fun
22:50fincs: So *stay away from this bit* basically
22:50fincs: Maybe it's some funky powersaving thing for shaders that only need one attribute or something, but that needs more investigation
23:29imirkin: fincs: ok cool
23:30imirkin: it probably does something, and we'll eventually learn what it is, but not now
23:31fincs: Yeah