00:17 rhyskidd: Lyude: you'll see the improved output on a pre locked-down-PMU gpu with the following kernel parameter nouveau.debug="VBIOS=trace,DEVINIT=trace"
00:18 rhyskidd: there might be one other reserved opcode in your trace on ~kepler, maxwell1 which is the 0xAA INIT_VDT ... doesn't impact nouveau, and i might get around to sending a patch for that one
00:18 rhyskidd: there's a documentation pr to envytools to support INIT_VDT in our vbios scanner
00:20 rhyskidd: vbios scanner = offline vbios parser ... might be the better way to describe it
02:01 imirkin: skeggsb: thoughts on the patch that kills the alpha overlay formats?
02:16 skeggsb: i haven't entirely decided yet tbh
02:16 imirkin: k
02:16 skeggsb: i mean, it makes some sense
02:16 imirkin: just wanted to make sure you had seen it
02:21 skeggsb: but, like, can you use the alpha part with source color keying?
02:22 skeggsb: HW has definitions for the bgrx versions, but they deliberately use the bgra versions in the class
02:25 imirkin: yeah
02:25 imirkin: well afaik the implication of an alpha format in kms is that it gets blended over the plane below it
02:26 imirkin: which we obviously don't do (and can't do, at least until gv100 where it's a bit less clear)
02:26 skeggsb: well, if that's the case, then yes, we definitely should i guess
02:26 imirkin: but perhaps i misunderstood that. would be good to double-check with someone in the know
02:26 skeggsb: i should probably also configure nvd that way too if that's the case...
02:27 skeggsb: assuming it was even implemented on gv100, there's a bunch of stuff in the class that caps bits say doesn't exist
02:27 imirkin: ah =/
02:27 imirkin: i guess we could use the VIC on MCP89 :)
02:28 imirkin: but seems a bit too special to worry about
02:28 skeggsb: sure, if someone gets bored on a rainy day and feels like implementing it, i'll pull the patch!
02:28 imirkin: more like a rainy month
02:28 skeggsb: true.. i'm pretty sure they'd need to write fw for that too
02:29 imirkin: i think drm/tegra has a VIC that's pretty similar one could use for inspiration
02:32 skeggsb: does modetest already have tests in such a way i could play with the alpha-blended requirement (assuming that's indeed what's supposed to happen) btw?
02:32 imirkin: sure
02:32 imirkin: just use an alpha-ful format for the plane overlay
02:32 imirkin: and make sure it's a pattern that has some alpha to it
02:32 skeggsb: i was more asking if it already uses such a pattern :P
02:32 imirkin: iirc smpte pattern does. not sure about tiles/et
02:33 imirkin: -Fsmpte,smpte
02:33 imirkin: (with my tree)
02:33 imirkin: i assume you have non-nvidia hw?
02:33 skeggsb: should probably get a solid answer about expected behaviour too
02:33 skeggsb: no, i don't actually
02:33 imirkin: then how will you check?
02:34 imirkin: or you mean for playing around with nvd?
02:34 skeggsb: yeah
02:34 imirkin: ok
02:34 skeggsb: oh, i guess i could switch to the intel gpu too.. i forget i have those
02:34 imirkin: so the tiles pattern, the top-right quarter is 50% alpha
02:34 imirkin: tiles is the default pattern for overlays
02:35 imirkin: i've never personally observed this, tbh
02:40 imirkin: skeggsb: hm, i may have lied.
02:41 imirkin: looks like there's a pixel blend mode one can set
02:42 imirkin: DRM_MODE_BLEND_*
02:42 imirkin: covered in drm_blend.c
02:43 imirkin: otoh...
02:43 imirkin: * @supported_modes: bitmask of supported modes, must include
02:43 imirkin: * BIT(DRM_MODE_BLEND_PREMULTI). Current DRM assumption is
02:43 imirkin: * that alpha is premultiplied, and old userspace can break if
02:43 imirkin: * the property defaults to anything else.
02:44 imirkin: otth, if you don't expose that blend mode property... you're off the hook? dunno.
03:14 imirkin: ok, so i think without that property, blend mode = premultiplied. with that property you can set it to whatever, but you must support premultiplied as part of it.
03:53 imirkin: skeggsb: as far as you know, it's ok to enable BASE_LUT and OUTPUT_LUT at the same time?
03:54 skeggsb: yeah, they do different things
03:54 imirkin: different?
03:54 skeggsb: well, same, but at different stages
03:54 imirkin: ;)
03:55 imirkin: pre-gf119, i don't see a middle stage though
03:55 imirkin: unless i'm not looking hard enough
03:55 skeggsb: middle stage?
03:55 imirkin: maybe the ofs_gain thing happens in the middle there?
03:55 imirkin: well, BASE_LUT -> x -> OUTPUT_LUT, no?
03:55 imirkin: (that was my assumption)
03:55 skeggsb: that's the x though?
03:55 imirkin: pre-GF119 there are no CSC properties
03:55 skeggsb: oh right
03:56 skeggsb: i thought that's what you meant, but yeah you're correct, they were a later addition
03:56 imirkin: but they dedicated hw for two whole lut's, so ... there must have been SOME use-case in mind
03:58 skeggsb: i don't know how exactly they use them, but output lut is generally for per-crtc gamma correction. base lut is necessary for indexed formats, not sure if they use them otherwise. degamma on later boards that support csc too, presumably
03:58 imirkin: we use the same lut for indexed formats
03:58 imirkin: (don't we?)
03:59 imirkin: oh. and we use the BASE_LUT
03:59 imirkin: heh
03:59 skeggsb: we put the gamma_lut onto the output lut, as we should. except when there's no degamma lut provided + indexed format, we steal the gamma lut it and use it as the base lut instead
03:59 skeggsb: (for compat with legacy interfaces)
03:59 imirkin: head507d_olut_set -- that always writes to BASE_LUT
04:00 skeggsb: hmm, why did i do that again...
04:00 skeggsb: i probably wrote the reason down somewhere in notes
04:00 imirkin: probably to make C8's life easier
04:01 imirkin: if C8 *has* to go through BASE_LUT
04:02 skeggsb: i'm trying to remember why core/base *both* have both of those on them
04:02 skeggsb: nvd is much saner in this regard
04:03 imirkin: i'll care when they release a GT 1630 :)
07:19 enyc:goes to read troubleshooting bugs and FAQ, as have a G72 / GeForce 7500 LE rev a1 that is blackscreen/pain on current linux, only in nvidia-304 driver, etc.
07:23 enyc: in theory this is something like NV46 which isn't listed in the FeatureMatrix page!
07:24 enyc: hrrm, probbaly NV40 anyhow
07:32 enyc: Will play fact-checking and troubleshooting later!
08:00 soalokin: question, how good is nv110 GeForce 750 ti with performance in gaming?
08:09 gnarface: soalokin: if you can get reclocking working, maybe good?
08:09 gnarface: https://nouveau.freedesktop.org/wiki/FeatureMatrix/
08:10 gnarface: good for nouveau
08:10 soalokin: i took a look there, dont understand much. is it hard to get reclocking working
08:11 gnarface: well if we're right about the card identity, then it seems as though power management is marked as "work in progress"
08:11 gnarface: which might mean there is some chance for at least manual reclocking if you have a new enough kernel build
08:11 gnarface: i'm not really sure about specifics, sorry
08:12 gnarface: i mean, i assume it's pretty simple to actually set, the hard part might be rebuilding the kernel
08:12 gnarface: i don't even know what you actually set though
08:12 gnarface: something in /sys probably
08:13 soalokin: Okay, thanks for the information=)
08:13 soalokin: i will further research
08:13 gnarface: no problem
09:01 pmoreau: soalokin: You should be able to reclock the card, since it is a first gen Maxwell. To reclock, do `echo XX > /sys/kernel/debug/dri/0/pstate` *as root*. To get the valid XX values, cat that same pstate file and look for the 03/07/0e/0f values; higher value means higher clock.
09:29 karolherbst: pmoreau: do you have a solution for this spirv extension stuff?
09:48 pmoreau: karolherbst: Inside spirv/invocation.cpp where we fail if the extension is not known?
09:49 karolherbst: yeah
09:51 pmoreau: Not really, but the code is actually wrong as it checks against OpenCL extensions rather than SPIR-V extensions. --"
09:53 karolherbst: yeah, that was my first impression as well
09:54 pmoreau: We probably need a `device::supported_spirv_extensions()` that is returned by the driver, and if the driver is using `spirv_to_nir_cl()`, that would be the list of extensions handled by `spirv_to_nir_cl()`.
09:55 pmoreau: If some extensions are not supported but can be ignored, they could still be allowed and just print a warning that this extension is ignored.
10:03 karolherbst: but then we have to know about this extension
10:03 karolherbst: also what about extensions added to core?
10:04 karolherbst: maybe we need to create a table similiar to the GL extension table stuff? mhhh
10:05 karolherbst: we should have something for vk as well
10:08 pmoreau: “but then we have to know about this extension” yes, we need to know about them anyway IMHO, as otherwise it’s hard to guess if it has an impact on correctness or not.
10:08 karolherbst: pmoreau: by definition listing extensions has 0 impact
10:09 karolherbst: I don't think any spirv extesnsion is allowed to change behaviour implicitly
10:09 karolherbst: it also has to come through new ops/caps/other stuff..
10:09 pmoreau: Ah, it’s only for validation purposes, and unlike an OpExtInstImport
10:09 pmoreau: ?
10:10 karolherbst: well the doc is saying for OpExtension: "Declare use of an extension to SPIR-V. This allows validation of additional instructions, tokens, semantics, etc."
10:10 karolherbst: ahh semantics means something like memory semantics and stuff
10:11 pmoreau: Also from the spec, Section 1.4: “Using the OpExtension instruction to require new semantics that must be supported. Such new semantics would come from an extension specification.”
10:11 karolherbst: sure
10:12 karolherbst: I am not 100% sure if an extension can change existing stuff
10:12 karolherbst: change without declaring something
10:12 karolherbst: like bindless_texture did for glsl
10:14 karolherbst: pmoreau: but at the same time, an OpCapability also doesn't do anything on its own either, it only allows certain stuff to be used
10:15 pmoreau: Right, yet those are usually checked.
10:16 pmoreau: Looking at `spirv_to_nir.c`: `SpvOpExtension` is ignored as considered to be debug info, but `SpvOpCapability` is checked and unhandled capabilities are errored out.
10:16 PaulePanter: https://paste.debian.net/1085991/
10:16 PaulePanter: WARNING: CPU: 3 PID: 21461 at drivers/gpu/drm/nouveau/nvif/vmm.c:71 nvif_vmm_put+0x6a/0x80 [nouveau]
10:16 PaulePanter: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108GL [Quadro 600] [10de:0df8] (rev a1)
10:16 karolherbst: PaulePanter: yeah... this happens from time to time, but we didn't figure out why
10:17 karolherbst: it seems to be harmless though
10:17 PaulePanter: karolherbst: Good to know. Thank you.
10:17 karolherbst: pmoreau: yeah... usually if a cap is declared, the shader also uses things this cap enables
10:18 karolherbst: but the point is, the client API is allowed to reject based on declared caps
10:18 karolherbst: do you know how that works in CL?
10:19 karolherbst: pmoreau: anyway, I think it's fine to ignore extensions and rely on cap validation
10:19 karolherbst: we might want to validate earlier though
10:21 pmoreau: I would assume that OpenCL can reject based on caps, for example if you have a SPIR-V using FLoat64 but doubles are not supported by the device (since Float64 is optional for OpenCL 2.2 for example).
10:22 karolherbst: yeah
10:23 karolherbst: I think fp16 is a better example though as it requires a spirv extension as well, no?
10:23 pmoreau: spirv-val should check that you don’t use features without using the corresponding cap, and if that cap was introduced by an extension, that the extension is declared. So if everything the extension introduces depends on a cap, and we check the cap, we should be fine.
10:24 karolherbst: well or new instructions or something
10:24 karolherbst: this can also happen
10:24 karolherbst: or a new memory model, etc...
10:24 karolherbst: but we should be able to catch everything inside spirv_to_nir
10:24 karolherbst: thing is, we only get to it when linking
10:24 karolherbst: is there some req in the spec _when_ we have to do this kind of validation?
10:25 pmoreau: I doubt fp16 requires SPIR-V changes: OpTypeFloat takes a width as argument.
10:25 karolherbst: ohh, it's no extension indeed
10:26 pmoreau: Float16 is a core capability
10:26 karolherbst: I thought it was
10:29 pmoreau: From the OpenCL 2.2 spec: “CL_INVALID_VALUE if the length-byte memory pointed to by il does not contain well-formed intermediate language input that can be consumed by the OpenCL runtime.”.
10:29 pmoreau: (when using clCreateProgramWithIL()`)
10:29 karolherbst: heh, "well-formed" is kind of a vague expression here
10:30 pmoreau: So I guess it does not have to be “valid”, just parseable, even if it doesn’t match the spec?
10:30 karolherbst: I guess so
10:30 pmoreau: But yes, “well-formed” is vague.
10:30 karolherbst: I think the issue is with entry points
10:30 karolherbst: imagine you have three copies of the same entry points, but each using less extensions as the previous one
10:30 karolherbst: and then you just select at runtime based on what the device is able to consume
10:31 karolherbst: you still want to accept that spir-v even if your runtime can't launch all the entry points
10:32 pmoreau: Hum
10:35 pmoreau: So that means you create 3 different clProgram, based on 3 different SPIR-V modules.
10:35 karolherbst: no, just one
10:35 pmoreau: OpCapability is for the whole module, not per entry point
10:35 karolherbst: but based on the caps of the device, I select a different entry point
10:35 karolherbst: mhhh
10:36 karolherbst: true
10:36 karolherbst: but I could use it for using different instructions
10:36 karolherbst: or memory model
10:36 karolherbst: or whatever
10:36 karolherbst: some things are per entry point
10:36 karolherbst: variables as well
10:36 pmoreau: memory model is also for the whole module ;-)
10:37 karolherbst: eh
10:37 pmoreau: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpMemoryModel
10:37 karolherbst: true
10:40 pmoreau: I need to get some lunch and start working. :-) TTYL
11:46 PaulePanter: karolherbst: What is the warning about?
11:46 PaulePanter: WARN_ON(nvif_object_mthd(&vmm->object, NVIF_VMM_V0_PUT,
11:46 PaulePanter: &(struct nvif_vmm_put_v0) {
11:46 PaulePanter: .addr = vma->addr,
11:46 PaulePanter: }, sizeof(struct nvif_vmm_put_v0)));
11:48 karolherbst: PaulePanter: I think it tries to remove some entry inside the MMU but it's already gone. It might be some race condition or userspace messing up or something
11:48 karolherbst: there could be even memory corruption, but nobody found anything yet
12:35 imirkin: skeggsb: my current plan is to map degamma_lut -> base_lut, gamma_lut -> output_lut, but if there's only a gamma_lut and a c8 format, then stick that into the base_lut
13:55 rhyskidd: karolherbst, mupuf_: you might be interested as I know you've looked around the voltage map curves https://github.com/envytools/envytools/pull/191
13:56 karolherbst: uff
13:57 rhyskidd: it took me a bit of staring at traces to figure that one out :)
13:57 karolherbst: yeah.. sorry
13:58 rhyskidd: no problem. happy it's fixed
14:04 imirkin_: danvet: btw, path of least resistance is definitely to keep messing with modetest. every incremental feature is not-a-lot-of-work. i realize this makes porting more painful in the end, but i don't think i have the time to do a proper port to igt. too much learning, and i expect i'll have to extend igt as well.
14:05 danvet: imirkin_, yeah no worries
14:05 danvet: I'll just keep pestering everyone about this, so maybe eventually we'll get to that glorious future :-)
14:05 imirkin_: if somebody did want to develop a replacement for modetest, i'd be happy to contribute thoughts about what makes modetest useful.
14:09 jamincollins: karolherbst: any luck on getting the off-and-on.patch merged?
14:15 karolherbst: jamincollins: skeggsb is working on a better solution for the secboot stuff
14:15 karolherbst: I still want to check something for the runpm patches though
14:16 jamincollins: I'd be happy to test them, the off-and-on.patch is the only way I can use my system at the moment
14:17 jamincollins: I also seem to be unable to get three simultaneous displays using the nouveau driver, any two work fine, but adding a third does interesting things
14:17 karolherbst: mhh, interesting
14:17 karolherbst: imirkin_ or Lyude might be able to help out with that
14:19 imirkin_: jamincollins: what GPU?
14:19 jamincollins: NVIDIA Corporation GP107GLM [Quadro P1000 Mobile] (rev a1)
14:20 jamincollins: the unit is a Lenovo P1
14:20 imirkin_: hm ok. well up to 4 displays should be supported there in theory.
14:20 jamincollins: yep
14:20 imirkin_: of the 3 displays, is it any two which work fine, and 3rd is always messed up?
14:20 imirkin_: or always the same monitor gets messed up?
14:20 imirkin_: also, are these all coming in via DP-MST?
14:21 imirkin_: actually, how about instead of guessing, why don't you just tell me what your setup is :)
14:21 imirkin_: what monitors, resolution, how they're connected, how you're turning them on, etc
14:22 jamincollins: any two monitors (internal plus one more) work fine. The two externals I'm trying to use are a BenQ GW2765 and and ASUS ZenScreen MB16AC
14:22 jamincollins: provided I only have two connected it doesn't matter which of the externals I use
14:23 jamincollins: but if I connect both externals, they are fine *if* the third is mirroring an existing display
14:23 jamincollins: the Asus is USB-C connected and powered, so it turns on when connected
14:24 jamincollins: the BenQ is connected via HDMI over a USB-C hub with an HDMI output. However, I've also tried it directly in the laptop's HDMI port
14:24 jamincollins: and configuration is done via xrandr through arandr
14:26 jamincollins: imirkin_: anything important I left out?
14:30 jamincollins: I'm happy to rearrange the connections and try anything you've got in mind
14:30 imirkin_: (sec)
14:36 imirkin_: ok, so ... we don't explicitly support USB-C. i suspect there's some magic which pipes this stuff through to DP.
14:36 imirkin_: what are the connector names on nouveau?
14:38 jamincollins: imirkin_: how would I get those? xrandr?
14:39 imirkin_: sure
14:39 jamincollins: eDP1 VIRTUAL1 eDP-1-2 HDMI-1-1 DP-1-1 DP-1-2
14:39 imirkin_: and you're trying to make which 3 work on nvidia?
14:41 jamincollins: eDP1 (laptop), DP-1-1 (Asus), DP-1-2 (BenQ)
14:41 imirkin_: eDP1 is on intel, not nvidia
14:42 jamincollins: ok
14:42 imirkin_: can you try the "modesetting" Xorg driver instead of "intel"?
14:43 jamincollins: right now, I have all three connected and mirroring each other, works fine
14:44 jamincollins: I can try it, will take me a bit (I think) as I believe I'll need to craft a config rather than letting Xorg auto config
14:46 jamincollins: ok, looks like simply removing the intel driver should be enough... bbiba
14:55 jamincollins: imirkin: xorg is still trying to load intel, so going to take me a bit
14:55 imirkin_: what xorg version do you have?
14:55 imirkin_: modeset should be built-in
14:55 imirkin_: starting with like 1.18
14:55 imirkin_: it had bugs though, i'd recommend 1.20
15:00 jamincollins: xorg v1.20.4
15:01 jamincollins: it's likely cruft on my install, it has been migrated through several different host systems
15:06 imirkin_: pastebin xorg log without intel installed? also it's conceivable that modeset is in a separate package in your distro
15:06 imirkin_: (it was originally, but then got merged into xserver. however to make life more difficult for users, distros like to split up upstream packages into multiple pieces.)
15:06 jamincollins: I'm running Arch, I believe it's in the xorg package
15:07 jamincollins: I'm making progress, found an old xorg stub directly referencing intel, now I have displays, just not the laptop display
15:09 imirkin_: pastebin xorg log
15:09 jamincollins: working on it
15:10 jamincollins: https://pastebin.com/BCJuYFsT
15:11 imirkin_: only nouveau is being picked up
15:11 jamincollins: yep
15:11 imirkin_: [ 1204.675] (**) | |-->Device "Nvidia card"
15:11 imirkin_: get rid of this.
15:12 imirkin_: your xorg config should have no devices.
15:12 jamincollins: improvement
15:13 jamincollins: ok, have all three connected, in mirror mode
15:14 jamincollins: moved two out to mirror each other (laptop and asus) positioned below BenQ... applied the change through arandr, the laptop and asus display fine, the BenQ is messed
15:14 imirkin_: describe "messed"
15:15 jamincollins: getting photo
15:15 imirkin_: and check to see if there's any info in dmesg
15:15 imirkin_: my guess is that this is not nvidia-related
15:15 imirkin_: but rather ddx-related
15:15 imirkin_: also ... how are these positioned?
15:15 imirkin_: and what are their resolutions?
15:15 imirkin_: (i don't mean physically, but logically in xrandr)
15:16 imirkin_: (if you just pastebin the output of "xrandr", that should get me all those answers)
15:17 jamincollins: benq is 2k 2560x1440 @0,0; the other two are 1920x1080 @0,1440
15:18 imirkin_: so ... in total you have a 3840x2520 area?
15:18 imirkin_: (with some holes)
15:22 jamincollins: https://cloud.asgardsrealm.net/index.php/s/kaT34xnYXrHa9WT
15:23 jamincollins: that sounds right, but that's not what is shown in xrandr output
15:24 jamincollins: Screen 0: minimum 320 x 200, current 2560 x 2520, maximum 8192 x 8192
15:25 imirkin_: perhaps you can just pastebin xrandr output? :)
15:25 jamincollins: sure, brb
15:26 imirkin_: ok, so the fact that the cursor displays fine tells me that the actual crtc/etc stuff is working just fine.
15:27 jamincollins: https://pastebin.com/7WCuqW7v
15:27 imirkin_: which means the issue is with image generation
15:27 imirkin_: right - that's with just one screen...
15:27 imirkin_: (one external screen)
15:27 jamincollins: sorry, pulled the asus to get the phone connected, one sec
15:28 imirkin_: lol
15:28 imirkin_: too many devices, not enough plugs!
15:28 jamincollins: indeed
15:28 jamincollins: https://pastebin.com/hGyNaBXz
15:28 jamincollins: there you go
15:28 imirkin_: that's with mirroring, yeah?
15:29 jamincollins: yes
15:29 imirkin_: and without mirroring? :)
15:29 jamincollins: and benq is current in the messed state with that mirroring
15:29 imirkin_: oh really?
15:29 jamincollins: yes
15:29 imirkin_: weird.
15:29 jamincollins: unless they all three mirror each other, it's messed
15:29 imirkin_: wwwwwweird.
15:29 imirkin_: what if you move it to not mirror?
15:30 imirkin_: e.g. xrandr --output DP-1-1 --right-of DP-1-2
15:31 jamincollins: trying to do that now, and things aren't looking good
15:31 jamincollins: once the benq gets messed up getting it back seems to require a reset of the x session/display
15:32 jamincollins: could this be related to off-and-on.patch?
15:33 jamincollins: I'll need to restart the xsession, one sec brb
15:35 jamincollins: needed a full system restart to bring the displays back
15:39 jamincollins: imirkin: https://pastebin.com/JJz8reVT <-- that's full three display mirror
15:39 imirkin_: and still doesn't work presumably?
15:40 imirkin_: er wait, no, you said that DOES work
15:40 jamincollins: currently the three display mirror works... to get the displays back I had to fully reboot the system
15:40 jamincollins: yes, three way mirror DOES work
15:40 imirkin_: is there anything in xorg log or dmesg when you get the failure?
15:40 jamincollins: let's see =)
15:42 jamincollins: attempting to move the laptop display below the benq
15:43 jamincollins: ok... that worked... pastebinning a new xrandr
15:43 jamincollins: https://pastebin.com/4YnpB0S5 <-- BenQ and Asus mirroring, laptop below
15:43 jamincollins: all displays are readable
15:44 jamincollins: attemping to move the Asus to mirror the laptop
15:45 jamincollins: Asus now mirrors the laptop, but the BenQ is back to the messed up display
15:46 jamincollins: near as I can tell the xorg only has modeset lines, but I'll pastebinit
15:46 jamincollins: https://pastebin.com/8C8S6K65
15:48 jamincollins: and nothing interesting in the dmesg or journalctl output, just cpu temps
15:55 imirkin_: i doubt it'll matter
15:55 imirkin_: but can you try uninstalling xf86-video-nouveau?
15:56 jamincollins: sure, but won't that disable the exteranl displays entirely?
15:56 imirkin_: no
15:56 imirkin_: they'll get driven by the generic modeset driver
15:56 imirkin_: since it's a secondary gpu, there's basically no advantage in doing it
15:57 jamincollins: ok, brb, rebooting
15:59 jamincollins: ok, back with three way mirror, and no nouveau driver installed
15:59 jamincollins: https://pastebin.com/QHzb09P8 <-- xorg log
16:00 jamincollins: moving just the asus display below the benq
16:00 jamincollins: seems to work
16:00 jamincollins: moving the laptop display to mirror the asus
16:00 jamincollins: also works
16:01 jamincollins: moving the asus to the right of the laptop
16:01 jamincollins: also works
16:01 jamincollins: have three distinct displays now
16:01 imirkin_: nice.
16:01 jamincollins: https://pastebin.com/ByY1Qtkz
16:01 imirkin_: i wonder what xf86-video-nouveau does (or doesn't do) to upset this situation
16:02 jamincollins: _almost_ *nice*... the main display shakes every few seconds
16:02 imirkin_: nail down your table
16:02 imirkin_: or move out of japan...
16:02 jamincollins: not that kind of shake
16:02 imirkin_: :)
16:02 jamincollins: it purely the image within the frame =)
16:03 imirkin_: did that happen before?
16:03 jamincollins: like a bad old TV broadcast... just not quite so pronounced
16:03 jamincollins: no
16:03 imirkin_: odd.
16:03 imirkin_: try plug/unplug that monitor
16:03 imirkin_: perhaps the link will retrain and it will be happy
16:04 jamincollins: done... let's see
16:04 jamincollins: seems good
16:05 jamincollins: who'd have thunk that removing the actual display drivers would fix it...
16:05 jamincollins: newp, it just twitched
16:05 jamincollins: :sigh:
16:06 jamincollins: xrandr has a crap ton of non-associated resolutions now
16:07 jamincollins: I think the issue before was that the screen size was not being adjusted
16:07 jamincollins: Screen 0: minimum 320 x 200, current 3840 x 2520, maximum 8192 x 8192
16:07 jamincollins: Screen 0: minimum 320 x 200, current 2560 x 2520, maximum 8192 x 8192
16:08 jamincollins: remember when you asked how big the display was (with some holes) I said that it sounded right, but wasn't what xrandr was showing
16:10 jamincollins: Screen 0: minimum 320 x 200, current 2560 x 2520, maximum 8192 x 8192 <-- current should have been 3840 x 2520
16:12 imirkin_: you had 2 screen overlapping each other
16:13 imirkin_: unfortunately i'm not sure how to diagnose DP-related quality issues.
16:13 imirkin_: i'd say "get a better cable", but the fact that it used to not do that is ... odd.
16:26 HdkR: Oh hey, overlapping screen things. I remember running in to that
16:27 karolherbst: uhm.. wait, wasn't there some patches to modesetting to lift this 8kx8k limit?
16:30 karolherbst: imirkin_: you are aware that the nouveau ddx isn't used here? Or did I miss something
16:31 imirkin_: it was previously.
16:31 karolherbst: ahh, I see
17:40 Lyude: imirkin_: when [and if someone else doesn't get to it first] I start working on nouveau igt stuff, I'll try to remember start off with coming up with a modetest equivalent then work my way up with adding support for the various nouveau stuff we'll need using that
17:41 imirkin_: Lyude: well, might not be the best use of time ... i use modetest as an interactive tool, essentially
17:42 imirkin_: basically i futz with parameters to figure out whether something works
17:42 imirkin_: and if not, i'll edit the source to try to make it work
17:43 imirkin_: and if so, then i try different parameters to see if i can make it not work
17:43 imirkin_: this is imperfect... i spent a good 10 minutes investigating why a "plain" overlay on top of the gradient didn't work...
17:43 imirkin_: turns out, because it's an optical illusion :)
17:44 imirkin_: (if you have a solid color on top of a gradient, then the solid color appears to be a gradient as well)
17:44 imirkin_: e.g. http://www.123opticalillusions.com/pages/gradient_illusion.php
17:45 imirkin_: was having trouble figuring out how a memset could go so wrong :)
17:45 imirkin_: but no. it's just my human brain that's broken.
17:53 Lyude: rhyskidd: jfyi, I'm also looking at your nvbios changes as well
17:54 Lyude: additionally-definitely seeing some interesting changes with the reset stuff in the devinit traces for this GPU
17:54 Lyude: (it's the GK110 in our vbios repo)
18:31 jamincollins: could the display shakes be related to bandwith or some other timing?
18:31 jamincollins: all three displays have slightly different refresh rates
19:33 imirkin_: jamincollins: it's clearly some weird clock thing ... but what, who knows
19:33 imirkin_: it's unlikely to do with diff displays having diff refresh rates
19:33 imirkin_: i'm guessing that the link training that nouveau does is somehow insufficient
19:33 imirkin_: it's weird that it didn't happen before though
19:39 jamincollins: but it's no longer using the nouveau xorg driver, you're talking about the kernel module?
19:40 imirkin_: the kernel module was always the thing driving it
19:46 jamincollins: imirkin_: thank you so much for getting me this far! I can't express how nice it is to have three displays working
19:47 imirkin_: if you have a different cable you can use for the wobbly display, i'd start with that
19:47 imirkin_: i'd also try a smaller resolution on that display, to see if that also "fixes" it
19:49 jamincollins: I've either gotten used to it, or it has decreased in frequency
20:07 imirkin_: perhaps your brain is flickering at the same frequency...
21:22 rhyskidd: Lyude: i saw your typo query re the envytools init_reset_*, was describing the interval of cores it's present on
21:22 rhyskidd: aim was to avoid the potential confusion around inclusive and exclusive intervals
21:22 Lyude: ahhh, maybe it's some lingo I'm just not used to seeing then :)
21:23 Lyude: if it's not a typo that's fine with me, I can resolve discussions + merge
21:24 rhyskidd: https://en.wikipedia.org/wiki/Interval_(mathematics)#Terminology
21:25 rhyskidd: i meant to write it that way, whether it is clear to a reader is a different thing ...
21:27 Lyude: oh hey I actually have heard of this now that I think about it
21:27 Lyude: either way it's up to you, I'm fine with this terminology
21:41 imirkin_: skeggsb: btw, i've confirmed with a test on i965/skl that overlay planes with alpha formats are supposed to pixel-blend. and it was confirmed in #dri-devel.
21:43 RSpliet: Lyude, rhyskidd: yeah mathematicians should know about this notation, and any compsci who followed calculus should have come across this as well ;-)
21:43 imirkin_: well, really any discussion of continuous math...
21:44 imirkin_: or even discrete, as we see here
21:44 Lyude: RSpliet: I'm all self taught so a lot of stuff like that goes over my head until I look it up :p
21:44 imirkin_: math is full of conventions. takes a while to figure all of them out.
21:44 RSpliet: Lyude: I went through uni and forgot so much of it that by now I consider myself de-facto self-taught as well :-P
21:45 Lyude: hehe
21:53 imirkin_: RSpliet: i use earplugs to prevent it from leaking out.
21:56 rhyskidd: hehe
21:56 RSpliet: imirkin_: Heard they double as excellent noise filters. I'm sure you have good use for that these days ;-)
22:04 imirkin_: for the first time i have noise-cancelling headphones
22:04 imirkin_: it's a very weird experience
23:10 HdkR: imirkin_: Which ones did you go for? I was forced to purchase some a bit over a year ago
23:19 imirkin_: just got a wireless set recently
23:19 imirkin_: playing with bluetooth and whatnot. not immensely impressed. got sennheiser ones.