01:09 Horizon_Brave: Hey everyone
01:16 mooch: hey
01:16 mooch: codimwk, are you mwk?
01:16 mooch: or what?
01:32 mwk: mooch: yeah
01:33 mooch2: ah
03:21 Horizon_Brave: When a company such a nVidia, (which would rarely happen, but bare with me) wants to provide you with an open source driver or atleast the firmware for some new hardware, do they post it on the somewhere public, like a github or the linux kernel site? or do they provide it to you guys directly and leave it up to you to share however you see fit?
03:34 airlied: Horizon_Brave: usually sent to linux-firmware for firmware
03:36 Horizon_Brave: airlied: ehh what do you mean sent to linux-firmware? would the company submit it the upstream kernel devs? is that what you mean?
03:42 airlied: Horizon_Brave: yes it's a mailing list to send git pull requesst to
03:46 Horizon_Brave: ah of course... the firmware/drivers would have to be started as a pull request from main first... then if tested and approved, they'd be rolled up in the next point release...
03:47 Horizon_Brave: as I understand it..
04:24 mangix: Horizon_Brave: depends on your distribution
04:24 mangix: linux-firmware is distributed separate from the kernel. usually...
05:06 Satchelboi: Hey, I'm about to submit a gsoc proposal for a Nouveau ticket that's been on the wait list. Anyone care to take a look?
06:04 dboyan_: Satchelboi: which topic?
09:47 karolherbst: Satchelboi: you are... late, the proposals are due today
09:47 karolherbst: dboyan_: I how you know that as well
09:48 karolherbst: April 3 16:00 UTC
09:48 karolherbst: still 6 hours, but still :p
09:49 karolherbst: Satchelboi: also before doing stuff like that, first ask the project, and second: find a mentor before writing the proposal. Maybe you talked with somebody before, but I don't know anything about that
10:10 mupuf: Satchelboi: you can still try to propose something as part of the EVoC
10:10 mupuf: so, go for it
10:10 mupuf: all is not lost
10:16 dboyan_: karolherbst: yeah, I know. it is too late atm. Also taking into account that people live in different timezones.
10:19 karolherbst: dboyan_: just wondering if your prposal is finished, cause you got 6 hours left :p
10:20 dboyan_: karolherbst: I've submitted the final version :)
10:20 karolherbst: \o/ yeah
10:21 karolherbst: dboyan_: I think the biggest task is to include something like dual issueing inside the scheduling
10:21 karolherbst: because this makes everything absurd and hard to predict
10:30 dboyan_: karolherbst: yeah, it's part of the whole problem, might take that into account.
10:30 dboyan_: gtg for a moment
10:31 karolherbst: dboyan_: I have a post RA pass to improve dual issueing by the way, might be helpful for your work
10:32 karolherbst: dboyan_: https://github.com/karolherbst/mesa/commit/50de61aa0ccf047f46998920715da55e0cac3433
11:24 karolherbst: mhhh here is a bug somewhere: https://gist.githubusercontent.com/karolherbst/e6de65e4051c6419c30f6352068d63fa/raw/6bc30808062434b28daca7af63258547cad4cae2/gistfile1.txt
11:25 karolherbst: ohh wait, the first set is part of the second opt...
11:26 karolherbst: and in SSA form now: https://gist.githubusercontent.com/karolherbst/e6de65e4051c6419c30f6352068d63fa/raw/754112c86e710bdfb12752ad69d1a70c6c221efc/gistfile1.txt
11:29 karolherbst: uhh, I think it didn't respect the "not" of the and
13:27 RSpliet: karolherbst: I'm not entirely sure if isCommutationLegal() is valid after RA
13:27 RSpliet: I have a strong suspicion that interfers() makes assumptions that are only true in SSA form ( https://github.com/karolherbst/mesa/blob/50de61aa0ccf047f46998920715da55e0cac3433/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp#L489 )
13:28 karolherbst: which one?
13:28 RSpliet: karolherbst: could you rephrase that question?
13:29 karolherbst: which assumptions
13:30 karolherbst: I don't see how interfers makes any sense while in RA
13:30 karolherbst: because it depends on the register id
13:30 karolherbst: which makes no sense in SSA
13:30 RSpliet: no I was going to backpeddle on my comment earlier
13:31 RSpliet: interfers only checks whether two registers overlap.
13:31 RSpliet: so is written for post-RA indeed
13:32 karolherbst: I know that my pass breaks a few things, but it works for most stuff. I am pretty sure I would have notice a more serious breakage earler :)
13:32 karolherbst: *earlier
13:32 RSpliet: but... okay, I'm not entirely convinced that it detects hazards if given two non-adjacent insns
13:33 karolherbst: it doesn'T indeed
13:33 karolherbst: but this is no problem
13:33 RSpliet: in your pass it might not be, but for dboyan_'s proper scheduling I hope it will be :-D
13:34 karolherbst: exactly
13:34 karolherbst: but he needs a different approach alltogether
13:36 RSpliet: Not entirely dissimilar. I expect 1) analysis to get the right type of dependency graph and a list of schedulable instructions, 2) logic to pick the best one from the list. Picking means following the dependency graph to add all insns to the list that are now schedulable
13:37 karolherbst: RSpliet: mhh, I am currently wondering if it makes sense to do the scheduling directly before RA
13:37 RSpliet: depends on your scheduling target
13:38 RSpliet: pre-RA for Kepler your aim would probably be to reduce the liveness range to 32 regs, and if impossible extend step by step
13:39 RSpliet: in combination with adjusting RA to use all the space you have (instead of always allocating the lowest reg numbers) this can be a powerful step to allow more freedom to a post-RA scheduler
13:41 RSpliet: powerful because it helps reduce "false dependencies" :-)
13:43 dboyan: sounds interesting.
13:43 RSpliet: dboyan: it is! That's why I'm so jealous of you taking on this job :-P
13:44 dboyan: karolherbst: I noticed your work, although I haven't read it carefully yet. I will read it some time in the following weeks to learn some of the ideas
13:56 karolherbst: at least piglit is fine now with my looped opts
14:00 karolherbst: those gprs increases are mostly due to RA being silly :/ https://github.com/karolherbst/mesa/commit/0847e273064e21e31c3bb7a6b1804151715d00bc
14:02 karolherbst: mhh idea: run algebraicopt _after_ modifierFolding, this should create some wonderfull bugs
14:05 nyef: Hunh. Where'd drm_crtc_get_hv_timing() go, and why?
14:05 karolherbst: drm-next update most likely
14:06 karolherbst: skeggsb pushed stuff again
14:06 nyef: Ah, renamed because it's actually a mode thing, not a crtc thing.
14:07 nyef: Easy enough fix on that front.
14:10 dboyan: karolherbst: Is it possible for a pass to report progress and loop until it "converges". i965 is doing things like that.
14:11 nyef: That's a pretty typical thing to do, the loop-until-converge-or-bailout. The catch is showing that it doesn't loop infinitely, and that your bailout makes sense.
14:11 karolherbst: dboyan: it's possible, but not globally, so you would have to add code to every tiny opt
14:12 karolherbst: but seriously
14:12 karolherbst: with a shader cache I don't really care about doing too much work
14:12 karolherbst: I could reduce the loop to only do a second run
14:12 karolherbst: the hird run is only needed for 5 shaders
14:12 nyef:has had to deal with a loop-until-converge that didn't, and that someone had added an ill-thought-out bailout to. "Rather than loop forever, let's quietly *miscompile* stuff!"
14:12 karolherbst: :(
14:13 karolherbst: the main issue in nouveau is, that AlgebraicOpt wasn't written with source modifiers in mind
14:13 karolherbst: but there are most of the important opts for the second run
14:14 karolherbst: dboyan: maybe counting instructions is enough
14:15 karolherbst: anyway, the downsides are quite small, so I don't really bother
14:16 karolherbst: dboyan: by the way, were you able to track down the shader cache issue within hitman?
14:17 dboyan: karolherbst: Not quite. I can see the issue even with only tgsi/glsl cache on, and it crashes at funny places.
14:18 karolherbst: dboyan: my issue is before a benchmark scene starts
14:18 dboyan: well, it only crashes in the middle of benchmark on my machine
14:18 karolherbst: is your rendering broken?
14:18 karolherbst: like the font is garbaged?
14:19 karolherbst: maybe they fixed it now... no clue
14:19 dboyan: sometimes, not often
14:19 karolherbst: okay, so it is
14:19 dboyan: I haven't had time to run it since the update though
14:20 karolherbst: okay
14:20 karolherbst: if you run a benchmark, you need to delete ~/.local/share/feral-interactive/HITMAN/VFS/User/hitman/profiledata.csv
14:20 karolherbst: and on my branch, I run it like this: MESA_VENDOR_OVERRIDE="ATI Technologies Inc." gdb --args ./HitmanPro -ao START_BENCHMARK true -ao BENCHMARK_SCENE_INDEX 1 -ao AUTO_QUIT_ENGINE 120 ConsoleCmd UI_ShowProfileData 1 ConsoleCmd EnableFPSLimiter 0 -ao FullScreen 0 ConsoleCmd settings_vsync 0 ConsoleCmd settings_SetHDR 0 -ao RESOLUTION 1280x720
14:21 dboyan: well, I have to start hitman within steam because it is not compatible with my native runtime
14:22 dboyan: but I managed to launch with gdb
14:22 karolherbst: what is the issue?
14:22 dboyan: soname mismatch
14:22 karolherbst: lib/libcurl.so is a big troublemaker
14:22 karolherbst: remove it
14:22 karolherbst: (this is true for all feral ported games)
14:29 nyef: ... And clean build after that. I guess next is the checkpatch results.
14:35 karolherbst: imirkin: I think the piglit arb_shader_image_load_store.invalid tests are affected by multi context issues
14:37 mupuf: karolherbst: how did the piglit runs fared on reator?
14:37 karolherbst: bad, the textureGather beased tests sometimes freeze the driver
14:37 karolherbst: but I have the same issue on my local machine as well
14:37 mupuf: ah, right
14:37 karolherbst: it just happened to not happen today
15:47 dboyan: strange, why clocklo/clockhi is not reset on shader launch on nouveau...
15:47 karolherbst: dboyan: is it for nvidia?
15:47 dboyan: yeah
15:47 imirkin: dboyan: probably some reg write
15:47 karolherbst: then figure out why ;) but I am sure they just push a few commands to the GPU
15:48 karolherbst: or set a flag or a reg write
15:48 imirkin: dboyan: or a shader header thing
15:48 imirkin: [which are documented, as it turns out]
15:49 karolherbst: imirkin: I will push out two fixes for algebraicOpt, which take care of a bit of mod handling. With this it should be possible to run modifier Folding _before_ Algebraic Opt without breaking stuff
15:49 karolherbst: at least piglit is happy
15:49 imirkin: k
15:50 dboyan: well, it is a compute shader
15:51 karolherbst: for other it works?
15:51 dboyan: haven't tested others
15:56 karolherbst: uhh crap, wrong author tags...
15:58 imirkin: slct can have mods? surprising.
15:58 karolherbst: NOT
15:58 karolherbst: afaik
15:58 karolherbst: but yeah, I hit this
15:58 imirkin: ah right. and neg presumably.
15:58 karolherbst: send out v2 with updated author :(
15:58 karolherbst: yeah, something like this
15:58 imirkin: (for the F/I versions, respectively)
15:59 nyef: Hrm. Okay, I think I have most of the checkpatch results figured into "stuff that I'm doing", "stuff that I'm not doing without a (possibly mild) fight", "stuff that I would be happy to do if someone can provide a reasonable way to do so", and "the fifteen fallthrough comments for one switch statement".
15:59 karolherbst: not quite sure I did the right thing within handleLOGOP, but at least reverseCondCode still resulted in piglit fails, and with both patches everything is fine
16:01 karolherbst: imirkin: to be honest, I would only merge the last patch _after branching for 18 or the 17.1 or wtvr
16:02 imirkin: nyef: fyi, being "checkpatch clean" isn't a hard requirement
16:02 imirkin: some of the things it proposes to do are asinine
16:03 nyef: imirkin: I figured as much, and yes, my counterargument for a number of things are "this is how the original code already was".
16:03 dboyan: btw, what is the 0xf in gm107 asm "mov $r2 $r6 0xf"?
16:03 karolherbst: immediate
16:03 imirkin: nyef: it's mostly there to help newbies not mix up spaces and tabs
16:03 imirkin: dboyan: it's the lanemask
16:04 imirkin: dboyan: you can make it so that the move is only effective to a specific lane (out of 4 lanes)
16:04 imirkin: this is useful for specifying explicit derivatives (i.e. textureGrad)
16:04 nyef: In one case, my counterargument is "the only angle for improving this situation is to reduce this twelve-character variable name by at least five, and preferably twelve characters".
16:04 dboyan: oh i see
16:04 imirkin: for the variants of textureGrad that aren't directly supported by the hw op
16:05 nyef: (Or to introduce a temporary variable to hold a pointer to a member of a union, that gets used precisely once.)
16:05 imirkin: (cubes, shadow compares, 3d textures, probably other oddnesses i'm forgetting)
16:05 imirkin: nyef: don't get obsessed with addressing every one of its suggestions.
16:06 imirkin: that way lies unreadable code
16:06 nyef: Yeah, just reconsidering my plan of action now.
16:06 karolherbst: if something gets unreadable -> bad
16:07 imirkin: checkpatch doesn't check for unreadable :)
16:07 imirkin: it checks for regexes
16:07 imirkin: hard to write a regex for "readability"
16:07 nyef: One commit actually does need a few fixes, due to typos, but otherwise I might just post as having been rebased and wait for further feedback.
16:07 imirkin: much easier to write a regex for "you are using spaces instead of tabs"
16:10 dboyan: imirkin: I guess I only need 0xf there, but i was just curious about gm107 asm.
16:11 dboyan: I learned blob's ARB_shader_ballot on my pascal machine, and the gm107 asm was quite hard to understand from the first look
16:15 imirkin: dboyan: it's the same as the (l0) stuff in envydis's gk110/gf100 asm
16:15 imirkin: the gm107 envydis stuff is modeled after nvdisasm
16:16 imirkin: whereas i think gf100/gk110 were more modeled after ptx
16:17 dboyan: yeah, now i understand it better after some reading. And i finally know what .S flag really means
16:18 imirkin: S = join :)
16:18 imirkin: aka sync
16:18 imirkin: on gm107 iirc it's a separate op, no more flag
16:19 dboyan: seems so
16:32 Marex: Hi, I ran into https://bugs.freedesktop.org/show_bug.cgi?id=100293
16:32 Marex: I had no problem with xserver 1.18, but after updating to 1.19 I got this crash
16:32 Marex: any ideas ?
16:36 Marex: hm, updating the xorg nouveau component to 1.0.14 doesn't help either
16:38 orbea: Marex: how about modesetting instead of the nouveau ddx?
16:38 orbea: does that work?
16:39 orbea: (guess)
16:40 Marex: orbea: I can try ...
16:40 Marex: orbea: but I'd rather like to see a patch, not a workaround
16:42 Marex: no, different crash tho
16:43 orbea: oh well
16:43 orbea: least we now know its not that...
16:43 Marex: wait, ignore what I said, I didn't do the correct test
16:43 Marex: I have two cards, so I need to change that on both
16:44 orbea: heh
16:44 Marex: btw for future reference, do they make a card with four outputs but single GPU already ?
16:45 karolherbst: Marex: you don't need xinerama for that anymore though
16:45 Marex: karolherbst: for what ? two GPUs, four pivoted screens in one huge canvas ?
16:45 orbea: my limited understanding is that not everyone wants to maintain, so ime at least a few bugs went away with modesetting. :)
16:46 orbea: *maintain the nouveau ddx
16:46 karolherbst: Marex: exactly
16:46 karolherbst: Marex: it can be done through xrandr now
16:46 Marex: karolherbst: I'd just be happy to have a working system again :)
16:46 karolherbst: xinerama is basically dead, because nobody wants to maintain it
16:46 Marex: karolherbst: ha
16:46 Marex: karolherbst: yeah, well, it was the only thing that worked before ...
16:46 karolherbst: and it is more pain than xrandr
16:46 Marex: karolherbst: took me a long time to get this working at all
16:46 karolherbst: true
16:47 karolherbst: Marex: what you want to do is something like "reverse prime"
16:48 Marex: karolherbst: so one GPU rendering, the other just displaying, huh
16:48 nyef: Is a "reverse prime" something like a "highly composite number"?
16:48 Marex: karolherbst: I have two identical GPUs, but I don't really care if it's in prime setup
16:49 karolherbst: yeah
16:50 karolherbst: well, nouveau can't do SLI anyway
16:50 Marex: I don't care about hte 3D stuff, I mostly use command line
16:53 Marex: karolherbst: ha, the xrandr approach looks almost working
16:53 Marex: karolherbst: good idea :)
16:53 karolherbst: good thing about it: you don't need any Xorg configs
16:54 karolherbst: what GPUs do you have by the way?
16:57 Marex: karolherbst: right
16:58 Marex: karolherbst: sec
17:00 Marex: karolherbst: NVIDIA Corporation G98 [Quadro NVS 450] (rev a1)
17:01 karolherbst: Marex: to get a smoother esperience, it might make sense to change the pstates of both GPUs. The rendered images are coopied over the PCIe bus and doubling the bandwith is most likely a good idea
17:02 Marex: hm, thus far, I only get three monitors working :/
17:02 Marex: the fourth one is in sleep state now
17:11 Marex: karolherbst: jupp, one monitor goes to sleep if I use Xrandr
17:12 Marex: karolherbst: it's like the monitor is part of the canvas, but it's not enabled ... why ?
17:17 imirkin_: Marex: kepler and newer GPUs can support 4 simultaneous heads
17:17 imirkin_: Marex: also most semi-recent AMD gpu's can do a lot of heads too... up to 6 iirc
17:18 Marex: imirkin_: hm that's great :)
17:18 Marex: imirkin_: I guess none of those have pasive cooling ?
17:19 Marex: btw I'd still prefer to get back my four monitor setup just like I had it before this crappy xserver 1.19 "upgrade"
17:19 imirkin_: highly unlikely
17:20 imirkin_: Marex: have you already posted your xorg config and logs somewhere?
17:21 Marex: imirkin_: well since the upgrade, my Xorg is no longer generating logs (probably systemd gobbles them, great :( )
17:21 imirkin_: the logs are somewhere
17:21 imirkin_: you just need to find them
17:21 Marex: imirkin_: the bug I see is the same as https://bugs.freedesktop.org/show_bug.cgi?id=100293
17:21 karolherbst: Marex: I think you can disable that going iinto sleep via xrandr somwhow
17:21 karolherbst: Marex: but I guess everything is rendered and displayed just fine?
17:22 imirkin_: Marex: really? in RRCrtcGammaSetSize?
17:22 Marex: imirkin_: if I use xinerama, yes
17:22 imirkin_: Marex: right, i just pushed a patch from manio to disable uevents when randr is off (e.g. when xinerama is used)
17:22 imirkin_: Marex: grab xf86-video-nouveau from git
17:23 imirkin_: (he's also the reporter of that issue as well)
17:24 Marex: imirkin_: ah ok, gotta figure out how to do that in debian ... I don't want to install random files into the FS
17:25 Marex: imirkin_: can I cherry-pick a patch to 1.0.14 ?
17:25 Marex: imirkin_: if so, which one ?
17:26 Marex: imirkin_: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=e9418e434311336e905b70553a5ed740838d90ad ?
17:32 Marex: imirkin_: with that patch, X11 crashes :)
17:35 Marex: imirkin_: here's the crash ... https://pastebin.com/McE4W7DY
17:36 Marex: imirkin_: here's Xorg conf ... https://pastebin.com/2tSryrE2
17:46 nyef: Hrm. In the last patch in my HDMI 3D series, should I rewrite so that the binary operators next to the linebreaks in the if condition are before the linebreak instead of after?
17:48 Marex: oh well, since after this "upgrade" my xserver crashes and my workstation is unusable, and with xrandr I can only use 3 monitors out of 4 , I guess I'll have to live with the later ...
17:49 Marex: it's better than not being able to do any useful work, but I really hate upgrading recently , every single time I loose functionality
17:50 Marex: sigh :(
17:50 Marex: the linux desktop experience is becoming worse every year
17:51 karolherbst: as I said: nobody wants to maintain xinerama anymore
17:51 Marex: karolherbst: well I use Xrandr now, that at least doesn't crash, but it does NOT WORK EITHER
17:51 karolherbst: because the display turns off?
17:51 Marex: yes
17:52 Marex: I suspect it might be because the canvas is too big
17:52 karolherbst: I think it is a silly issue
17:52 Marex: well I had no issue before I upgraded to xserver 1.19 :)
17:52 Marex: karolherbst: any ideas ?
17:53 imirkin_: Marex: i strongly suspect that manio's patch will fix things for you
17:53 karolherbst: you can turn off that "turn off displays on inactivity"
17:53 nyef: Does it work if you set the fourth display to clone one of the others, rather than being its own chunk of "screen" space?
17:53 imirkin_: Marex: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau
17:53 nyef: (Yes, not useful, but might suggest something that is.)
17:53 Marex: imirkin_: I tested it, it does not
17:54 Marex: karolherbst: well, setting mode to 1920x1080 makes all four monitors work
17:54 imirkin_: Marex: surprising, since randr should be off in the xinerama case
17:54 Marex: karolherbst: setting mode to (native) 2560x1440 only works with three monitors
17:55 karolherbst: hum, interesting
17:55 karolherbst: Marex: you could create a new bug, and I am sure this one might be fixed faster than the other one
17:57 Marex: karolherbst: how do I debug this issue ?
17:58 Marex: imirkin_: even if I use rotated screens ?
18:00 Marex: imirkin_: well, with that patch the Xserver crashes ... and it seems randr is enabled
18:03 karolherbst: Marex: you couold turn off this auto turn off display feature and see if this is better
18:03 Marex: ugh, with this xrandr typing into console is unusable and slow as crap
18:04 Marex: karolherbst: which feature ?
18:04 karolherbst: suspend displays, I have no idea how to turn it off, it seems to be always off for me
18:04 Marex: with this Xrandr, the system is really noticably less usable
18:05 karolherbst: try upclocking the GPUs
18:05 nyef: Rebased 3D stuff seems to work fine, at least.
18:05 Marex: on the screens attached to the second GPU, I see noticable slowdown when typing to console
18:05 Marex: karolherbst: how ?
18:05 karolherbst: xinerama does no offloading, so each GPU renders it's own part with all the drawbacks and positive effects
18:05 Marex: karolherbst: worked for me without this "upclocking" before ...
18:05 karolherbst: Marex: you should have two files with that pattern: /sys/kernel/debug/dri/*/pstate
18:06 karolherbst: the last line is the current state
18:07 Marex: everything is maxed out
18:07 karolherbst: is the last line like the second last one?
18:07 Marex: yes
18:07 karolherbst: mhh, could you still echo the prefix of the second last line into the pstate files?
18:07 karolherbst: I guess something is wrong related to the pcie speeds still
18:09 Marex: karolherbst: hm interesting, that worked
18:09 karolherbst: so everything is smoother now?
18:09 Marex: karolherbst: no, typing into console is still crap, but at least I can get four screens
18:09 karolherbst: ohh
18:09 karolherbst: copying 2x 2560x1440 displays over the PCIe bus isn't exactly cheap though
18:10 karolherbst: that's the problem with the reverse prime way
18:10 Marex: well, do you have a better idea how to support this configuration ?
18:10 Marex: xinerama worked
18:11 karolherbst: Marex: what LnkSta is reported for both nvidia cards in "lspci -vv"
18:11 karolherbst: let me calculate something
18:13 karolherbst: if I don't miss anything the 4 GB/s for pcie v2 and x8 width should be enough
18:13 karolherbst: you need 1.23 GB/s but got 4 GB/s
18:14 karolherbst: maybe we are just not efficient enough though, so in the end xinerama is your best option for now
18:14 Marex: karolherbst: 5GT/s x16 into the PCIe switch, 2x 2.5GT/s x4 from it (to each GPU)
18:15 karolherbst: the GPUs are connected via x4 width and only 2.5 GT/s?
18:15 Marex: to the switch, yes
18:15 karolherbst: uh
18:15 karolherbst: okay, that is just 1 GB/s
18:16 Marex: that sounds a bit weird, since the switch has 5GT/s x16 upstream
18:16 karolherbst: yeah, it does
18:16 karolherbst: what does lspci -vv report?
18:16 Marex: that's from the lnksta
18:16 karolherbst: mhhh
18:16 karolherbst: okay
18:16 Marex: I rebooted the machine, sec
18:17 karolherbst: could be my fault, wait a second
18:17 Marex: 2.5GT/s x4 is roughly 8 GB/s
18:17 karolherbst: you miss that the former is in bits
18:17 Marex: err, right
18:17 karolherbst: and then you get only 8/10
18:17 karolherbst: cause of protocol
18:17 Marex: so yes, 1 GiB/s
18:18 imirkin_: Marex: xinerama should work =/
18:18 karolherbst: yeah
18:18 karolherbst: Marex: could you boot with nouveau.debug=pci=trace, switch the pstate as before and give me "dmesg | grep nouveau" ?
18:18 karolherbst: I bet that we missdetect something
18:18 imirkin_: Marex: imho xinerama is definitely the best thing assuming you don't need dynamic monitor configuration or direct rendering.
18:18 imirkin_: [most people like direct rendering]
18:20 Marex: imirkin_: I really just need terminal :)
18:20 karolherbst: start two X servers! :p
18:20 imirkin_: no, i get it - i'm on board with the whole "don't adopt new shit for the sake of new shit" rule
18:21 Marex: pretty much
18:21 imirkin_: however, as it happens, most of the graphics community does like new and shiny.
18:21 Marex: I dont mind ... I don't even mind switching, but if it only has downsides for me ? I do mind that ...
18:21 karolherbst: yeah
18:22 imirkin_: either way ... what are your capabilities? i mean - can you read + write + debug code? or not?
18:22 karolherbst: I guess we mess up here in several places
18:22 karolherbst: Marex: I still would like to see the debug output of nouveau. Maybe I can figure something out and fix that pcie speed issue somehow
18:22 Marex: imirkin_: around 400 patches in the mainline kernel , over 1k in mainline u-boot etc ...
18:22 karolherbst: I guess the switch adds a layer we can't handle right
18:22 imirkin_: Marex: documentation patches i assume? :p
18:23 Marex: imirkin_: whitespace cleanup
18:23 imirkin_: heh
18:24 imirkin_: Marex: either way, you basically need to make your own xserver build and figure out wtf is going on
18:24 imirkin_: Marex: i would highly recommend using xf86-video-nouveau from git
18:24 imirkin_: since it has manio's patch, which should affect your situation. but perhaps not fix it, since your issue isn't with events.
18:24 Marex: I think I have a patch in there for this screwed up setup already too ...
18:24 Marex: imirkin_: I am running with that patch , I said that already
18:25 imirkin_: it sounds like xf86HandleColormaps is calling something in randr that it shouldn't be.
18:25 Marex: imirkin_: I use 1.0.14 + that patch now, doesn't help
18:25 imirkin_: right, i understand that
18:25 Marex: imirkin_: yes, that's what it looks like by the backtrace
18:25 imirkin_: it won't help that situation. but it might help a future situation where you accidentally turn off one of your monitors.
18:26 Marex: imirkin_: I think I'm hitting https://bugs.freedesktop.org/show_bug.cgi?id=100293 , I already poked Michel , so let's see
18:26 Marex: karolherbst: I can try that, but I kinda wanted to do something useful today too ...
18:26 Marex: karolherbst: sec
18:27 imirkin_: getting other people to fix your unusual setup will likely not get too far.
18:27 imirkin_: did you try applying the patch that manio suggested in that bug?
18:28 Marex: imirkin_: yeah, that only got me a really screwed up colormap
18:28 Marex: imirkin_: the display was totally garbled
18:28 Marex: imirkin_: I only started moaning here once I ran out of ideas
18:28 imirkin_: =/
18:29 imirkin_: Marex: did you try reverting b4e46c0444bb09f4af59d9d13acc939a0fbbc6d6 outright?
18:30 Marex: imirkin_: I don't have that in my clone of xf86-video-nouveau
18:30 imirkin_: it's xserver
18:30 Marex: ah, xserver
18:32 Marex: imirkin_: doesn't revert cleanly, but I can try
18:32 Marex: seems easy to fix
18:32 imirkin_: well, not off master, but perhaps off 1.19.3?
18:32 Marex: imirkin_: yeah, 1.19.2 is what's in debian testing, so that's what I'm using now
18:34 Marex: needs a few more reverts
18:36 Marex: ok, rebuilding with the reverts
18:36 Marex: karolherbst: booted with the trace kernel param, what do you need to know ?
18:37 Marex: [ 147.752288] nouveau 0000:06:00.0: pci: requested 2.5GT/s
18:37 Marex: [ 147.752293] nouveau 0000:06:00.0: pci: current speed: 2.5GT/s
18:37 Marex: [ 147.752294] nouveau 0000:06:00.0: pci: requested matches current speed
18:37 karolherbst: that is after changing the pstate?
18:38 Marex: yes
18:38 Marex: it's there twice, for two GPUs
18:39 karolherbst: mhh interesting
18:39 karolherbst: is the detected max speed 5.0?
18:40 imirkin_: karolherbst: there's an extra bridge chip involved, i suspect...
18:40 Marex: karolherbst: where ?
18:41 Marex: yes, there is extra bridge which has 5GT/s x16 upstream and 2.5GT/s x4 downstream
18:41 imirkin_: Marex: pastebin lspci -nnvvt
18:41 karolherbst: imirkin_: doesn't matter, the GPU tells us
18:41 karolherbst: Marex: dmesg
18:41 karolherbst: Marex: "pcie max speed:"
18:41 Marex: imirkin_:
18:41 Marex: +-03.0-[03-06]----00.0-[04-06]--+-00.0-[05]----00.0 NVIDIA Corporation G98 [Quadro NVS 450] [10de:06fa]
18:41 Marex: | \-02.0-[06]----00.0 NVIDIA Corporation G98 [Quadro NVS 450] [10de:06fa]
18:42 Marex: # dmesg | grep -i pcie.max.speed
18:42 Marex: [ 2.267331] nouveau 0000:05:00.0: pci: pcie max speed: 5.0GT/s
18:42 Marex: [ 3.834705] nouveau 0000:06:00.0: pci: pcie max speed: 5.0GT/s
18:42 Marex: karolherbst: ^
18:42 karolherbst: play
18:42 karolherbst: *okay
18:42 karolherbst: so we jsut parse the vbios wrong
18:42 karolherbst: this is fine
18:42 Marex: heh
18:42 karolherbst: I know that issue, I was just too lazy to fix that, because "nobody is hitting this anyway"
18:43 Marex: imirkin_: trying with the reverted patches to the xserver-core
18:43 karolherbst: Marex: by any chance, you don't compile your own kernel, do you?
18:43 Marex: karolherbst: no, I gave up on that, why ?
18:44 Marex: karolherbst: I mean, I do , but not for my workstation anymore
18:44 karolherbst: you could try a dirty hack, but it's not worth it to build a kernel
18:44 karolherbst: I will just try to fix the parsing soon
18:44 karolherbst: it will improve the situation under xrandr significantly
18:44 karolherbst: but I already know that
18:45 Marex: ha
18:45 Marex: karolherbst: can you share the patch ?
18:46 karolherbst: here return always 5_0: https://github.com/karolherbst/nouveau/blob/master_4.10/drm/nouveau/nvkm/subdev/pci/g84.c#L72
18:46 karolherbst: ohh wait
18:46 karolherbst: wrong place :D
18:47 karolherbst: in nvkm_pcie_set_link, set speed = NVKM_PCIE_SPEED_5_0; https://github.com/karolherbst/nouveau/blob/master_4.10/drm/nouveau/nvkm/subdev/pci/pcie.c#L115
18:48 Marex: nice hard-coded constants ...
18:48 karolherbst: never said it will not break other configurations :p
18:48 karolherbst: I just need to fix the vbios parsing code, but this is a bit complex, cause it involves reverse engineering
18:50 Marex: imirkin_: reverting that v6 commit generates a really weird color distortion on my screen
18:50 imirkin_: =/
18:51 imirkin_: i think there are more commits that need reverting
18:52 imirkin_: Marex: on top of that revert, also revert 17213b74fd7fc4c4e2fe7a3781e7422dd482a0ab and then 62f44052573b475a7b4c24f8e2da9bd6a8f1bd70
18:53 karolherbst: mupuf: 84.5% in pixmark_piano :3
18:54 karolherbst: and with dboyan_ scheduling stuff, we will get above 100%!
18:56 Marex: imirkin_: hang on ...
19:14 Marex: imirkin_: oh yes, my xinerama is back, wonderful :)
19:14 Marex: imirkin_: these are the reverts I needed
19:14 Marex: git revert --no-edit 02ff0a5d7e32ce8460d6d0669f532d65ad212fcd a58dd678bf952560e5422845e186d80a189953fe 5b9f3ea2501a886fb74e5248e82a95e76443f1e8 a446ff84de2dd29439521f6e87d75bde3bbf002c b4e46c0444bb09f4af59d9d13acc9 17213b74fd7fc4c4e2fe7a3781e7422dd482a0ab 62f44052573b475a7b4c24f8e2da9bd6a8f1bd70
19:15 imirkin_: Marex: can you make a note of that in the bug?
19:15 Marex: imirkin_: which bug ? :)
19:15 imirkin_: the one you pointed out
19:16 Marex: imirkin_: I don't think I have bugzilla account ... but sure, I can
19:16 imirkin_: i can send it for you
19:16 imirkin_: if you don't want to create one
19:16 Marex: imirkin_: that'd be nice
19:16 Marex: imirkin_: I can create one ...
19:17 imirkin_: i'm doing it now
19:19 Marex: imirkin_: seems I have an account, but I forgot the password
19:19 Marex: imirkin_: sec :)
19:19 imirkin_: don't worry about it
19:21 Marex: ah ok
19:22 Marex: imirkin_: I just changed my password, well, thanks
19:23 Marex: imirkin_: at least added myself to CC list
19:23 imirkin_: feel free to subscribe to the bug to get updates
19:23 imirkin_: :)
19:23 Marex: done
19:24 imirkin_: oh, i recognize your name... you're one of the arm soc people, right?
19:24 Marex: heh , busted
19:24 Marex: imirkin_: no, but I do a lot of stuff with arm
19:24 imirkin_: coolio
19:24 Marex: I also do a lot of stuff with mips and nios2 ... and FPGAs
19:25 imirkin_: good times :)
19:25 karolherbst: let's finally fix those remaining pcie issues
19:28 karolherbst: there is still no 16_0GT enum value in Linx :( oh well
19:30 Marex: karolherbst: you can add it and send a patch ?
19:31 karolherbst: I am just buffled, because somebody has to work on that, or not?
19:32 RSpliet: Marex: Allwinner?
19:33 RSpliet: Ah, and RISC-V tinkerer :-)
19:34 Marex: RSpliet: not really, mostly altera/xilinx/nxp
19:35 Marex: RSpliet: ah I have one A20 here to test the mali driver (man that's is such a pile of repulsive garbage, I want to step on that board)
19:35 Marex: karolherbst: eh ?
19:36 karolherbst: aren't pcie 4.0 devices coming like pretty soon?
19:36 RSpliet: Marex: yeah, Allwinner is garbage IMHO
19:36 Marex: RSpliet: not really, it's yet another standard ARM core with random peripherals ...
19:37 Marex: RSpliet: ARM Mali is garbage , GARBAGE !
19:37 RSpliet: cheap as f... something cheap, but I've had the pleasure of looking into the NAND driver
19:37 karolherbst:is wondering what RSpliet would have said if Marex is indeed working for Allwinner, mhhh
19:37 RSpliet: karolherbst: Allwinner employees have never been spotted in the wild
19:37 Marex: RSpliet: ah that, ok, NAND driver on allwiener is problematic from what I heard
19:37 karolherbst: RSpliet: :O
19:37 Marex: RSpliet: we have good support for the allwinner in U-Boot and Linux though, so no problem there
19:37 RSpliet: Marex: first hand experience. A20 can't boot from SLC, MLC/TLC is too unreliable with Linux last time I checked
19:38 Marex: RSpliet: boot from SD/eMMC ... for the applications this is used, good enough ...
19:38 RSpliet: Marex: not the applications an undisclosed we envisioned it for :-D
19:38 RSpliet: eMMC is more reliable, but more expensive
19:38 RSpliet: anyway, getting off-topic (sorry!)
19:39 Marex: imirkin_: I think last time I was adding support for this crazy card to xf86-video-nouveau, you also helped me out :)
19:39 Marex: imirkin_: I think it needed some weirdo quirk
19:45 Marex: karolherbst: can you CC me on that PCIe speed patch ?
19:46 karolherbst: I try
19:46 karolherbst: but it will take a bit of time
19:47 Marex: karolherbst: um, wait , that code you linked me to, that's not kernel is it ?
19:47 Marex: or is that out-of-tree driver ?
19:48 karolherbst: out of tree
19:48 karolherbst: but the path is the same basically
19:48 Marex: ah, yeah, I see it
19:48 karolherbst: you just need to add "drivers/gpu" or something like this
19:49 Marex: karolherbst: I have the file, yeah
19:50 Marex: karolherbst: can I somehow easily dump the register 0x460 to see my max speed ?
19:51 karolherbst: it's 5.0
19:51 karolherbst: but we have tools for this, yes
19:51 karolherbst: envytools
19:52 Marex: karolherbst: ha ... so it's set_link_speed which is called with 2.5 then ?
19:52 karolherbst: yes
19:52 karolherbst: the pstates are defined inside the vbios
19:52 karolherbst: and they also tell the driver which pcie speed to set for each pstate
19:52 karolherbst: we just parse that wrongly
19:53 karolherbst: to be sure I fix it also for you, could you grab me the vbios.rom file of one of your cards?
19:53 karolherbst: it's where the pstate file is
19:53 Marex: karolherbst: yeah, how do I do that ?
19:53 karolherbst: cat the file and write it somewhere
19:53 Marex: karolherbst: well, cat it from where ? :)
19:54 Marex: karolherbst: do you have a sysfs entry or somesuch ?
19:54 karolherbst: /sys/kernel/debug/dri/0/vbios.rom
19:54 Lyude: imirkin_: https://trello.com/c/IAqZXMmt/154-gm200-amd-vertex-shader-layer-viewport-index ready to start working on this jfyi, not sure if you want to assign the card or something
19:55 imirkin_: Lyude: do you have a username on trello?
19:55 Lyude: yep
19:55 Lyude: just lyude
19:55 imirkin_: added
19:56 Lyude: cool, thank you!
19:57 Marex: karolherbst: PM, let me know when I can remove the file
20:03 Marex: karolherbst: so ... have fun :)
20:03 Marex: karolherbst: and thanks
20:05 imirkin_: Lyude: as you probably see in the trello card, i wrote a patch for it. iirc it only works for viewport and not for layer. or vice-versa.
20:05 imirkin_: Lyude: my suspicion at the time was that some register needed to be set
20:06 imirkin_: should be easy to test to see which set of tests is failing ;)
20:07 Lyude: sure thing
20:08 imirkin_: looks like the blob also sets additional viewport regs (+0x1c, +0x18) to various values
20:08 imirkin_: no clue what that value is.
20:13 Horizon_Brave: hiya folks
20:15 imirkin_: Lyude: however it sets LAYER = USE_GP somewhere at the top, so perhaps that's where the viewport init thing is too
20:15 karolherbst: Marex: bad news, we didn't reverse engineer the right byte for the pcie speed for your vbios yet... this will get interesting
20:15 imirkin_: could be any one of those unknowns. more like to be the unknown unknowns, rather than the known ones
20:15 Lyude: imirkin_: i'll keep that in mind
20:15 karolherbst: Marex: but are your cards indeed x4 width gpus?7
20:15 imirkin_: PB: 0x00010000 GM204_3D.LAYER = { IDX = 0 | USE_GP }
20:16 imirkin_: that's what i mean by LAYER = USE_GP btw
20:16 imirkin_: karolherbst: it's a single board with 2 gpu's on it. there's a pci bridge embedded.
20:16 Lyude: oh! I would probably have asked that later lol
20:16 karolherbst: imirkin_: :O insane
20:16 imirkin_: karolherbst: look at his lspci -t output (way) above
20:16 Lyude: ohhh, do they still make those things?
20:16 imirkin_: Lyude: no
20:17 imirkin_: Lyude: but not all people use brand-new or even still-in-production GPUs
20:17 Lyude: of course
20:17 Lyude: i imagine those dual GPU combo things were a pain if you didn't have your PCIe slots in a normal order...
20:17 Lyude: well, "normal"
20:17 imirkin_:has GK208, G92GL, NV4A, and NV34 plugged in ;)
20:18 imirkin_: hm?
20:18 imirkin_: it's single-slot
20:18 Lyude: oh is it?
20:18 imirkin_: just has a bridge chip
20:18 Lyude: i thought they used to be dual slot at some point
20:18 imirkin_: and internally both of the GPUs connect to it
20:18 imirkin_: Lyude: http://www.nvidia.com/object/product_quadro_nvs_450_us.html
20:18 nyef: IIRC, the card in question isn't even a double-wide?
20:18 imirkin_: (there have been several like this though... NVS 420 iirc)
20:18 Lyude: oh, huh
20:19 imirkin_: i don't think i've ever heard of a dual-pcie-slot card
20:19 Marex: karolherbst: no idea :)
20:19 karolherbst: odd
20:19 Marex: karolherbst: that's what lspci tells me
20:19 Lyude: yeah, maybe I'm just misremembering things, it's been a while since I've seen these things
20:19 karolherbst: wonderings why both GPUs are only connected by 4x
20:20 imirkin_: karolherbst: that's a much better question. ultimately the thing only has 16x of lanes
20:20 Marex: karolherbst: the PCIe switch on the card is 5GT/s x16 , so dunno
20:20 imirkin_: so i'd assume both would be x8
20:20 Marex: karolherbst: maybe they had another design which uses x8 and they didn't want to change the PCB ?
20:20 nyef: Maybe it's the motherboard slot that's limiting things here?
20:20 Marex: nyef: that's x16
20:21 karolherbst: even the vbios says x4
20:21 Marex: karolherbst: ah
20:21 nyef: Ah, okay.
20:21 karolherbst: we can't change the width anyway
20:21 karolherbst: everytime we tried, the GPU got upset
20:21 nyef: IIRC, some motherboards have slots that are electrically x4 or x8 while physically x16?
20:22 imirkin_: yep
20:23 Horizon_Brave: what the heck is the point of that? why not just reduce the slot physically as well?
20:23 Horizon_Brave: cheaper to keep it all one size?
20:23 Marex: wouldn't the switch be on x8 then ?
20:23 imirkin_: x16 slots are also given more power
20:24 imirkin_: i dunno if you get that power if you only have a x8 connector. not sure.
20:24 Marex: that switch has
20:24 Marex: LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
20:25 Marex: but that's in caps, hmmmm
20:25 imirkin_: iirc LnkCtl is the thing
20:25 nyef: Might be cheaper to not have to source as many kinds of slot connector?
20:25 Marex: LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s, Exit Latency L0s <512ns, L1 <4us
20:26 imirkin_: er no. LnkSta is the thing
20:26 Marex: ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
20:26 Marex: LnkCtl: ASPM Disabled; Disabled- CommClk+
20:26 Marex: ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
20:26 Marex: LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
20:27 karolherbst: LnkSta is the real deal
20:27 Marex: hm, one thing doesn't make sense, I have two such switches there ?
20:28 Marex: https://pastebin.com/x7mxQxec
20:28 karolherbst: imirkin_: only x16 gets more power
20:28 karolherbst: ohhh :O
20:28 karolherbst: that's why the bridge is x16
20:29 Marex: ah nevermind, 04:0*:00 are the downstream ports
20:29 Marex: 03:00:00 is the upstream port, makes sense
20:29 karolherbst: only x16 graphics card are allowed to get additional 75W
20:29 karolherbst: uhm, in total
20:30 imirkin_: LnkCap: Port #2, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <512ns, L1 <1us
20:30 imirkin_: LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
20:30 imirkin_: so .... in THEORY, it should be possible to widen it
20:30 imirkin_: in practice, i don't know that we've ever succeeded
20:30 Marex: hm yes, looks like it
20:31 Marex: then it's make sense to use 5GT/s x16 upstream port if you have two 2.5GT/s x16 downstream ports
20:31 karolherbst: no
20:31 karolherbst: you have 2 5.0 x4 downstream ports
20:31 karolherbst: LnkCap isn't trustworthy
20:31 karolherbst: it tends to lie sometimes
20:31 Marex: heh
20:32 karolherbst: but you also have those 04:00.0 and 04:02.0 devies
20:32 karolherbst: *devices
20:33 imirkin_: seems reasonable that you could run 2x 2.5GT/s x16 devices over one 5GT/s x16 link
20:33 karolherbst: in practise not
20:33 imirkin_: why not?
20:34 karolherbst: because you wouldn't be able to contact both cards at once
20:34 Marex: overhead ? ok, but you won't use the entire bandwidth anyway ...
20:34 imirkin_: huh?
20:34 karolherbst: you can't magically split the pcie commands
20:34 imirkin_: at least one of us doesn't understand something about pcie :)
20:34 Marex: why would that be a problem >
20:34 Marex: ?
20:34 Marex: you have two PCIe endpoint devices behind a PCIe switch here
20:35 nyef: Ah, 2.5GT/s actually uses up the full second, and you only have the one link, so you'd have to run two of them at 1.25GT/s at best?
20:35 Marex: no, that's 2.5GT/s per lane
20:35 nyef: (Well, at 2.5GT/s but only for half of each second?)
20:35 karolherbst: you can't communicate with two devices on the same lane
20:35 karolherbst: and you can't split 8 lanes to 16 lanes over a bridge as well
20:36 Marex: karolherbst: that doesn't matter, the switch will handle the transfer scheduling
20:36 nyef: Hrm. Can you partition the... right, guess not.
20:36 karolherbst: except you have a super smart bridge which actually allows you to do this
20:36 imirkin_: karolherbst: why not? the bridge should handle it, no?
20:36 Marex: karolherbst: most of them do ?
20:36 karolherbst: which one does this?
20:36 imirkin_: otherwise what's the point of bridges...
20:36 imirkin_: i assumed all.
20:36 Marex: yeah, all of them, otehrwise it'd be a horrible mess
20:36 Marex: PCIe is packet based, just like ethernet (kind of)
20:37 karolherbst: I doubt any bridge can fill 32 lanes while having only 16
20:37 karolherbst: show me an example and I believe you
20:37 imirkin_: the outcoming connection is 2x the rate
20:37 imirkin_: so it all fits
20:37 karolherbst: it fits from the data rate, yes. but not on the protocol level
20:37 imirkin_: you just have to have enough of a buffer (which isn't that much)
20:38 Marex: imirkin_: even if it was all 5GT/s x16 , the switch would just say it cannot receive transmission for a bit, no problem
20:38 karolherbst: again, show me a bridge which is able to do this and I believe you
20:38 Marex: it's like ethernet, you can have 5-port 1Gbit/s switch and it works :)
20:38 imirkin_: karolherbst: show me one that can't
20:38 karolherbst: his apperantly
20:38 imirkin_: why not?
20:38 karolherbst: why does it only provdes 4 lanes to the GPUs?
20:38 imirkin_: it's just configured that way.
20:38 Marex: imirkin_: that
20:38 imirkin_: it provides 16 lanes, the gpu is only configured for 4.
20:39 karolherbst: I doubt nvidia does anything else
20:39 imirkin_: so that the driver can dynamically shift the lane allocations depending on if 1 or both are used.
20:39 karolherbst: okay, that might work
20:39 Marex: imirkin_: the driver doens't do anything
20:39 imirkin_: Marex: the nouveau driver? yeah.
20:39 imirkin_: Marex: it doesn't properly account for this situation :)
20:39 karolherbst: nvidia won't use x8 or x16 lanes as well
20:39 Marex: imirkin_: it's the switch which negotiates the PCIe config , brings up the link and reports the configuration to the kernel
20:40 Marex: imirkin_: well, the kernel enumerates the PCIe bus and gets those information from the devices anyway
20:40 imirkin_: Marex: the device can be configured as well.
20:40 nyef:is having SGI XBOW flashbacks.
20:41 Marex: imirkin_: ah well, in that case you still need to configure it somehow
20:41 Marex: imirkin_: so start in x1 2.5GT/s , communicate the setup , reenumerate
20:41 imirkin_: which is what's being discussed ;)
20:41 imirkin_: my guess is that tne nvidia gpu's come up at x4
20:41 Marex: imirkin_: I thought what's being discussed is some communication with two GPUs at the same time, which sounded weird
20:42 imirkin_: basically we write into some pci regs to tell the board to change its link settings
20:43 imirkin_: i think we've never had any real success with changing lane widths
20:43 karolherbst: on one GPU
20:43 karolherbst: and it was a macbook
20:43 imirkin_: but there's only been limited experimentation with it
20:43 karolherbst: well, it worked though
20:43 karolherbst: I think pmoreau had the one
20:43 imirkin_: since most of the time it links at x16, and all's well anyways
20:43 karolherbst: it booted at x1 and we could bring it up to x16
20:44 karolherbst: but it was also the only one telling it in the vbios
20:44 karolherbst: I think
20:44 karolherbst: I might be missremembering
20:44 karolherbst: or it was the other way around
20:45 Marex: oh jeez, I have no end of trouble with nvidia/intel combo on rMBP 10.1 :/
20:45 karolherbst: booted at 16 and the vbios allowed to bring it down to x4 or x1
20:56 karolherbst: okay, I think I found the pcie speed bytes
20:57 karolherbst: Marex: how mauch hazzle would it be for you to test something with nvidia?
21:01 nyef: Hrm... NVS 450 on eBay, about $80, give or take.
21:01 karolherbst: insane
21:02 imirkin_: nyef: 4x DP, single-slot, and fanless. pretty unique in that regard.
21:02 karolherbst: AMD should have such cards
21:02 imirkin_: but doesn't afaik
21:02 karolherbst: we have a system wich such, but embedded chip
21:02 karolherbst: so no card :(
21:02 nyef: I don't really have the panels or the use-case for one, though.
21:03 nyef: ... Are the two GPUs on the card basically SLI together?
21:03 karolherbst: uhh, such GPUs are so overpriced
21:04 imirkin_: nyef: dunno if there's a SLI link between them. could be, but hardly the point.
21:04 karolherbst: "ATI FirePro 2460 passiv" :D 200€
21:04 karolherbst: insane
21:04 imirkin_: nyef: they're the weakest GPUs of the line... G98's
21:05 nyef: Yeah, yeah. More idle curiousity than anything else at this point.
21:05 nyef: As I said, I have neither the output hardware nor the use-case for buying one.
21:05 karolherbst: can't imagine that there is no SLI connection between those
21:07 imirkin_: anyways, with DP-MST, quad output is less of a need
21:07 imirkin_: as long as you have the CRTC's to back it up
21:08 karolherbst: true
21:08 nyef: There's a Mystery Science Theater joke around here somewhere, I know it.
21:09 Marex: karolherbst: depends on what
21:09 karolherbst: Nvidia being nice or not :O
21:09 karolherbst: but no, there is no SLI GPIO, so
21:09 karolherbst: :(
21:09 Marex: imirkin_: I got this card at a local shop, it was the last one, package was opened because it was on display ... but I was lucky to get it, exactly because 4x displayport and fanless
21:09 Marex: imirkin_: I think it was the last one in the entire country
21:10 imirkin_: there's always ebay
21:10 Marex: well, yeah
21:11 nyef: Triple-up on them and video-wall?
21:12 imirkin_: people have run 5x of those for a 20-monitor wall
21:12 imirkin_: with NVS 420's iirc
21:12 imirkin_: which was the nv4x-based version of that card
21:14 karolherbst: nice
21:14 Marex:uses it for 4 2560x1440 monitors in pivoted configuration
21:14 Marex: awesome for hacking and reading PDFs (with datasheets)
21:14 Marex: and vim works super on those rotated monitors
21:14 imirkin_: not so awesome if you're the table that has to support all this
21:14 imirkin_:uses 2x 1200x1920 monitors
21:14 karolherbst: imirkin_: the NVS 810 has 8 DP connections :D
21:14 Marex: I rent this place :)
21:15 imirkin_: karolherbst: 2x kepler probably :)
21:15 nyef: Hrm. NVS 420 quad DP, $50ish?
21:15 imirkin_: nyef: hmmmm... i didn't think those did DP.
21:16 nyef: pci.ids says it's a G98?
21:16 imirkin_: oh, look at that. they did.
21:16 imirkin_: yeah, probably are. i'm thinking of 410 then?
21:16 imirkin_: or NVS 440
21:17 imirkin_: https://www.newegg.com/Product/Product.aspx?Item=N82E16814133165
21:17 imirkin_: 2x DMS-59 cables :)
21:18 imirkin_:has the pleasure of having 2 separate GPUs with DMS-59 cables
21:23 karolherbst: imirkin_: no, two maxwell
21:38 Lyude: imirkin_: mind linking that page you originally showed me for the mmt tracing stuff again? Satchelboi could probably make some use of it
21:39 imirkin_: which page?
21:39 imirkin_: you mean the page that comes up as the #1 result for [valgrind-mmt] ?
21:39 Lyude: oh, yes, i should have just tried that
21:39 Lyude: lol
22:26 Lyude: imirkin_: btw, when you said the blob was setting additional viewport regs (+0x1c, +0x18) are those offsets from a different register address?
22:26 Lyude: since 0x18 doesn't look like it would be a register address here...
23:41 imirkin_: Lyude: from the "other" viewport regs
23:41 imirkin_: Lyude: there are 16 viewports