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