00:32 MrCooper: lilleman: your description sounds like tearing to me; please provide your current Xorg log file
00:32 MrCooper: FireBurn: can you bisect?
01:36 spstarr: hello bridgman :)
02:02 bridgman: hi spstarr
02:02 spstarr: evening
02:24 _ds_: One of the Rx cards looks like a worthwhile upgrade at some point this year… checking requirements – Mesa 12 + LLVM 3.8/3.9 + Linux 4.7 (radeon module) or closed-source + Linux 4.7 (amdgpu)?
02:26 MrCooper: _ds_: if you mean the upcoming Polaris GPUs, those will only be supported by the amdgpu kernel driver
02:27 _ds_: Yes, I do mean those. Do you mean amdgpu either way?
02:27 MrCooper: yep
02:28 _ds_: Useful information ☺
02:33 _ds_: Incidentally, running 12.0~rc3 with mareko's MSAA & pipelined upload patches applied. Working nicely.
06:43 FireBurn: MrCooper: I'll do it tonight
06:43 FireBurn: I'm pretty sure it was one of the 10 patches that was added yeseterday
06:43 mannerov: MrCooper: no news on https://bugzilla.kernel.org/show_bug.cgi?id=119631
06:43 mannerov: do you think the fix should work ?
07:14 lilleman: MrCooper: http://pastebin.com/jzxEWwr8
08:27 MrCooper: mannerov: async flips should be faster than copies, so I suspect it should depend on how the application manages the buffers rather than on the presentation interval per se
08:31 MrCooper: lilleman: are you using the default Unity session or a different one?
08:42 lilleman: MrCooper: I'm running in i3
08:42 MrCooper: I see; to avoid tearing, you either need to use an OpenGL compositing manager or enable Option "TearFree"
08:42 lilleman: MrCooper: Oh, that sounds fancy. Where do I do that? Or where do I begin? Is there any docs for it somewhere? :)
08:42 MrCooper: e.g. compton is a standalone OpenGL compositing manager
08:43 lilleman: MrCooper: Alright... so I'm going to have to use this "compton" so I need to read up on what it is and how to get it running
08:43 lilleman: I'll do that in a little while when my current meeting is over :)
08:43 vedranm: arsenm: Kabini GROMACS perf has improved again in my random manual testing; weekly benchmarks (though for Hawaii) coming this weekend
09:22 lilleman: MrCooper: It seems compton is not the answer for me, I think. My understanding is this is "just" a layer between the wm and the gfx driver
09:22 lilleman: The tearing I see affects everything, mouse, borders, video etc alike
09:23 lilleman: I also tried simply running "apt-get install compton" and then "compton" with no change. I do not know if this is sufficient, I do not understand these things really. :)
09:23 MrCooper: it shouldn't affect the HW cursor
09:24 MrCooper: not sure compton is configured optimally by default, but if it works well enough for you... :)
09:28 lilleman: it does affect the HW cursor (assuming it is HW and not software... but I guess I would notice that) and that is why I think it is "deeper"
09:29 lilleman: However, I have a more basic problem; I cannot find xorg.conf or any other X11 config file in ubuntu 16.04....
09:29 lilleman: Where do I modify radeon options?
09:30 MrCooper: there's no xorg.conf by default, you can create a minimal one with only Section "Device"
09:31 MrCooper: anything that affects the HW cursor will not be helped by compositing or TearFree
09:32 lilleman: Ah, so if I create a new /etc/X11/xorg.conf that will be read upon reboot?
09:33 lilleman: And thank you for the confirmation about compositing and hw cursor
09:38 MrCooper: yes, Xorg will read it the next time it starts (which probably doesn't require a reboot but just logging out)
09:43 lilleman: thanks
09:44 MrCooper: np
10:01 lilleman: In my Xorg.0.log I find this: "+hsync -vsync" on both my 4k modlines (60hz and 30hz). Maybe that is an issue? Could I manually add a modline to set +vsync as well?
10:14 MrCooper: those don't mean what I think you think they do :)
10:24 iive: lilleman: sorry to ask, would you describe your problem again?
11:26 philectro: salut
11:58 lilleman: iive: np, I'm having a horisontal flickering, mainly on my upper part of my screen.
11:58 iive: horizontal flickering?
11:59 lilleman: iive: I've had great help here to get my R9 390 to run 4k@60hz over DP1.2 on my Asus PB287Q - needed to use kernel 4.7-rc3
11:59 lilleman: yes, horisontal lines is moving up and down rapidly every now and then
12:00 iive: even when there is no motion on the desktop?
12:00 lilleman: yes, but less then
12:00 lilleman: If I have a lot of stuff going on, it seems to get worse
12:01 lilleman: Sometimes I see no flicker at all for a minute or two, and then its back. Its mostly minor enough for me to use my desktop though
12:02 iive: it does sound like monitor connection problem. DP1.2 stands for display port, doesn't it?
12:02 lilleman: Yes
12:02 lilleman: I do not get this issue on any other resolution and/or freq though
12:03 lilleman: On the other hand I have no other source to check with
12:03 lilleman: Maybe I should just leave it for now and test out with my new librem laptop when it arrives in a month or so
12:04 iive: is that the only output type on your video card, and only input type on your monitor?
12:07 lilleman: No, I have HDMI as well, but HDMI does not support 4k@60hz does it?
12:12 iive: lilleman: if i read wikipedia correctly, you can do it with hdmi 2.0 .
12:17 lilleman: I guess my monitor and/or the cable does not support HDMI2.0 in that case. I'll read up a bit on that, but it'll have to be later :/
12:20 bnieuwenhuizen: I don't think the GPU supports HDMI 2.0
12:26 AUser: I have a MSI R9 390, and I get the same tearing problem, it seems to be an issue with DPM, when I append radeon.dpm=0 to the kernel args, it goes away, however the clocks are locked low, if I force the dpm performance level to high, it also fixes it.
12:26 AUser: I have been trying to figure out if there was a proper way to fix it, but I haven't been able to find it.
12:27 AUser: seems to be something with the shader clock changes. as my memory clock stays the same on performance level auto.
12:27 iive: hum, makes sense
12:28 iive: the code does changes to the clocks during the vblank to avoid visible artifacts
12:29 iive: that would explain why the first lines are mostly affected.
12:36 bridgman: lilleman: you need something like compton --vsync <other stuff>
12:43 lilleman: AUser: Good to hear it relates to other R9 390 users as well, that means its probably not my cable and/or my exact monitor + card.
12:43 lilleman: bridgman: I dont think compton will help in this case, since this affects everything, including hw pointer
12:48 AUser: lilleman: try this, sudo sh -c "echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level"
12:49 AUser: Just to test if its the same as mine
13:02 lilleman: AUser: Dude, worked like a charm!
13:02 lilleman: AUser: What drawbacks does it have?
13:06 AUser: lilleman: well more power usage maybe more heat because its forced into high performance mode
13:27 mannerov: isn't there a middle as well ?
13:27 mannerov: low middle high
13:27 mannerov: perhaps middle would be a better fit
13:27 mannerov: AUser: ^^
13:31 AUser: mannerov: for the force variable only auto low and high
13:31 AUser: I guess you could switch it to low if you don't need the performance, I havent tried it.
13:34 mannerov: I think in the past there was something between low and high
13:35 AUser: power_profile has low mid high auto and default
13:36 AUser: but I can't write to it when dpm is enabled
13:43 mannerov: if you force the power profile, isn't it the same as disabling dpm ?
13:46 vedranm: the amount of hackery that fixes known problems found by users on #radeon continues to amaze me
13:46 vedranm: AUser: is there a bugzilla entry for this DPM on 390 problem?
13:47 AUser: mannerov: I am not sure
13:47 lilleman: AUser: I'll try the low value then I suppose as well
13:48 AUser: vedranm: https://bugs.freedesktop.org/show_bug.cgi?id=96326
13:48 Jester01: this kernel version is more stable, it went for 8 days, but when it locks up, it locks up for good
13:48 AUser: lilleman: let me know how it goes
13:48 Jester01:googles what caps+scroll lock blinking means
13:48 AUser: vedranm: I found it a few days ago while looking to fix this
13:49 _ds_:panics
13:50 Jester01: older kernel versions at least only locked up the graphics so I could still ssh in or sysrq and got logs
13:50 Jester01: but this ... just lock up and that's that
13:50 mannerov: the 390 consumes a lot of power, keeping high profile all time is going to be bad for electricity bill
13:51 mannerov: and for heat
13:51 AUser: mannerov: yeah, that's why I joined here, because I was hoping to help get the problem atleast known about more
13:55 _ds_: Jester01, maybe make use of netconsole?
13:55 Jester01:checks
13:56 _ds_: https://www.kernel.org/doc/Documentation/networking/netconsole.txt
13:59 agd5f: AUser, try my drm-next-4.8-wip tree and the latest firmware from linux-firmware it. make sure you have hawaii_k_smc.bin
14:13 lilleman: AUser: low made the issue come back
14:15 AUser: lilleman: so low seems to be the issue, what if you set it on auto, and run a graphic intensive app?
14:17 lilleman: It seems rhythmbox is the most aggressive wone, when I go to that app it flickers all over
14:18 lilleman: auto brings back the flickering
16:52 notadeveloper: ;)
17:08 arsenm: vedranm: i committed the pointer patches
17:53 MaDMaLKaV: agd5f: is the drm-next-4.8-wip-si branch deprecated , or just not seeing much activity recently?
17:54 MaDMaLKaV: seems strange the commit "drm/radeon: load different smc firmware on some SI variants" went to drm-next-4.8-wip and not the -si
17:55 MaDMaLKaV: (so tempted to add my card id to that patch and see if it explodes or something)
17:57 agd5f: MaDMaLKaV, not seeing much activity. the current code in that branch is not really usable for end users at the moment
17:57 agd5f: drm-next-4.8-wip-si is just for si support in amdgpu
17:57 agd5f: nothing to do with radeon
17:58 MaDMaLKaV: I know, but as I spotted it fails in a different way on my card, I will keep trying to but it from time to time
18:03 haagch: well, it's not working for anyone yet, so no point in trying it out
18:03 haagch: but someone is still working on it?
19:11 notadeveloper: is there a radeon with 2 gpus
19:11 notadeveloper: or is it firegl
19:15 agd5f: notadeveloper, yes
19:16 agd5f: most multi-GPU boards are consumer
20:18 speeder: there is a channel for AMDGPU?
20:24 vedranm: speeder: no, this is the one
20:25 speeder: ah
20:25 speeder: I see.
20:25 speeder: do anyone know if you can ask an AMD card why it is throttling? I do know AMDGPU supports PowerTune (according to wikipedia at least...)
20:26 vedranm: speeder: which card? which distro, application?
20:26 speeder: vedranm: doesn't it matter?
20:26 speeder: does*
20:26 vedranm: speeder: yes
20:26 speeder: the card uses GCN 1.2
20:27 speeder: or GCN 3
20:27 speeder: depending who you ask
20:27 vedranm: kernel? application?
20:28 speeder: vedranm: I want to know if the hardware supports it
20:28 vedranm: I don't know what is PowerTune, but PowerPlay is supported
20:30 speeder: PowerPlay is deprecated, from what I've saw, AMDGPU impelments PowerTune, and calls it PowerPlay on the source. (PowerTune replaces PowerPlay)
20:30 speeder: I want to know if when Power* is throttling, if there is a way to know why.
20:31 bnieuwenhuizen: AFAIK not really. You can look up the temperature and GPU load but no specific details on why exactly it throttles
20:37 speeder: :(
20:37 speeder: bnieuwenhuizen: thanks. this is what I suspected.
21:33 spstarr: hello
21:54 MaDMaLKaV: speeder, my card was famous for throttling without reason, people got it solved with bios update or upping the power limit 10% in the windows amd overclocking panel. no idea if there is an equivalent for that in linux
21:56 speeder: MaDMaLKaV: people on AMD forums are asking people to up power limit every time someone complain of card throttling, I suspect something is wrong with AMD throttling system, and wanted to investigate.
21:57 speeder: MaDMaLKaV: also I believe my model in particular has wrong TDP on the card BIOS. (Sapphire Nitro 380X) because it has lots of complaints, and when you leave power on default settings, it throttles down to the 380X reference PCB clock.
21:58 MaDMaLKaV: have you asked for a BIOS update on shappire forums?
22:00 MaDMaLKaV: some graphic card makers are famous for not publishing bios but providing there on demand. I suppose they don't want people to risk briking cards on a bad flash so they limit the flux of firmwares
22:01 MaDMaLKaV: techpowerup normally have a pretty complete collection of bios , that is a place to look at also
22:06 iive: MaDMaLKaV: have you upped the power limit with 10%
22:07 MaDMaLKaV: I solved my problem with bios upgrade years ago, when using windows. no throttling problems since then on windows or linux with fglrx.
22:14 MaDMaLKaV: oh cool, we got a patch for amdgpu to disable CUs. After latest tests I don't have much use for it but it is nice for future debugging on other savaged gpus
22:25 tstellar_: nha: http://reviews.llvm.org/D18714 has "Needs Revision" status, so I don't think it is showing up on the reviewers' todo list.
22:26 nha: ah, I didn't realize, thanks for the heads up
22:27 nha: hmm, how do I change that?
22:28 nha: it apparently didn't change automatically when I uploaded a new diff a long time ago, and I don't see anything on the web interface
22:30 tstellar_: nha: Yeah, I thought it was supposed to change when you uploaded a new patch.
22:30 nha: hmm, there are some inline comments I didn't explicitly set to Done
22:31 nha: arsenm added a new one, I'll take care of it (not today though)