01:55 imirkin: dboyan_: a few of the esp earlier comments apply to a bunch of places, i didn't always point all of them out.
02:07 dboyan_: imirkin: thanks, I'll be careful.
02:10 dboyan_: imirkin: Do you think 2/9 fits into stable? If so, I'll add cc: mesa-stable line after fixing it.
02:14 imirkin: yes, i think so
02:14 imirkin: it's very unlikely to hit the issue, but definitely possible
02:14 imirkin: (we rarely allocate more than 2 predicates)
03:41 Satchelboi: imirkin: Are you free to take a look at something quick?
03:42 imirkin: sure
03:47 Satchelboi: I replaced the chipset constants with the SM constants where ever the chipset constant was used. Heres the before: https://paste.fedoraproject.org/paste/E--8Z8J-9rRrVpmtsS1Nbl5M1UNdIGYhyRLivL9gydE= and the after: https://paste.fedoraproject.org/paste/inN3ZokXIsDF9X8AqBJGX15M1UNdIGYhyRLivL9gydE=
03:49 imirkin: Satchelboi: it's a start
03:49 imirkin: does it still build?
03:50 Satchelboi: Whoops, I actually have to check if it does. One sec
03:50 imirkin: a good thing to do after you use sed a bunch :)
04:03 Satchelboi: It built alright
04:04 Satchelboi: I actually caught a few parts I missed going back too where the constants were still set to chipsets
04:05 Satchelboi: Im running the make check on it too
04:06 imirkin: meh... that generally won't catch anything if you're only modifying stuff in nouveau
04:07 Satchelboi: But yeah though, it built again without any errors
04:07 imirkin: well, if you had to fix things related to missed conversions
04:07 imirkin: and prior to that, it had built properly
04:08 imirkin: i would suggest that there's a chance that you're not building things at all
04:09 Satchelboi: Oh?
04:09 imirkin: ls -l lib/gallium/nouveau_dri.so
04:10 imirkin: is the file there, and if so, is the timestamp on it from last time you built?
04:10 imirkin: if not, you have a problem :)
04:12 Satchelboi: Odd, I dont see a gallium folder in my lib
04:12 imirkin: find . -name nouveau_dri.so
04:12 imirkin: (assuming cwd is the mesa dir)
04:14 Satchelboi: Found it
04:16 Satchelboi: Erm, how do I open it and check exactly?
04:17 imirkin: open what?
04:18 Satchelboi: How do I check the timestamp of nouveau_dri.so ?
04:18 imirkin: ls -l
04:19 Satchelboi: It gave back a date of march 20th
04:19 Satchelboi: Funny, I just set this up 3 days ago
04:20 imirkin: so that means that file hasn't been built since.
04:20 imirkin: i'm guessing the file you found is installed by the system
04:21 Satchelboi: It must be. Odd spot too, it was in /usr/lib64/dri
04:21 imirkin: right, that's the system one
04:21 Satchelboi: That was the only place I found a file with that name
04:21 imirkin: (why is that an odd spot?)
04:22 imirkin: so as i expected, you're not building nouveau
04:22 Satchelboi: Just not where I expected it to be
04:23 Satchelboi: Im not sure why its more recent though. We spent a significant amount of time getting mesa to build the other day
04:23 Satchelboi: not more recent*
09:52 RSpliet: imirkin_: managed to test the tree?
09:52 RSpliet: imirkin ^
11:27 karolherbst_: imirkin: I have an idea how to move instructions out of loop bodies: if all sources of an instruction are in BBs different than the instruction, do smart things. First easy case: all are in the same -> move instruction at the end of the BB before any control flow instruction. Would I need to check anything here? Like fixed instructions or something like this?
11:35 dboyan_: karolherbst: I guess there is. For example vote or ballot.
11:38 pmoreau: karolherbst: Can’t you have multiple BBs inside the loop body?
11:39 pmoreau: s/inside/corresponding to
11:39 karolherbst: sure, if there is an if
11:40 pmoreau: then "if all sources of an instruction are in BBs different than the instruction, do smart things" wouldn’t work, depending on what smart things you are planning
11:41 karolherbst: well you could also have something like if (...) do = stuff(5); else things = stuff(5);
11:41 karolherbst: uhm, replace 5 with a or something
11:42 karolherbst: "a=....; if (...) do = stuff(a); else things = stuff(a);" => "a=...; temp = stuff(a); if (...) do = temp; else things = temp;"
11:43 karolherbst: pmoreau: there is also the situation where all sources are in different BBs
11:43 karolherbst: so sometimes you need to decide in which BB you actually are allowed to move the instruction
11:43 karolherbst: etc...
11:44 karolherbst: and then it has to be done before LocalCSE
11:45 karolherbst: I think if we continue from the start and follow the CFG, this way we wouldn't move anything deeper, because there will be always a phi hindering this
11:48 pmoreau: If you have `int res, i; while(true) { int foo = 0; if (i % 2 == 0) foo = bar1(i); else foo = bar2(i+1); res = foo * 2; ++i;}`, that would fit "if all sources of an instruction are in BBs different than the instruction" but you can’t move things out of the loop body.
11:50 karolherbst: I do this in SSA form
11:50 karolherbst: yours in semi-SSA form: https://gist.github.com/karolherbst/d058c35f121322d640ada934d6add2eb
11:51 karolherbst: res also gets a phi, but that's a differen thing
11:51 karolherbst: and i as well
11:54 karolherbst: mhh, how is the phi thing working for things like this? "int res; while(...) {res = ...};" ?
11:54 pmoreau: Good question
11:54 karolherbst: there will be a res = phi(...) after the loop, but I am not quite sure what the arguments would be
11:55 karolherbst: maybe res = phi(res_loop, res_before_loop);?
11:55 pmoreau: I am not sure there would be a phi
11:55 karolherbst: and before loop is not initiliazed?
11:55 karolherbst: there has to be a phi
11:55 pmoreau: If res was initialised sure, but since it is not
11:55 karolherbst: it doesn't have to be initiliazed
11:56 karolherbst: codegen complains though
11:56 karolherbst: maybe while(true) loops are handled differently anyway
11:56 karolherbst: anyway, if we assume that while(true) can be false, res can stay uninitliazed
11:56 karolherbst: even if it is true, it could have a break;
11:57 karolherbst: so yeah, there has to be a phi
11:57 karolherbst: there is even a operand for unitilized
11:57 karolherbst: OP_NOP?
11:58 karolherbst: and then you would get nop $r0; ... loop start $r1 = something ... loop end; phi $r2 $r0 $r1 // res ?
11:59 pmoreau: Maybe
12:00 karolherbst: anyway, I am sure there will be a phi, otherwise it would be silly, cause we would have run into this problem before already
12:01 karolherbst: but I am sure you could also just do a phi with one source, because phis are crazy anyway
13:09 imirkin: RSpliet: yeah, i tested your tree. the GT 240 was fine.
13:09 RSpliet: Cool, thanks
13:09 imirkin: or rather, as fine as it ever was
13:09 RSpliet: That's all I wanted to hear :-)
13:10 imirkin: i thought some errors were new, but apparently not - out-of-bounds bios reads
13:10 RSpliet: I'll send out a series of patches tonight for upstream, and slap your tested-by on... https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/7e12312886ef67d182b8d794118faf80bbe1b29c
13:11 imirkin: did i really test that?
13:11 imirkin: i didn't try reclocking... should i have?
13:11 RSpliet: No, this patch is only "hook up training pattern upload routine"
13:11 imirkin: ah ok
13:12 imirkin: well, i think you know the extent of my testing. feel free to stick my T-b on anything appropriate.
13:13 RSpliet: Yeah, was mostly concerned about sw-level regressions causing GDDR5 cards to be rejected by nouveau (as I observed on certain Fermi cards before adding the fallback pattern back in)
13:13 RSpliet: Seems it doesn't :-)
13:14 RSpliet: If during GDDR5 gt215 reclock development it turns out it needs a little bit of tweaking that's not disasterous, but it gives whoever picks it up a framework to work in
13:14 RSpliet: and enables re-use of the VBIOS part of training patterns among older gens
13:53 whompy: imirkin, skeggsb, fyi, looks like Gerd forgot that nouveau also may be interested in big endian discussions.
13:54 whompy: On dri-devel
14:01 Satchelboi: I'm a bit stuck on learning git send-email if anyone has a sec. I have the 4 files I modified and committed locally, and I have my email settings configured, but I can't for the life of me figure out how to actually send just the 4 modified files in it
14:03 karolherbst: Satchelboi: you have one commit right? git send-email --signoff -1 ... and your other stuff
14:03 karolherbst: if you have more commits, you need a different number
14:03 karolherbst: or base branch/commit whatever
14:03 Satchelboi: Just one commit, yeah
14:06 karolherbst: then -1 is fine
14:11 nyef: Satchelboi: I tend to format-patch into temporary directory, look things over, deal with a cover letter if necessary, and then send-email the directory.
14:12 Satchelboi: nyef: I just went with what karolherbst had said already. It was a very minor patch, so I'll take notes of what you do there for the next, more important one
14:13 nyef: Yeah, I figured that I might be a bit late with that.
14:16 RSpliet: https://regmedia.co.uk/2012/05/17/nvidia_kepler2_die_shot.jpg GK110 is quite a beauty looking at it like that...
14:16 Satchelboi: I'm honestly just hoping it sent at all haha, that was my first time with git email
14:17 Satchelboi: RSpliet: There aren't any very high res pics of that same die by chance, are there?
14:17 RSpliet: hah, such wishful thinking... no
14:30 ccaione: guys, there is a way to poke the GPIO status using the envytools?
14:31 RSpliet: ccaione: you can do the manual labour using nvapoke, but I'm quite sure there's some nva tools that do what you require
14:31 RSpliet: And if not, you can shoehorn your experiment into nva with a bit of manual labour... one of the things it doesn't do for you is figure out how the GPIO pins are routed, as that requires more comprehensive parsing of the VBIOS
14:33 ccaione: uhm, I'm a bit lost on this. I have a mmiotrace + demmio log with something like 'MMIO32 W 0x00d980 0x000000ff PGPIO+0x980 <= 0xff'. I'd like to reply this operation
14:33 ccaione: AFACT 0x00d980 is not directly mapped
14:36 RSpliet: it's an offset within the GPUs MMIO-space
14:37 RSpliet: nvapoke operates on these register offsets
14:38 ccaione: ok, how do I get the base? Since for other operations like 'MMIO32 W 0x619484 0x0000ff00 PDISPLAY.VGA.CR+0x84 <= 0xff00` I have the absolute address
14:39 RSpliet: no you don't
14:39 RSpliet: the GPU just has a very large GPIO window
14:40 RSpliet: *MMIO window
14:40 romulo: Hi, is it possible to use prime offloading on a desktop?
14:41 imirkin_: sure
14:42 romulo: Ok, now the problem :) I`m trying to use it but I get "nvc0_screen_create:794 - Base screen init failed: -19"
14:42 romulo: it is a gtx 1080
14:43 imirkin_: whompy: thanks
14:43 imirkin_: romulo: you need drm-next and an up-to-date mesa
14:44 dboyan_: and also a fresh linux-firmware
14:45 romulo: haha no idea how to get it all :)
14:45 imirkin_: romulo: drm-next = https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
14:47 romulo: linux-firmware?
14:47 imirkin_: it's a tree with all the public firmware
14:47 imirkin_: i'm sure you can use your superhuman searching powers to locate it
14:48 romulo: Yes, let me get air first :)
14:49 romulo: Well really thanks guys, I have something to start with now, If I get some doubt I will come back.
14:57 imirkin_: dboyan_: i'll probably look at your updated series tomorrow night
15:01 dboyan_: imirkin_: No hurry
15:11 imirkin_: ccaione: what are you trying to achieve btw?
15:11 imirkin_: a line in demmmio like
15:11 imirkin_: MMIO32 W 0x00d980 0x000000ff PGPIO+0x980 <= 0xff
15:12 ccaione: imirkin_: making the backlight control working on GP106
15:12 imirkin_: means "32-bit write at mmio address 0x00d980 with value 0x000000ff"
15:12 ccaione: imirkin_: yeah, I know, can I access 0x00d980 with nvapoke?
15:12 imirkin_: and then after that, demmio decodes it as "PGPIO+0x980 <= 0xff"
15:12 imirkin_: yep
15:12 imirkin_: nvapoke d980 ff
15:12 imirkin_: it maps the appropriate PCI bar, etc
15:12 ccaione: ok, then probably I'm missing all the GPIO initialization
15:13 imirkin_: tbh, i don't quite remember how the gpio stuff works
15:13 ccaione: I have the trace of the proprietary drivers when changing the backlight and I was trying to determine how that works
15:13 imirkin_: are you the guy who was having trouble with the backlight where blob didn't work either?
15:13 nyef: ... Can we access MMIO registers via echo | dd and dd | hexdump?
15:13 imirkin_: (sorry, my memory for people is ... weak.)
15:14 RSpliet: nyef: yes, but you'd just make your own life harder
15:14 ccaione: imirkin_: yes, but with 381.09 (beta) is working
15:14 imirkin_: dd where?
15:14 imirkin_: to /dev/mem or something?
15:14 ccaione: so I was trying to RE
15:14 imirkin_: ccaione: ah awesome. compare the 2 mmio traces of the blob
15:14 imirkin_: and diff them :)
15:14 ccaione: already doing :D
15:14 ccaione: an it seems that the driver is accessing the GPIOs to change the backlight
15:14 RSpliet: ccaione: did you get as far as to ask your VBIOS *which* of the GPIO lines is responsible for backlight?
15:14 nyef: imirkin_: dd to the appropriate sysfs file for the PCI device, of course.
15:15 RSpliet: we have the nvbios tool to decode the appropriate information from your VBIOS
15:15 imirkin_: nyef: oh, i didn't realize that pci resources were made available like that
15:15 ccaione: RSpliet: nope :) I'm a nouveau noob
15:15 RSpliet: okay, so what you can do is: 1) copy your vbios from /sys/kernel/debug/dri/0/vbios.rom when nouveau is enabled
15:15 RSpliet: 2) feed it into nvbios
15:15 RSpliet: 3) look for the GPIO table
15:16 imirkin_: RSpliet: ftr, nouveau does not properly operate his backlight. and neither did earlier blob versions. but i guess newer ones do.
15:16 ccaione: interesting, let's see what it spits out
15:16 imirkin_: RSpliet: and is it a backlight gpio usually? normally you just write to SOR_PWM somewhere
15:16 RSpliet: imirkin_: I figured, thanks. Just pointing at the tools
15:17 nyef: ... Can you "just" copy the vbios from /sys/bus/pci/devices/{whatever}/rom ?
15:17 ccaione: imirkin_: yeah, SOR is not working for GP106
15:17 RSpliet: imirkin_: last I remembered it was a GPIO, which was routed to a PWM.
15:17 imirkin_: right
15:17 nyef: Or does that not necessarily work?
15:17 ccaione: if I change the backlight and check the SOR nothing is changed
15:17 karolherbst: SOR is secured afaik
15:17 imirkin_: nyef: no, the rom is the option rom
15:17 ccaione: well, if I compare the mmio traces for two different backlight values what is changing is some GPIO registers
15:18 nyef: Okay, and the option rom may-or-may-not include the vbios, and even if it does it may not be immediately obvious where or how?
15:18 ccaione: that's why I guess the backlight is driven using PWM
15:18 imirkin_: nyef: which contains 16-bit real mode code to set things up. among other things, the vbios. it's sometimes == the vbios, but usually not.
15:18 RSpliet: ccaione: they probably change those regs to route it to the right PWM :-)
15:18 karolherbst: ccaione: there should be a GPIO inside the vbios indicating it
15:18 ccaione: haha well, that is a possibility. If I poke into SOR I get nothing, but if it is secured then I'm not sure anymore
15:19 ccaione: ok, let me check the bios
15:19 RSpliet: anyway, I'm semi-shooting in the dark to be honest. mupuf is probably your best most-awake source of information on GPIO-related matters
15:21 jamm: imirkin_, hakzsam : can read/write bars have > 6 instances? the control codes wiki mentions slots of 0-5 for maxwell but i see slot numbers higher than that in the control codes for the blitter shader
15:22 ccaione: GPIO 7: line 7 tag 0x21 [PANEL_BACKLIGHT_LEVEL] OUT DEF 0 HW gpio: normal SPEC_OUT 0x84 [SOR1_PANEL_BACKLIGHT_LEVEL]
15:22 hakzsam: jamm: 6 max
15:23 ccaione: ok, there is a way to poke SOR1 if it is secured? I tried to hookup GP106 into the current nouveau_backlight.c but no success.
15:23 RSpliet: ccaione: which kernel are you using btw?
15:23 jamm: hakzsam: i see wt bars like 0x8 and 0x10 used here.. maybe i'm missing something? https://cgit.freedesktop.org/~hakzsam/mesa/commit/?h=gm107_scheduler&id=21c1edcb99385d5aa986e64e8849e9dda5a8fa1b
15:23 hakzsam: jamm: it's a bitfield
15:23 ccaione: RSpliet: 4.10
15:24 karolherbst: ccaione: SOR is secured
15:24 jamm: hakzsam: ah, right
15:24 ccaione: so I guess I can forget to use nvapoke right?
15:24 jamm: makes sense now, thanks :)
15:24 hakzsam: np
15:25 karolherbst: ccaione: anyway, there is a reg to control the backlight. What backlight are you talking about by the way? Display for a mobile chip?
15:25 ccaione: karolherbst: yes
15:25 karolherbst: it might be that it just works but isn't wired up already
15:25 mupuf: ccaione: the backlight is supposed to be driven by PWM, at least on older platforms
15:26 mupuf: but I don't know of any platform that would not use it. What are you interested in?
15:26 ccaione: mupuf: I'm working on an asus laptop, and we need backlight control
15:26 karolherbst: ccaione: ohh wait, how is your display connected?
15:26 karolherbst: LVDS or eDP?
15:26 karolherbst: or something else
15:26 mupuf: sounds good, what GPU is that?
15:26 ccaione: eDP
15:26 karolherbst: ohhh
15:26 karolherbst: I found it
15:26 karolherbst: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_backlight.c#L283
15:26 karolherbst: guess what
15:27 mupuf: karolherbst: pascal missing? "D
15:27 ccaione: karolherbst: I tried to add V0_PASCAL there
15:27 ccaione: no luck
15:27 ccaione: the sysfs entry is created but not working
15:27 ccaione: at least on my setup
15:27 karolherbst: okay
15:27 karolherbst: at least something
15:27 karolherbst: something might have changed
15:27 ccaione: this is the bugreport https://bugs.freedesktop.org/show_bug.cgi?id=100446
15:28 karolherbst: check the nva3_set_intensity function
15:28 karolherbst: and check if you see anything related to that in the nvidia mmiotrace
15:29 ccaione: alright, let me see
15:30 nyef: Wait, wait... eDP and backlight? Is this a "can't set brightness" thing or a "doesn't resume from suspend" thing?
15:30 ccaione: nyef: can't set brightness
15:30 nyef: Ah, okay.
15:32 imirkin_: karolherbst: SOR is locked down? huh??
15:32 imirkin_: we couldn't operate any of the display stuff if that were the case
15:33 imirkin_: SOR is definitely *not* locked down
15:33 ccaione: karolherbst: so, I have the mmiotrace + demmio log when changing the backlight (something like `echo > tracemarker && xsetbacklight && echo > tracemarker` and I have to access to SOR
15:33 ccaione: s/to/no
15:34 ccaione: I only have two calls into SOR:
15:34 ccaione: [0] 2012.887629 MMIO32 W 0x61c880 0x00000a8c PDISPLAY.SOR[0x1].PWM_DIV <= 0xa8c
15:34 ccaione: [0] 2012.887630 MMIO32 W 0x61c884 0xc0000a8c PDISPLAY.SOR[0x1].PWM_CTL <= { DUTY = 0xa8c | CLOCK_SELECT = CRYSTAL | TRIGGER }
15:34 ccaione: not related to backlight
15:35 karolherbst: why not?
15:35 imirkin_: i thought that PWM stuff was specifically related to backlight
15:35 karolherbst: hum, maybe I was thinking about something else
15:35 karolherbst: maybe SOR1 was the LED thing or something...
15:35 karolherbst: where was the fan PWM?
15:35 imirkin_: nowhere near SOR's
15:35 imirkin_: *OR = output register = display things
15:37 karolherbst: k
15:37 karolherbst: then the LEDs where in SOR
15:38 karolherbst: ohhh
15:38 karolherbst: 0x61c880 and 0x61c884 are for the GPU LEDs
15:39 karolherbst: ccaione: do you have an entry inside the GPIO table for something like LOGO LED?
15:39 karolherbst: kind of useless on a laptop though, somehow
15:39 ccaione: nope
15:39 karolherbst: hmmmm
15:39 karolherbst: mupuf: ^^
15:39 ccaione: so, or == 1 is for leds?
15:40 imirkin_: that's not really how it works
15:40 karolherbst: not really
15:40 imirkin_: it'll be in the vbios
15:40 RSpliet: PWM is PWM... whether you use it for a useless LED or a backlight. You might need different characteristics for your PWM according to the application
15:40 RSpliet: but considering desktops don't require backlight control and laptops don't require shiny LEDs they could well re-use the same PWM
15:40 mattst88: https://bugs.freedesktop.org/show_bug.cgi?id=99202 -- works on in 1.0.12, but broken in 1.0.13. anyone able to take a look?
15:41 ccaione: ok, can I assume that somehow the backlight is controlled by PWM but without touching the SOR register?
15:41 karolherbst: no, change them
15:41 RSpliet: ccaione: unlikely considering how your VBIOS says the backlight GPIO is connected to a PWM in SOR
15:41 karolherbst: write stuff into 0x61c884
15:41 karolherbst: write 0xc0000000 into it :O
15:41 imirkin_: mattst88: the 2 users have totally different GPUs... one's a tesla, the other's a (late-model) kepler
15:42 mattst88: I'd ignore the "me too" report
15:42 imirkin_: mattst88: yeah. the issue is unrelated. that one is the "tesla's sometimes fuck up" issue, which we have absolutely no leads on solving.
15:42 mattst88: :(
15:42 mattst88: a bisect wouldn't help?
15:43 imirkin_: for the tesla issue? there's no good version. that's the "me too" guy.
15:43 imirkin_: the first guy's report is longer, hold on :)
15:43 ccaione: well, I see no SOR access in the mmio trace when changing the backlight O_O I'm confused
15:43 karolherbst: ccaione: did you write that stuff into the reg?
15:43 imirkin_: ccaione: look for GPIO 7 being written to
15:44 ccaione: karolherbst: yes, writing rubbish into SOR (at or == 1) I get nothing
15:44 karolherbst: you need the high bits
15:44 karolherbst: write 0xc0000000 into 0x61c884
15:44 karolherbst: and read it back
15:44 mupuf: hey, don't forget to set the commit bit, otherwise, you'll see no change at all
15:45 imirkin_: mattst88: i highly doubt the issue is related to a xf86-video-nouveau upgrade. if you look at his log, the MassEffect2.exe game does something bad (via the GL driver), which causes nouveau to fail at recovery.
15:45 mupuf: 0xc0000000 would work, and show absolutely nothing on the screen :D
15:45 karolherbst: that's the point
15:45 ccaione: karolherbst: ok, give me 4 min that my distro is screwed up and I need to reinstall
15:45 karolherbst: a more obvious change you can't get
15:45 mattst88: imirkin_: okay, thanks
15:45 karolherbst: ccaione: maybe write 0xc0000100
15:45 imirkin_: mattst88: also he says it also happens with xf86-video-nouveau 1.0.12, just "less often", which is pretty subjective
15:45 karolherbst: at least then you should see a bit
15:45 ccaione: yup
15:45 ccaione: I'll report asap
15:45 mattst88: imirkin_: yeah, I noticed that -- that's different than what he says in the gentoo bug
15:47 imirkin_: mattst88: the differences between 1.0.12 and .13 seem pretty minor from looking at the log. fixing some reverse prime stuff... some support for newer Xorg's...
15:48 mattst88: yeah, seems like he's wrong
15:48 imirkin_: mattst88: in general, xf86-video-nouveau is Bug Free (tm). unless you're doing that weird trapezoid drawing that no one does. but then it's very deterministically buggy.
15:48 imirkin_: and it's just visual bugs, not hang bugs
15:49 imirkin_: [there's a disagreement between the exa fallback logic and nouveau about ... something subtle. i forget.]
15:50 imirkin_: mattst88: whereas the nouveau GL driver is Bug Full (tm). so when in doubt, blame that :)
15:51 mattst88: good. I know who to blame then :)
15:51 imirkin_: [this is also why i recommend people use xf86-video-nouveau over -modesetting + glamor]
15:51 orbea: but then sometimes your bugs go away if you use modesetting :)
15:51 orbea: for example I no longer have those blackscreens after pm-suspend which had no error messages
15:52 Lyude: i just use wayland ;)
15:52 orbea: and openmw doesn't crash with DRI3 anymore
15:52 karolherbst: Lyude: is it stable enough now :O Would like to use wayland with my plasma5 desktop
15:53 Lyude: karolherbst: fedora 25 defaults to wayland so I'd say so, yeah
15:53 Lyude: I've been using it as my primary desktop since like, f23 now
15:53 Lyude: (gnome-shell)
15:53 karolherbst: mhh, well all the issues I had were plasma related anyway
15:53 karolherbst: I think
15:53 karolherbst: but maybe that's better now
15:54 RSpliet: Wayland + Pidgin has some nasty bugs
15:54 RSpliet: and I feel my system is slightly less stable than with Xorg
15:54 karolherbst: well, I will just try it out and blame Lyude, cause I've got told it is super stable now :O
15:54 imirkin_: Lyude: yeah, that's all unsupported (by me) :)
15:55 Lyude: hehe
15:55 orbea: xorg does what I want and as I dont use any fancy de I dont feel much pressure to change :)
15:56 imirkin_: RSpliet: turns out that alignment fix is needed on kepler too
15:56 imirkin_: RSpliet: although iirc you said that was not enough to fix the whole thing?
15:57 imirkin_:still needs to test pq's weston change...
15:57 imirkin_: -ENOTENOUGHTIME
15:57 ccaione: karolherbst: so, https://paste.fedoraproject.org/paste/mCgxNTtWpcE~0ZVfzpK5jV5M1UNdIGYhyRLivL9gydE=
15:57 ccaione: I see absolutely no difference in brightness
15:57 karolherbst: ccaione: try 0xc0000000 then
15:57 ccaione: same
15:58 karolherbst: mupuf: do I forget about something?
15:58 imirkin_: try gpio 7 directly.
15:58 ccaione: imirkin_: sorry, how?
15:58 karolherbst: isn't GPIO7 and output GPIO?
15:58 karolherbst: *an
15:59 imirkin_: it is...
16:00 imirkin_:is checking how to drive the gpio...
16:00 imirkin_: maybe that's not a thing?
16:00 karolherbst: not really
16:00 karolherbst: GPIOs only report on or off
16:00 karolherbst: so well
16:01 imirkin_: but for driving, you can also toggle them
16:01 imirkin_: but ... what you really want to do is configure the pwm...
16:01 karolherbst: yes
16:01 karolherbst: but usually those GPIOs are read only
16:01 karolherbst: or the PWM is just fast enough in overwriting the value
16:01 ccaione: another possibility is to replay the mmio trace step-by-step using nvammiotracereplay
16:01 imirkin_: ccaione: nvapeek d62c
16:02 ccaione: 0000d62c: 00006084
16:02 imirkin_:wonders...
16:02 imirkin_: nvapoke d62c 60ff
16:03 ccaione: nothing at all 0000d62c: 000060ff
16:03 imirkin_: ok, flip it back to the old value
16:03 ccaione: done :)
16:03 imirkin_: can you put up your (xz -9'd) mmiotrace somewhere?
16:03 imirkin_: the working one
16:04 karolherbst: force it off with a while loop :O
16:04 ccaione: imirkin_: the one including the backlight change?
16:04 imirkin_: yes.
16:04 imirkin_: did you insert MARK's into the trace?
16:04 ccaione: yeah
16:04 imirkin_: eeexcellent.
16:04 ccaione: but I need to catch another one
16:05 imirkin_: anyways, put up the traces and vbios somewhere
16:05 imirkin_: people here may be able to assist
16:05 ccaione: I'll do, tnx
16:07 karolherbst: Satchelboi: where did you send your mail to?
16:08 Satchelboi: karolherbst: It should have gone to the mesa dev mailing address
16:08 Satchelboi: From the patch submission page instructions
16:09 imirkin_: it'll take a few hours before someone approves the message
16:09 karolherbst: ohh right
16:09 karolherbst: Satchelboi: please subscribe
16:09 karolherbst: then nobody needs to approve it anymore I think
16:10 Satchelboi: I'm not sure how to subscribe to it actually
16:10 karolherbst: instructions are on the website
16:11 Satchelboi: Thankies
16:17 RSpliet: imirkin_: correct, the alignment fix didn't improve on pidign rendering
16:17 RSpliet: but did silence the warnings
16:17 imirkin_: ok. well, no warnings on kepler - just bad rendering
16:17 RSpliet: and +1 on ETIMEOUT, I should get a trace of all this...
16:18 RSpliet: unsurprised if Cairo turns out doing something illegal
16:18 imirkin_: actually a CTS test pointed out that we were perhaps doing something less-than-ideal with persisten buffers
16:18 RSpliet: but Wayland + Pidgin renders fine on G92
16:18 imirkin_: there's a fix on list
16:19 imirkin_: dunno if cairo uses those
16:19 RSpliet: less than ideal being... not persisting?
16:19 imirkin_: heh
16:20 imirkin_: no, just not waiting for previous rendering to complete when mapping
16:20 imirkin_: i thought that was what the spec wanted, but apparently not
16:21 RSpliet: ok. I'd be happy to have my fingers type that I can just give that patch a whirl and see what happens, but quite frankly prio 1 right now is sending some reclocking stuff off to the ML so Ben as something more to work with
16:21 karolherbst: Satchelboi: you need to configure your CC list though, cause I got no mail :p
16:21 Satchelboi: karolherbst: Yes I do, I completely forgot about that >.<
16:22 Satchelboi: I was already late on the patch so I kind of just pushed it out
16:24 karolherbst: no worries, just think about it the next time
16:25 Satchelboi: I'll configure it when I get back, Im sitting in a lecture right now and dont have ssh set up on this
16:28 imirkin_: RSpliet: yeah don't worry about that stuff.
16:28 imirkin_: RSpliet: your reclocking stuff -- way more useful ;)
16:37 karolherbst: I hope ben merges my reclocking patches soon, so that I can continue to work on the other patches. I really want to get the dynamic reclocking working this year :)
17:12 ccaione: imirkin_: https://bugs.freedesktop.org/show_bug.cgi?id=100446
17:18 imirkin_: cool. fwiw, we can run demmio all on our own too :)
17:50 nyef: ... Damn. Rebased to drm-next, and now something is broken. /-:
17:52 nyef: Only affects (some?) 3D modes.
18:07 imirkin_: nooo
18:14 nyef: So, the frame-packed modes flicker horribly, and the interlaced side-by-side-half modes are sortof dim at the top and can mess up some state somehow that needs to be reset by two or three "sane" modesets.
18:15 nyef: Also, things seem oddly flickery on modeset.
18:15 nyef: Might just be how igt is driving the modeset, though.
18:37 nyef: Okay, two parts. One is the interlace, the other is the frame-packing.
18:38 nyef: The frame-packing is probably related to the recent change to blankus in nv50_head_atomic_check_mode().
18:39 nyef: Interlace... I have no idea.
18:42 karolherbst: Satchelboi: can you send your patch to me directly once? Not that something else messed up and the ML doesn't get it. Thanks
18:43 nyef: Ohh... Maybe my other test hardware doesn't support interlaced 3D modes, and thus it was always broken and I never noticed.
18:44 Satchelboi: karolherbst: I'll send it as soon as I get back to my dorm in a bit
18:57 nyef: is m->h.active in terms of m->clock, or does it use some other unit?
18:58 imirkin_: nyef: didn't we say some stuff HAD to be supported? or was it conditional on other modes?
19:01 nyef: Good call, but it's conditional on the 3D_present bit in the EDID and also the presence/absence of 50Hz and 60Hz 2D formats.
19:02 nyef: Here's a fun one: Given an EDID that only reports 24Hz 2D modes, the 3D_present bit is meaningless.
19:04 nyef: ... Hunh. Right, the EDID for my other panel indicates that it does support the same 1920x1080i modes that are having touble here.
19:06 nyef: And I think I know what's going on with blankus for the FP modes.
19:18 nyef: Okay, the 32-bit extension on intermediate values for blankus looks to be kicking in even for the SBSH modes.
19:19 imirkin_: 64-bit all the way?
19:19 nyef: Well, yes, but not because of this.
19:20 nyef: Basically, because of the use of a 16-bit intermediate result, the value was way, way low.
19:20 nyef: Now with the 32-bit intermediate, it's a lot higher.
19:20 nyef: Though I note that the "underestimate" part is that it's scaling by m->h.active rather than mode->crtc_htotal.
19:22 nyef: Anyway, for 1920x1080i on this panel, the intermediate value before it gets chopped by the mode clock is (* (+ 1084 (- 1125 1094 2)) (+ 2008 (- 2200 2052)) 1000) => #x8f076ae0.
19:24 nyef: And there's a similar intermediate for the non-interlaced versions of the mode.
19:25 nyef: Now, a frame-packed mode has *twice* the advertised dot clock.
19:26 nyef: I'm not at all sure what that's going to end up doing, but it may yet overflow the 32-bit intermediate.
19:27 nyef: I think that my next step is to work out how all of the timing parameters fit together.
19:28 nyef: And not just "read an explanation of it", but actually work out the math.
19:30 nyef: Actually, no. My next step is to override the value to something stupidly low, like maybe fifteen, or even zero, and see if that clears things up.
19:36 nyef: I'm also thinking that igt testdisplay is rounding certain refresh rates *up*.
19:51 imirkin_: RSpliet: the most carefully laid plans... foiled by a simple typo
19:52 RSpliet: imirkin_: I didn't even abide to the law of preservation of tyops
19:53 nyef: And smacking m->v.blankus to 0 clears up all of the 3D mode issues.
19:54 karolherbst: RSpliet: my notification bar is DOSed by you :O
19:55 RSpliet: karolherbst: get a better notification bar
19:55 RSpliet: nyef: ... sorry! it's mandatory for flicker free clock changes on single-monitor set-ups though
19:55 karolherbst: it was fine before you send your patches :p
19:55 karolherbst: it's your fault (by the logic of many important people right now)
19:56 nyef: RSpliet: That's fair, I guess, but now I have to figure out how to make it work right for my case as well.
19:56 imirkin_: try dividing by 2?
19:57 nyef: RSpliet: Which, I suppose, also means that you may need to check whatever solution I come up with to make sure that it doesn't break whatever case you have.
19:57 nyef: imirkin_: Not until I actually understand what's going on.
19:57 RSpliet: nyef: As long as it exceeds 150/200 microseconds I'm sure it's fine
19:58 RSpliet: if it doesn't... we need someone to RE the linebuffer (NISO buffer) and implement code to configure that correctly so that we don't have to wait for vblank
19:59 RSpliet: but bear in mind that vblankus currently already is an underestimate, I'm sure we can come up with something tighter if need be
20:00 nyef: Is it an underestimate because it uses h.active instead of h.total as a scaling factor, or is there another reason?
20:00 RSpliet: nyef: tbh this is too long ago for me to remember, but that's one possibility
20:01 RSpliet: also: vblankus does not affect GF119+
20:01 nyef: Okay, fair enough.
20:01 nyef: ... Of course it doesn't. That would be convenient.
20:03 RSpliet: nyef: I thought that was a good thing. If it worked before ben fixed vblankus on gf119+, it should still work after
20:06 nyef: Sure, but it means that you need pre-GF119 hardware if you're going to mess with the mode parameters.
20:06 nyef: And probably GF119+ hardware as well.
20:07 nyef: ... And I may have to figure out how to strap a 24-inch panel and a desktop PC to my bicycle without using a trailer.
20:10 RSpliet: nyef: I recommend a back rack and some good bike bags
20:10 RSpliet: uncommon on mountainbikes unfortunately
20:12 nyef: I have front and back racks, a front basket, and some hopefully-good bike bags. But it's not an SFF desktop PC, and there's still the 24-inch panel, so I'm having trouble coming up with any reasonable way to secure everything. Or even just one of the items.
20:17 nyef: Ah well, with a bit of luck, I'll figure things out enough that I won't have to drag all of my HDMI 3D hardware into one place again.
20:17 nyef: On the other hand, this is going to push out the v3 patch series by at least another week.
20:47 nyef: ... Oh. Wow, nv50_head_atomic_check_mode() is going about what it's doing in a complicated way.
20:54 Satchelboi: I meant to send a test patch to one person, and accidentally sent it to the full mailing list. Whoops.
20:54 nyef: Satchelboi: For future reference? --dry-run is your friend.
20:54 Satchelboi: Very much noted
20:55 Satchelboi: Also removing mesa dev email from my automatic send, since that was not where I wanted it to go that time
21:04 nyef: Okay, I know how to get rid of the [hv]{back,front}p terms.
21:34 nyef: Okay, I've found a bug with computing blankus for interlaced modes.
21:34 nyef: And it might not even be one that I introduced in my local branch.
21:35 nyef: Yeah, that's definitely there.
21:37 nyef: For 1920x1080i on my big panel, mode->vtotal is 1125. Divide by two because of interlace is 562.5, but we're working with integers, so 562. Next, subtract mode->vdisplay, which is 1080, giving us -518. But we're in unsigned, so this becomes #xfffffdfa.
21:39 RSpliet: right... so vdisplay needs to be halved too because it's interlace
21:40 nyef: Still digging, will probably create patch in a bit.
21:43 nyef: ... And for the FP modes, m->v.active is 2250, but mode->vdisplay is 1080.
21:45 RSpliet: I suspect you can simply replace mode->vdisplay with m->v.synce
21:45 nyef: Mmm... Not quite the approach I'm taking.
21:46 nyef: Build and test time.
21:47 RSpliet: test is a tad tricky. Make sure to compare your calculated values and make sure they're lower or equal to those the blob sets...
21:47 RSpliet: for a variety of resolutions
21:48 RSpliet: (which lacking a large set of monitors I had to create a generous underestimate for back in the days :-D)
21:53 nyef: ... Much better. Over eighteen 3D modes, all showed something... But one looked like it was showing a 2D image.
21:54 RSpliet: What about regular monitors?
21:54 imirkin_: perhaps your eyes are revolting
21:54 imirkin_: rejecting the 3d effect
21:54 nyef: Given that I'm not wearing the 3D glasses?
21:55 nyef: ... And the return to 2D at the end resulted in a black screen until I restarted and stopped the test program (to force another mode change or two).
21:59 nyef: Tried again, and all of the 3D modes appeared correctly... and switching back to 2D failed again until I re-ran and interrupted the program twice.
21:59 nyef: Really not sure what's up with that.
22:02 nyef: Here's what I currently have, if anyone's up for a quick review: http://paste.lisp.org/display/341958#1
22:03 nyef: The blankus changes basically correspond to rescaling for interlace, for doublescan, and for frame packing.
22:06 RSpliet: nyef: it looks all right. Did you try capturing the values you actually set in all different modes?
22:06 nyef: No, I didn't.
22:07 RSpliet: I *think* you can nvapeek something in the 0x611 region to find out
22:08 nyef: With the exception of the blankus changes and the transition to using the crtcinfo derived timing parameters, these changes are all straight algebraic transforms.
22:09 nyef: Any behavioral change is very likely to be due to mode->vscan being set.
22:10 nyef: Or otherwise having a more-correct blankus, of course.
22:18 RSpliet: nyef: isn't line 8 unconditionally adjusting the mode for interlace and stereo - which it shouldn't do for 2D mode?
22:19 nyef: The call to drm_mode_set_crtcinfo()?
22:19 RSpliet: yes
22:19 nyef: It isn't. It's saying "do these adjustments IF the mode calls for them".
22:19 RSpliet: I found the description on 01.org rather ambiguous on this
22:20 nyef: So, for interlaced modes, halve the vertical. For frame-packing do the various things.
22:20 nyef: I found the code rather unambiguous on this.
22:20 nyef: drm_modes.c, drm_mode_set_crtcinfo().
22:20 RSpliet: then I stand corrected
22:32 nyef: I'll work up a proper patch for this in a bit.
22:35 karolherbst: hakzsam: imirkin_ had the idea to replace those checks with ISA checks, best with a new field inside the struct and as an enum
22:35 karolherbst: so you could do something like targ->getISA() == SM_30
22:35 karolherbst: or so
22:36 hakzsam: yeah, getISA() == SM_30 looks better than getChipset() == SM_30 :)
22:36 karolherbst: I know :)
22:37 hakzsam: if this can avoid confusion for some people, go ahead
22:37 nyef: ... getVLB() ? (-:
22:39 hakzsam: Satchelboi: --^
22:40 Satchelboi: I can go through and change those too. There are still some other constants I'd like to change as well, I just need to find the SMxx values for them
22:40 hakzsam: sgtm
22:59 mangix: well this is annoying. i got the monitor flickering issue again. anyone know what causes it?
23:00 nyef: "monitor flickering issue"?
23:02 mangix: while the screen is off, when i move the mouse or anything, screen comes back flickering with lines
23:02 nyef: Ah.
23:03 mangix: first thought is overheating but it doesn't feel warm at all
23:04 mangix: but when i leave it off for 5 minutes, it comes back to normal
23:05 mangix: *something* iis getting too hot
23:05 mangix: no idea what though
23:05 nyef: Too hot, or is it "just" a race condition with updating the cursor and exiting DPMS sleep?
23:07 mangix: doubt it
23:08 mangix: it persists in UEFI and Windows
23:21 nyef: RSpliet, imirkin_: Does this look reasonable? http://paste.lisp.org/display/341958#2
23:23 nyef: Hrm... And probably going to just push the HDMI 3D v3 patch series based on this tonight or tomorrow, so as to not lose any *more* time. /-:
23:27 nyef: RSpliet: I suppose that the "simple" version of the fix is to introduce a "vscan / ilace" term when calculating blankus.
23:28 nyef: I won't be doing that as a separate patch, since I really only see deleterious efects in 3D modes.