00:44Unbegriff: hello, i am having some issues with noveau and sddm/plasma, all kind of graphic artifacts. I checked journalctl and found this: https://pastebin.com/NrQNqf2K
00:45Unbegriff: i am realy lost but i noticed only QT5 apps are afected.. kde and ssd but no gtk like firefox or xfce
00:45imirkin_: i think that's a known issue
00:46Unbegriff: can you give me a link? i been searching for hours and i could not find anything about it.
00:46imirkin_: i'm sure if you search for "plasmashell nouveau" you'll find a bunch of such reports
00:46imirkin_: solutions include "don't use nouveau" and "don't use plasmashell"
00:47Unbegriff: oh no.. both solutions are inviable for me
00:48imirkin_: what gpu are you on btw? those error logs look like they might be from a tesla era gpu?
00:48Unbegriff: the nvidia driver is no longer supported for my gpu and it apears to be broken with linux 5+
00:48Unbegriff: Gforce 300M
00:49imirkin_: right yeah
00:49Unbegriff: it is an old macbookpro
00:49imirkin_: on top of everything else, tesla-era gpu's have "issues" that were never tracked down
00:49imirkin_: the 320M in MBP7,1 or whatever?
00:49Unbegriff: that one yes
00:49imirkin_: i.e. MCP89
00:50imirkin_: i don't know if this will affect your issue, but there was a recent fix for something there:
00:51imirkin_: not quite the same issue you're having
00:51Unbegriff: at this point i would follow anything that gives me hope. Otherwise this is just an aluminum paperweight
00:51imirkin_: but i can't imagine this problem would help
00:52imirkin_: you could also dump nouveau_dri.so from your system
00:52imirkin_: which would let you use nouveau for display, but not acceleration
00:55Unbegriff: noted to my list, maybe also downgrading kerner and using the old 340xx
00:59Unbegriff: thx for you help imirkin_
03:10imirkin: skeggsb: you might have said exactly this the other day, but ... it looks like you already have logic to drive the head_lut and output_lut (xlut + olut in the current code naming convention). except the olut setting is busted in head5072d, should be 0x848 instead of 0x840
03:10imirkin: would you say that's an accurate assessment of the situation?
03:14skeggsb: imirkin: yes, it was the intention to put most of the plumbing in place, i just didn't go the full way into wiring it up due to being unsure of whether it was "correct" or not
03:14skeggsb: i'm still not 100% sure if the 507d thing was deliberate for some reason or not
03:14imirkin: ok, i see why you did it the wrong way
03:15imirkin: coz the base lut has to be lores for c8
03:15imirkin: and you attached the logic to the olut instead of the xlut
03:17imirkin: so i think i can just move that to ->ilut and all will be well
03:17skeggsb: maybe. i have a horrible feeling there was some HW weirdness there, but i'll test out whatever you end up doing on 507d anyway and confirm
03:18imirkin: sgtm :)
03:18imirkin: i'll be testing it on a G84, so it won't be too far off from the original...
03:18skeggsb: you'd be surprised :P
03:19skeggsb: nv50 is weird in a few ways
03:19imirkin: i know some of them
03:19imirkin: but not the display ones, actually
03:19imirkin: no memtypes in sysmem was annoying.
03:19imirkin: and the fact that it handles varyings differently is ... infuriating.
03:20imirkin: since ignoring this fact *almost* works :)
03:30imirkin: skeggsb: do you remember why you enable USE_CORE_LUT on base507c?
03:31imirkin: looks like that option isn't available for the OUTPUT_LUT
03:32imirkin: although the implications of that are unclear to me
03:32imirkin: what's the relationship between NV507C_SET_OUTPUT_LUT_LO and NV507D_HEAD_SET_OUTPUT_LUT_LO
03:34imirkin: i.e. if i don't touch NV507C_SET_OUTPUT_LUT_LO and only touch NV507D_HEAD_SET_OUTPUT_LUT_LO - should be ok, yea?
03:43skeggsb: imirkin: if base is enabled at all, none of the equivilant settings on the core channel have any effect
03:44skeggsb: USE_CORE_LUT makes base inherit those settings, instead of its own version overriding them
03:44imirkin: that's ... inconvenient.
03:44skeggsb: but yeah, i'd just ignore OUTPUT_LUT on the base channel, pretend it doesn't exist
03:45skeggsb: oh.. though.. maybe you can't
03:45imirkin: but then the output lut never gets set.
03:46skeggsb: yeah... because output lut doesn't have a USE_CORE_LUT option for whatever reason
03:46skeggsb: that could actually be why i made the choice i did to use the base lut for gamma lut on the core channel
03:47skeggsb: you could always go for the "full cms only supported on 9070 onwards" option? :)
03:47skeggsb: it's not like csc is supported before then anyway
03:47imirkin: well, given the fact that 2 lut's really only make sense once you have a CTM in place
03:48imirkin: i kinda agree
03:48imirkin: ok ffffine.
03:48imirkin: you win this round!
03:48skeggsb: HW: 1, Ilia: 0 ;)
03:48imirkin: more like HW: 1000000000
03:49skeggsb: good point
03:49imirkin: so then in theory degamma and gamma lut's are both hooked up and should Just Work (tm)
03:51imirkin: just missing a check to disable the olut in case that we have gamma && no degamma
03:51imirkin: er actually, that looks covered
03:53imirkin: SET_CSC_RED2RED_OWNER = CORE vs BASE -- any ideas what this is about?
03:54skeggsb: they're not on core are they?
03:54imirkin: they're on base and overlay
03:55imirkin: the overlay one has no such setting though
03:55skeggsb: oh, I missed the OWNER part
03:55skeggsb: let me see...
03:56imirkin: also, should i dump the ctm into xlut.i, xlut, or a new "thing" in wndw_atom?
03:56skeggsb: whatever floats your boat :P
08:15rhyskidd: devinit related: any reviewers for this? https://github.com/envytools/envytools/pull/190
08:57karolherbst: rhyskidd: do you have a vbios which hits all of those opcodes?
08:57rhyskidd: yes, across a set of volta and turing vbioses
10:00karolherbst: what's that "fifo: PBDMA0: 01000000  ch 3 [00ffba4000 shader_runner_g] subc 0 mthd 0008 data 00000000" error about btw?
10:00karolherbst: I see that in a piglit run, but those tests still pass
10:01karolherbst: heh.. doesn't happen if I have a glxgears running besides it
10:01karolherbst: maybe some secboot stuff?
10:06AndrewR: karolherbst, may be some contexts stepping on each other tails? :}
10:11AndrewR: karolherbst, was just reading some related bugs (but it seems freedesktop.org now timeouts for me?) https://bugs.freedesktop.org/show_bug.cgi?id=109341#c4
10:11AndrewR: karolherbst, I also put reference to your work in https://bugs.freedesktop.org/show_bug.cgi?id=98039 hope you are ok with this?
10:20AndrewR: karolherbst, https://bugs.freedesktop.org/attachment.cgi?id=143094
11:47AndrewR: karolherbst, welcome back