01:37imirkin: skeggsb: what's the logic behind the ilut/olut/xlut naming in dispnv50?
01:38imirkin: i'm trying to extend it to support loading both the BASE_LUT and OUTPUT_LUT simultaneously
01:38imirkin: want to keep things consistent, but am having trouble identifying what's consistent :)
01:41imirkin: input = base, output = output?
01:41imirkin: and what's "both"? :)
01:41skeggsb: it covers both luts, there's state that's shared between them
01:41imirkin: like what?
01:41skeggsb: the ctxdma
01:42imirkin: the handle? or something else?
01:42skeggsb: yes, that
01:42imirkin: #define NV907D_HEAD_SET_BASE_LUT_HI_ORIGIN 31:0
01:42imirkin: #define NV907D_HEAD_SET_OUTPUT_LUT_HI_ORIGIN 31:0
01:42imirkin: (same in 507d)
01:43skeggsb: #define NV827D_HEAD_SET_CONTEXT_DMA_LUT(a) (0x0000085C + (a)*0x00000400)
01:43skeggsb: #define NV827D_HEAD_SET_CONTEXT_DMA_LUT_HANDLE 31:0
01:43skeggsb: applies to both base/output
01:43imirkin: makes sense. thanks!
01:43skeggsb: 507d is different, CONTEXT_DMAS_ISO() is used pretty much everywhere, rather than individual ctxdmas
01:44imirkin: ok, so basically i just add a xlut.o, and i'm golden
01:44imirkin: (+ a bunch of code)
02:46imirkin: skeggsb: what's the deal with nv50_wndw_atom vs nv50_head_atom?
02:46imirkin: is wndw only for overlays
02:46imirkin: or is it also for the primary plane on gv100+?
02:47imirkin: and if so, why do we still have head_atom
02:47skeggsb: it's also the primary plane state prior to nvd
02:47skeggsb: the head stuff is core channel state
02:48imirkin: i'll wrap my head around it eventually...
02:48imirkin: or it'll wrap around my head... we'll see.
03:30imirkin: skeggsb: looks like the handles are separate with nvd
03:30imirkin: NVC37D_HEAD_SET_CONTEXT_DMA_OUTPUT_LUT_HANDLE and NVC37E_SET_CONTEXT_DMA_INPUT_LUT_HANDLE
03:58skeggsb: imirkin: yes, and the same is true if you use the input ("base") lut methods on the base channel instead of core
03:59imirkin: on gv100+ that's the only way to set both lut's right?
03:59skeggsb: yes, and it's probably the way we should use them on evo too
04:00skeggsb: fwiw, it is actually how we use them on 9070+
04:01imirkin: and to remind me ... core channel = global thing, base channel = per-head thing
04:01skeggsb: think of base channel as a full-screen, opaque, overlay
04:01skeggsb: one per head
04:02imirkin: and the two channels process commands independently, hence the occasional interlock
04:02imirkin: thanks :)
04:02imirkin: i might write some docs
04:03skeggsb: so, i just double-checked, we program 9070+ EVO and NVD the same way essentially (ie. input lut handled from plane, output lut used on core, not base lut)
04:03skeggsb: i don't know why 8x7d touched base lut methods instead of output lut still
04:03skeggsb: there probably was *some* reason
04:04imirkin: for C8 probably?
04:04imirkin: and/or legacy
04:04skeggsb: well, we manage that on 9x70 just fine
04:05imirkin: ok, well, i'll try to fix all that up throughout
04:05imirkin: hopefully this weekend i should have the degamma/ctm/gamma stuff done
04:05skeggsb: do you have a proper way to validate it works correctly?
04:06imirkin: define 'proper'
04:06imirkin: i will be extending modetest to have configurable stuff
04:06skeggsb: well, something to compare against that's known correct :P
04:06imirkin: which i will also verify on intel/skl
04:06skeggsb: it's kinda why i avoided touching it
04:06imirkin: so we'll either be both right or both wrong :)
04:06skeggsb: perfect :P
04:07imirkin: i don't have a real colorimeter, so i'll never know the _full_ details
04:07imirkin: i expect the CTM stuff will require some fiddling
04:08imirkin: thus far, the kms api has worked the way i expected, so i don't think it's too bad
04:59AndrewR: imirkin, so, according to this https://github.com/intel/libva/blob/master/va/va.h if I want to add support for different Color space conversion flags I should look into vlVaPutSurface() in va statetracker subdir?
05:00imirkin: you know a lot more about va by now than i do
05:00imirkin: but yes, the va state tracker implements things like vaPutSurface
05:00imirkin: (there's wrapping that goes on, so the function in the mesa code is indeed vlVaPutSurface)
05:06imirkin: AndrewR: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/vl/vl_compositor.c#n384
05:09imirkin: AndrewR: and in va/context.c, there is
05:09AndrewR: imirkin, yeah, basically vl_csc_get_matrix/ vl_compositor_set_csc_matrix pair ,,nioww I just need to stuff them into va tracker :} (and add queries and defines. defines were simple!)...
05:09imirkin: vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_BT_601, NULL, true, &drv->csc);
05:09imirkin: if (!vl_compositor_set_csc_matrix(&drv->cstate, (const vl_csc_matrix *)&drv->csc, 1.0f, 0.0f))
05:09imirkin: it's all a bit tricky
05:09imirkin: e.g. what happens if one tries to write RGB data to a YUV backing surface (does the API allow it, etc)
05:12imirkin: the real key to all this is to have a good test-case
05:31AndrewR: imirkin, https://pastebin.com/s0TBhewB - like this (it doesn't read attribs via API, just hardcodes something ..hopefully at right place at minimum!)
05:35AndrewR: imirkin, pardon this actually compiles https://pastebin.com/cD0PzD00
09:26mercury^: Hi. I am getting a BadValue (0x0) error for X_GLXCreateNewContext when trying to run glxinfo in xorg. The kernel module and the X11 driver are loaded.
09:29mercury^: (And mesa is installed.)
09:30gnarface: seen this? https://nouveau.freedesktop.org/wiki/FeatureMatrix/
09:33mercury^: gnarface: it's NV50, so I believe it should work?
09:33gnarface: hmmm. i guess so, probably
09:34karolherbst: mercury^: mhh, yeah, it should work :
09:34karolherbst: mercury^: LIBGL_DEBUG=verbose glxinfo
09:35mercury^: karolherbst: that only adds the display number to the information.
09:35karolherbst: huh? weird, so maybe something is wrong on the X level
09:36karolherbst: mind sharing your X log?
09:36mercury^: karolherbst: I would not mind, but it is not so easy, because the machine with the error is fairly bare-bones.
09:37gnarface: find a program called pastebinit
09:37gnarface: it's in the debian repos
09:43mercury^: karolherbst: is there something that I should look for in the X log?
09:44karolherbst: no idea, because I have no idea what's going on, I have some ideas, but it would be just easier to pastebin the log
09:46gnarface: mercury^: usually lines with "(EE)" on them, but you need some context too
09:46gnarface: easier to just share the whole thing
09:50mercury^: Hmm, does that say removed for you too?
09:50mercury^: I used pastebinit.
09:51gnarface: i believe you
09:51gnarface: i don't know what went wrong
09:53mercury^: Well, the only errors in the log are failures to load other drivers (nv, fbdev, vesa)
09:55gnarface: well make sure it settled on the right one
09:56gnarface: "(WW)" might also be a sign of stuff gone wrong, but some are normal too
09:58gnarface: lines 110, 111 and 56 look like problems
09:58gnarface: not sure if they're related though
09:59gnarface: could be a kernel version issue?
09:59gnarface: i dunno
10:00mercury^: gnarface: I do not think that the lines you mention are part of the problem.
10:01mercury^: karolherbst: do you see anything?
10:02mercury^: oops, wrong keyboard :)
10:49karolherbst: ohh, I was out for lunch, src
10:49mercury^: karolherbst: no problem, thanks for your help.
10:49karolherbst: mhh weird, the GLX stuff seems fine
10:50karolherbst: mercury^: mind testing eglinfo?
10:50mercury^: ugh, that says FATAL: Module nvidia not found
10:50karolherbst: ohhh, I think I know what's going on
10:51karolherbst: find /usr/lib64/ -iname *nvidia*
10:51karolherbst: are some nvidia libraries installed?
10:51karolherbst: I guess the actual active GL frontend is from nvidia
10:51karolherbst: that's why things just fail
10:51karolherbst: you might want to uninstall all the nvidia stuff
10:51mercury^: karolherbst: I had nvidia-340xx installed until this morning, when support was discontinued in arch.
10:52karolherbst: ohh, I see
10:52mercury^: I thought I did uninstall it..
10:52karolherbst: maybe some bits where left behind? dunno
10:52karolherbst: anyway, it sounds like the issue you are having is that some nvidia stuff is still there
10:53mercury^: Definitely. Now I just have to figure out how to get rid of it.
10:55karolherbst: maybe some nvidia packages are still installed? worst case, just remove the files or something... maybe you are even able to switch the active GL installation to mesa or something. No idea how all that works in arch
11:00mercury^: Alright, managed to get it working. Thanks again for the help.
14:20karolherbst: pmoreau: meh.. I don't have any good solution for that pc vs entry_point thing curro complained about
14:20karolherbst: I am not willing to rework nouveau for a pointless thing
16:55karolherbst: pmoreau: okay... soo, I have no idea how to rework that properly
16:55karolherbst: and I don't want to add support for multiple entry points inside nouveau
16:55karolherbst: or, let's rephrase that. I refuse to even consider that
16:59imirkin_: what's the issue? (i gtg now, but will be back in an hr or two)
17:04karolherbst: meh.. curro doesn't like my entry point patch
17:04karolherbst: and wants to stick with the .pc stuff
17:05karolherbst: which means that on shader binding time, we don't know which entry point to choose
17:05karolherbst: which means, we would have to upload a binary with multipe entry points
17:05karolherbst: and select when launching the kernel
17:05karolherbst: and I kind of don't want to add all the code for that inside nouveau if we have totally different plans anyway which would make that useless anyhow
18:28razic: hello. i am experiencing freezes using sway (latest arch kernel) with nouveau drivers. do you have any idea how i can debug this?