02:42karolherbst: does anybody knows about an issue where X restarts whenever the nouveau module is loaded the first time after X is started? It happens only once per boot and maybe its sddm related?
02:48pmoreau: I'm back home for a few days, so if you need some testing or traces on various Tesla cards, just ping me. :-)
02:49RSpliet: pmoreau: alternatively, you could try and obtain traces for reclocking of those cards O:-)
02:50pmoreau: RSpliet: ;) I guess my "traces" includes "reclocking traces"
02:50pmoreau: Let me find my list of GPUs
02:51RSpliet: heh, well, I'll be the first to admit I don't have an overview of what is already available
02:52pmoreau: G80+GDDR3, G84+GDDR3, G86+DDR2, G92+GDDR3, G94+GDDR3 (2 perf levels), G96+DDR2, G98+DDR2
02:52pmoreau: But apart from the G94, they all only have 1 perf level... :(
02:53pmoreau: (I didn't included the ones from my laptop, as you already have traces for the G96, and my GT200 as you got it working :) )
02:53RSpliet: does it boot in that one particular perflvl?
02:53pmoreau: Could be that it doesn't, but I'll have to check
02:54pmoreau: And I also have a 480 that I haven't tested yet
02:55RSpliet: no rush, I probably will be extremely low in time anyway
02:57pmoreau: RSpliet: I'll most likely plug in the 480 this afternoon to test it. Do you need a reclocking trace for it?
02:58RSpliet: why not :-)
02:58RSpliet: never did properly look into Fermi
02:58RSpliet: I have about 0 of those cards
02:58pmoreau: I got my first one a few days ago from the team I was doing my master thesis with, as they didn't need it
03:01pmoreau: imirkin: I'll need your help at some point, to figure out how to correctly generate the nv50_ir::(Function, Instruction, ...) stored in nv50_ir::Program.
06:31imirkin: pmoreau: ask and ye shall receive
07:20karolherbst: imirkin: regarding my card: the nouveau driver throws some errors while trying to use the blob firmware: "nouveau E[ PFIFO][0000:01:00.0] unsupported engines 0x00000001"
07:23karolherbst: imirkin: ahh no, seems to be better now, I think I did something wrongly
07:24mlankhorst: my tegra will have a new purpose >:D
07:28martm: this poney saw some tanks
07:28martm: ouh sweet, cheers i wont push any longer, its sweet that you gave me voice
07:29martm: imirkin: yeah core mesa has some flushing issues, i think its quite a big priority to get them fixed when you have some time
07:31imirkin: mlankhorst: what's that?
07:32imirkin: mlankhorst: btw did you see my question about dri3 + scanout + ms?
07:34pmoreau: RSpliet: So, the 480 I have is a GF100+GDDR5 with 4 perf levels
07:34imirkin: all fermis have multiple perf levels
07:35pmoreau: I guess, >=GT200 has multiple per levels
07:35mlankhorst: imirkin: oh just trace it, that'll be fun :P
07:35imirkin: some pre-GT200 also have multiple ones... generally the mobile ones.
07:36imirkin: the G98 i have has 2 -- a really high one and a really low one :)
07:36imirkin: and by "really high" i mean "as compared to the really low"
07:36imirkin: but it served the purpose of me getting a vp3 board just fine
07:39pmoreau: Regarding my questions about NV50 IR, and I'll ask it again later, when I have some time to workback on it, but it was mainly how a small example of NV50 IR code would look like, and how to generate it.
07:39pmoreau: Say for example, how to define an ADD instruction
07:39martm: i am quite a rookie, i do some thinking but at different level then hw and mesa internals, i am still at gl level, guys have you tried this new dispatch glvnd stuff from ajax?
07:40imirkin: bld.mkOp2(OP_ADD, TYPE_U32, dst, src0, src1);
07:40imirkin: (or TYPE_F32 for float add)
07:40pmoreau: I used the Instruction ctor with the fct + operation + type, but I don't know how to specify the operands, where to put the result...
07:40imirkin: yeah... that won't work for a lot of diff reasons.
07:40imirkin: just use the builder
07:40imirkin: it knows all.
07:41imirkin: and has convenient helpers
07:41pmoreau: Oh, ok
07:41pmoreau: Seems way more easier indeed!
07:41imirkin: first off this stuff is all in an arena, so you can't just do new Instruction, you have to do new_Instruction
07:41imirkin: secondly you have to attach it to a bb
07:41imirkin: there's a bunch of stuff. just use the builder ;)
07:42pmoreau: I finally understood yesterday what BB meant in this case :D
07:42pmoreau: Cause for me, BB = Bounding Box
07:42imirkin: bulletin board, duh!
07:42imirkin: if you have further confusions, just ask :)
07:43imirkin: iirc my spir "code" did properly add the instructions in
07:43imirkin: it failed in some stupid graph stuff... at the time i didn't understand what the various edges meant
07:43imirkin: and i think the auto-classifier is broken
07:43pmoreau: I was trying to generate some code at the airport yesterday, but didn't had access to your branch to compare
07:43imirkin: i only ever tried to run it through nouveau_compiler though... handing it spir bitcode
07:44pmoreau: That's what I'm doing for now too
07:44imirkin: might glance at my branch then
07:44imirkin: but don't just copy it -- it gets a lot of stuff wrong
07:45imirkin: but before you get too far, make sure your logic will handle a kernel like for (i = 0; i < n; i++) foo++; or something
07:59RSpliet: imirkin: congrats with your "news" article!
08:00imirkin: haha thanks
08:00pmoreau: I planned to get a simple frag shader working before investigating how to setup kernel environments
08:00imirkin: pmoreau: ok. well there are two separate things that need to happen
08:00imirkin: pmoreau: (a) need to get all the compute stuff set up. this is actually largely done for kepler already.
08:00imirkin: pmoreau: (b) need to convert the incoming IR into nv50 ir
08:01pmoreau: imirkin: To bad I don't have a single Kepler :D
08:01imirkin: the compute stuff on nv50 is semi-done too
08:01imirkin: although i'm sure it's bitrotted horribly
08:01pmoreau: So I'm beginning by (b)
08:03imirkin: so then you should make sure that what you have works for control flow
08:03imirkin: hence my simple for loop example
08:06hakzsam_: btw, compute support is almost done for fermi too
08:07RSpliet: hakzsam_: are you talking about compute compute, or "perf counter compute"?
08:07imirkin: well, you have to get the compute pipeline up and running for those counters
08:07hakzsam_: "compute compute" (the ability to launch a kernel)
08:07RSpliet: cool :-)
08:08imirkin: hakzsam_: did you ever figure out why enabling compute killed the 3d pipeline on fermi?
08:08imirkin: (or perhaps through no action of yours the issue has gone away?)
08:08hakzsam_: imirkin, not yet, it's on my todolist :)
08:17pmoreau: Cool! :)
08:23karolherbst: imirkin: nouveau works with 4.1 ...
08:24karolherbst: at least glxgears displays something
08:27karolherbst: imirkin: also its totally fine to load the module after X got loaded
08:28karolherbst: and 0f pstate works :)
08:28karolherbst: maybe not stable enough though
08:28imirkin: karolherbst: it _actually_ works? does the "AC" or whatever line correspond to the 0f level?
08:29karolherbst: also fps in glxspheres go up
08:29imirkin: maybe coz you're not driving a display it doesn't get messed up? dunno. lucky you :)
08:29karolherbst: allthough the clock doesn't go higher with of
08:29karolherbst: because there is no higher gpu clock
08:29karolherbst: only memory
08:29imirkin: memory's kinda important
08:29karolherbst: it hangs now anyway
08:30karolherbst: yeah, its like 8% difference in glxpheres
08:30karolherbst: 240fps 07, 265fps oa and 280 fps in 0f
08:30imirkin: right. but glxspheres isn't exactly a memory heavy benchmark.
08:30karolherbst: so module got messed up anyway
08:30imirkin: the theory is that we mess *something* up training the memory and that's why it dies in 0f
08:31imirkin: since memory's kinda important to the general operation of the chip
08:31karolherbst: "[ 483.680435] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x00001d0000 [UNSUPPORTED_APERTURE] from PBDMA0/HOST on channel 0x00bf88f000 [unknown]"
08:31imirkin: yeah, aka "where'd my memory go, it was there a second ago"
08:31karolherbst: I see
08:31karolherbst: memory clocks goes from 1.6ghz to 4 ghz in 0f mode
08:31imirkin: (i guess i'm not 100% sure about that interpretation, but moderately sure)
08:32karolherbst: may be a big performance hit in some applications
08:32imirkin: right, so any screwups we make are amplified.
08:32karolherbst: also got "nouveau E[ PFIFO][0000:01:00.0] write fault at 0x00003c7000 [UNSUPPORTED_KIND] from BAR3/HOST_CPU_NB on channel 0x00bfcb7000 [unknown]" a lot
08:32imirkin: but the highest perf level doesn't work for anyone with GDDR5 vram, so i doubt you'd be an exception
08:32martm: we should leave this kinda issues to aussies and imirkin, though imirkin seems kinda ignorant, aussies and imirkin deal with hw roms:) terrible
08:32karolherbst: could blob firmware help here?
08:33imirkin: i mean... yes
08:33imirkin: but not the ctxsw firmware :)
08:33karolherbst: I extraced firmware from driver and mmiotrace
08:33imirkin: but we could reuse their PMU firmware
08:33imirkin: instead of writing our own
08:34karolherbst: mhhh, after the error the gpu state is pretty messed up :/
08:34karolherbst: even lower states won't work anymore
08:34imirkin: yeah, the memory's gone :)
08:34imirkin: and it can't remember where it went
08:34karolherbst: I will try if module unload/load helps, but I think I have to turn off the card
08:35karolherbst: nice, module reload helped
08:35karolherbst: with dri3 this is really nice
08:36karolherbst: because the X server doesn't claim the card if the modesetting driver is gone or dummy driver forced
08:36imirkin: forcing a vbios run probably sets it all back properly
08:36karolherbst: trying some big OpenGL titles I guess
08:37karolherbst: I should have tried 4.1 earlier :/
08:37karolherbst: but I usually wait until new bfs patches are out
08:39karolherbst: I think I see some minor corruptions, but that mioght be because of 60+ fps
08:40imirkin: if you have reproducible rendering issues, provide a trace, i can investigate
08:40imirkin: (trace == apitrace)
08:40karolherbst: hard to tell, most likely vsync problem
08:40karolherbst: but still different
08:40imirkin: well if the models are all messed up, then it's a rendering issue
08:40imirkin: if the colors are messed up, rendering issue
08:40imirkin: if it's tearing, vsync issue
08:42karolherbst: any prefered games I should test?
08:42imirkin: whatever you like
08:42karolherbst: ohh, windows are turning black sometimes
08:43imirkin: do update mesa before filing any bugs though, i've been fixing a bunch of stuff
08:43karolherbst: at least in steam
08:43karolherbst: yeah I emerged with debug symbols today
08:44karolherbst: yeah, seems like sometimes the content of a X window is black until a new update comes
08:45imirkin: feels like a dri issue, but someone also filed a bug about single-buffered situations where apparently nouveau doesn't always work. could be a larger mesa issue too.
08:45imirkin: unfortunately i don't really understand any of that stuff
08:45karolherbst: I see
08:48karolherbst: whoa, loading times should be rather high compared to blob driver, right?
08:49imirkin: depends what it's loading... if it's stuff into vram, then yes :)
08:49karolherbst: game like talos principle? (uses smae engine as SS 3)
08:50karolherbst: at least the game runs fine without any noticable issues
08:50imirkin: talos principle has an extra-fun bug where things turn red every so often
08:50imirkin: for like a frame
08:50imirkin: and then they're fine again
08:50karolherbst: I see green walls sometimes
08:50karolherbst: for one frame
08:50imirkin: probably the same thing
08:51karolherbst: cpu/gpu set to high, memory to lowes in game settings .D
08:51imirkin: or maybe i jogged the compiler enough that things are off by one register and now it's getting a 1 in the green channel instead of red.
08:51karolherbst: 5.2 fps in 07 pstate
08:51karolherbst: 6.6 in 0a state
08:52karolherbst: mhh, performance is not that high sadly :/
08:54imirkin: i think that clock-for-clock, nouveau tends to be in the 60-80% range of the blob driver
08:54karolherbst: I think it doesn't reclock right for me
08:57karolherbst: okay, using blob driver after nouveau error, bad idea
09:00karolherbst: imirkin: apitrace should be easy with DRI_PRIME, shouldn't it?
09:00karolherbst: only done it with bumblebee, and it was messy there
09:00martm: i am sorry to ask you karolherbst: but are you a woman hacker, hehee, that is pretty honarable isn't it?
09:00karolherbst: no, I am not, why? :p
09:01martm: karol, isn't that a womens name?
09:01karolherbst: not in all states
09:01imirkin: karolherbst: should Just Work (tm). but if it's about talos, no need, there's already the one bug open
09:01karolherbst: in east europe its usually a male name
09:01martm: yeah that makes sence!
09:01karolherbst: the polish pope was named karol as well
09:02martm: yeah but actually you did not deny being a woman either! you just said there are men with name karol!
09:02martm: polish are so keen of their belives
09:03martm: i think in poland it was said it was a crime to let a women to be unsatisfied and sexually
09:03martm: ah sorry , i will go, i am drunk again
09:03martm: cheers, before i get banned
09:04karolherbst: sometimes fn key layout are just total shit
09:04karolherbst: F2: disable screen, F3: mute speaker, F4: suspend, F5 and F6: raise, lower volume
09:04karolherbst: guess how often I hit F4
09:05imirkin: but look on the bright side -- you test out suspend/resume!
09:05karolherbst: yeah, like I never do it with my laptop
09:05karolherbst: allthough polkit 0.113 messed up my suspend
09:05karolherbst: needs root authentication
09:16karolherbst: imirkin: on a side note: runpm doesn*t seem to have any effect here :/
09:16karolherbst: card doesn't turn off at all, maybe its because of the hack
09:17imirkin: karolherbst: do you have CONFIG_RUNTIME_PM?
09:18imirkin: and maybe i was wrong, perhaps you really do have to have CONFIG_VGA_SWITCHEROO for it to work
09:19imirkin: other reasons are a phantom VGA output that keeps getting polled, prevent the card from sleeping
09:20karolherbst: imirkin: I think the options is called different now
09:20karolherbst: and with direct ACPI calls I can disable the card
09:20karolherbst: at least bbswitch works all the time
09:20karolherbst: whch doesn*t do anything else, than ACPI stuff
09:21imirkin: aha, it's just CONFIG_PM now
09:21imirkin: used to be a separate CONFIG_PM_RUNTIME
09:22imirkin: but i guess you need CONFIG_VGA_SWITCHEROO for nouveau's runpm to activate.
09:22imirkin: you def need it to see what state things are in, which is also convenient
09:22karolherbst: yeah, I guess so
09:22karolherbst: the description of switcheroo is really missleading now anyway
09:23imirkin: [e.g. how do you know that it's not turning the card off?]
09:23karolherbst: I have a LED which indicates the power status
09:23karolherbst: best thing you can have in a hybrid gpu laptop :D
09:23karolherbst: but the card also drains around 20W in idle, so its really important to know
09:26karolherbst: talos same settings with blob: nearly 30 fps
09:26karolherbst: nouveau was at 7 fps top
09:26karolherbst: 0a pstate
09:27karolherbst: but my 0a pstate also has a clock range
09:32karolherbst: imirkin: I am sure that the nouveau driver isn't parsing the clock information for my gpu right, where would be the right place to investigate it further?
09:33karolherbst: also if a pstate has 405-862MHz gpu clocking, will the driver reclock the gpu above 405 at any time? or will it stay at 405?
09:33RSpliet: karolherbst: what GPU is that again?
09:33karolherbst: only memory clocks are static across pstate
09:33karolherbst: but gpu clocks are always ranges across all pstates
09:33RSpliet: NVE6... is that with DDR3?
09:34mogorva: karolherbst: Talos Principle and SS3 render lots of flashing pixels here with a NV92 when gpu speed=medium: https://drive.google.com/open?id=0B-tTbLKBl-tOT01VMW95cmMxUFU
09:34RSpliet: oh right... but no memory reclocks; ok, in that case I'm not the man to look at it now :-)
09:34karolherbst: RSpliet: https://gist.github.com/karolherbst/9abd37717e1c08ab699a
09:35karolherbst: after I clocked down with blob driver to 713MHz (by 135MHz), the fps dropped to 19 from nearly 30
09:35karolherbst: so I think that would be the issue,w hy mesa only has around 7
09:35karolherbst: when the card is clocked at 405
09:35imirkin: karolherbst: probably http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/bios/rammap.c for the parsing
09:37karolherbst: but what about dyamic reclocking? Does the driver do that? Because if not, than its safe to assume it will stay at the lowest clock
09:38RSpliet: nouveau doesn't do that no
09:38karolherbst: O7 state should be 135MHz min gpu clock though for me
09:38karolherbst: other state also 135MHz min :/
09:38karolherbst: at least its waht nvidia-settings is telling me
09:49karolherbst: sadly this file is a little bit too cryptic for me :/
10:05karolherbst: imirkin: should I create an apitrace for the green wall issue in talos or is the issue already filled with enough information
10:06imirkin: karolherbst: well, there's already an outstanding issue for talos. if you like, you can add another trace to that bug
10:06imirkin: unfortunately i have no clue what's causing it
10:06imirkin: its draws are quite complicated, i haven't even isolated the draw that's going wrong
10:11karolherbst: I see
10:11karolherbst: I think I'll wait until the one issue is fixed, not that my trace will add confusing, because its a different issue or something
10:11karolherbst: anitchamber runs pretty good by the way
10:12karolherbst: is the 0a pstate supposed to be stable or can the gpu also get some errors there?
10:13RSpliet: karolherbst: are you talking ideal world or the real world? :-
10:13imirkin: GPU can get errors in any state
10:13karolherbst: real world of course
10:13RSpliet: it greatly depends on the graphics card, but in general I'd say GDDR5 reclocking is a "not supported, but might work"
10:13karolherbst: I see
10:13karolherbst: yeah my memory is getting reclocked
10:14karolherbst: but not near the max clock
10:14karolherbst: imirkin: shouldn't have SS3 the same issue as talos?
10:16imirkin: what's SS3?
10:16karolherbst: serious sam 3
10:16imirkin: file a bug... i have no idea
10:17karolherbst: because it uses the same engine
10:17imirkin: then it's fairly likely
10:17karolherbst: same game dev by the way
10:18karolherbst: same performance problems :D
10:18karolherbst: some setting in low really let the fps drop
10:18karolherbst: lowest is really fast
10:32karolherbst: okay, so there are multiple issues inside ss3
10:33imirkin: is there also a shadow flickering situation?
10:36karolherbst: don't know yet, I made a short screen capturing video and want to do screenshots of them first
10:37karolherbst: but I think yes
10:38karolherbst: imirkin: this is the one with the "tearing": https://imgur.com/ld8ei8t
10:38karolherbst: doesn't look like tearing to me
10:39karolherbst: allthough it does a little, but its not tearing ;)
10:39imirkin: that's weird.
10:39karolherbst: its like tearing on a hardware level :D
10:40imirkin: looks like a wrong stride or something, but that'd be very unlikely
10:41imirkin: but if you were recording your screen, who knows. this needs to be looked at in the trace
10:41karolherbst: this happens quite often with nouveau
10:42karolherbst: ever saw it before
10:42karolherbst: it also happens with glxspheres, so a trace from it would be pretty simple to read, shouldn't it?
10:44imirkin: from the sounds of it, it's actually not related to nouveau (directly)
10:44imirkin: but rather to dri3
10:44imirkin: i bet if you were to render the trace using nouveau, no such tearing would be present
10:44imirkin: but in displaying to the screen, the tears appear
10:45imirkin: [not that dri2 would do considerably better btw]
10:46karolherbst: but I can't unload the module then, right
10:46karolherbst: I missunderstood your sentence
10:46karolherbst: yeah I will try to create an apitrace of it
10:46karolherbst: allthough tearing is prevented here, because it an internal tearing somewhere inside the prime section
10:47martm: so called texture from pixmap, basically ipc of both ways hardly matters, but this guy is a good bloke krh
10:47imirkin: maybe. or maybe it doesn't copy in quite the order you think.
10:48martm: it just passes an address basically
10:48martm: that is why it is zero copy
10:56karolherbst: can I somehow control the speed of glretrace?
10:57imirkin: you might look into qapitrace
11:00karolherbst: mhh, the thumbnails are too small, maybe I can do something in the trace
11:00imirkin: you can click
11:00imirkin: and see the individual surfaces
11:00imirkin: it's not the most intuitive tool
11:00imirkin: but it is fairly versatile
11:00karolherbst: ahh I can create a video out of the trace
11:00karolherbst: then it should be possible :D
11:01imirkin: glretrace will let you dump out each of the frames one-by-one as well
11:01imirkin: look at the help
11:13karolherbst: the trace looks perfectly fine :/
11:14karolherbst: forgot to render it through nouveau :/
11:15imirkin: also note that traces taken with the blob might not replay on nouveau -- blob supports more features
11:15imirkin: in addition to the "regular" GL features, they also support a ton of NV_* extensions
11:15imirkin: which some engines probably make use of
11:18karolherbst: ohh, I saw them ow
11:23karolherbst: imirkin: is there a nice way to render the trace without PRIME on nouveau?
11:23karolherbst: second X server and DISPLAY?
11:24imirkin: karolherbst: yep, that's what i do
11:25imirkin: and i x11vnc + vncviewer into it ;)
11:25imirkin: although that's not really required
11:26karolherbst: mhh wait...
11:26karolherbst: the snapshots doesn't have the issue
11:26karolherbst: I see it only while replaying
11:26imirkin: like i said, it's not a straight-up nouveau issue
11:26imirkin: but rather a dri one
11:26karolherbst: yeah, okay
11:26imirkin: not that that makes it any less annoying
11:27karolherbst: zero copy issue I guess
11:27karolherbst: because you can see that on top is the new frame and bottom the last one
11:27imirkin: right. i dunno how it's all even supposed to work in the first place
11:28imirkin: my understanding of that portion of the display stack is minimal at best
11:28imirkin: although much closer to non-existent
11:28karolherbst: I think its buffer sharing of some kind
11:28imirkin: sounds like you're on my level ;)
11:28karolherbst: at least you don't need a ddx driver with DRI3 and this is a big win
11:29imirkin: i never do prime stuff in the first place
11:29imirkin: my laptop only has intel
11:29karolherbst: I see
11:30karolherbst: the thing is, the X server always tries to load a DDX driver for the card after I load the module and after that I can't unload it, so its pretty nice I think
11:30imirkin: right now i have 2 nvidia boards in my desktop, but i'm using them separately
11:30karolherbst: I couild use bumblebee though
11:30karolherbst: and compare performance
11:30karolherbst: no runpm needed in that case
11:30imirkin: well, runpm tends to work fairly well
11:31imirkin: just needs some more care in that hack patch
11:31karolherbst: yeah, but runpm makes only sense with prime
11:31karolherbst: allthough bumblebee can also use switcheroo instead of bbswitch
11:32imirkin: switcheroo is like 20 diff things btw
11:32imirkin: and none of which is the original thing it was designed for
11:32imirkin: (at least not on modern hw)
11:33karolherbst: yeah, I know
11:38karolherbst: imirkin: but maybe another issue: the first time nouveau is loaded it turns the card on, if its off
11:39karolherbst: but the next time it won't do it anymore
11:44karolherbst: will try switcheroo now
11:47boxfire_: when I see "(WW) EDID timing clock 297.00 exceeds claimed max 115MHz, fixing" in my Xorg.0.log, I wonder who's calimed maximum is that? The Nouveau driver? The screen?
11:51imirkin: boxfire_: probably. although 115 doesn't sound like a familiar limit. what GPU are you on?
11:51boxfire_: imirkin: Quattro 2000M, nvc3
11:51imirkin: aha, pre-NV18 only did up to 112mhz
11:52imirkin: but nvc3 is well past that era :)
11:52boxfire_: imirkin: is this a nouveau limitation? I happen to know I can drive a 300 mhz clock with this card from the propietary driver, but I will never install that again
11:53imirkin: it's a limitation that's being imposed by nouveau, but clearly for some BS reason. in general it has no issues with handling the full supported pixel clocks of all cards
11:54boxfire_: frustrating. Any clue on where to look to get around this limitation?
11:54karolherbst: imirkin: switcheroo is required as it seems
11:54karolherbst: the card went off after some time now
11:54imirkin: mogorva: mind making a trace of one of those other games fixed by my torchlight patch? want to see if it's the same issue, or a different one (i.e. is it also coz of the stupid gl_SecondaryColor thing, or they are otherwise expecting uninitialized values to be 0)
11:54imirkin: karolherbst: cool. i think we wait 10s or so.
11:55imirkin: boxfire_: pastebin dmesg and xorg logs
11:55imirkin: is this on a DP output?
11:56karolherbst: imirkin: also no system crash until now
11:56karolherbst: also GLX seems to work fine even with the hack
11:56boxfire_: imirkin: it is a DP output though HDMI converter
11:56mogorva: imirkin: sure, just have to restart X...
11:56imirkin: mogorva: no rush
11:56imirkin: mogorva: i want to see what people say about whether it looks like a compiler problem
11:57imirkin: boxfire_: yeah... for DP we set the max clock based on... the encoder's linkbw.
11:57imirkin: so if we read that in wrong
11:57boxfire_: imirkin: xorg: http://paste.pound-python.org/raw/gQc48Nn9GfGZDKYmhCs8/ dmesg: http://paste.pound-python.org/raw/mQcUEfwR3DTr7tYILegg/
11:57karolherbst: imirkin: only errors from dmesg: https://gist.github.com/karolherbst/6dafaff47c482523d154
12:00boxfire_: imirkin: so is there any way to force the value?
12:01imirkin: boxfire_: probably... i'm not immensely familiar with the code
12:01imirkin: [ 110.007] (WW) EDID timing clock 297.00 exceeds claimed max 115MHz, fixing
12:01imirkin: [ 110.007] (--) NOUVEAU(G0): HDMI max TMDS frequency 300000KHz
12:01imirkin: this is def a bit weird...
12:01imirkin: skeggsb: if you're back, perhaps you can take a look --^
12:02karolherbst: so is there anything I could do with helping max pstate stability? Or is it just a coincidence that lower states work and there is a bigger known problem inside the driver?
12:03imirkin: mmm... it's known that higher ones don't work
12:03imirkin: it's unknown why
12:03boxfire_: imirkin: thanks. Im going out for a few hours but ill check back later.
12:04imirkin: i think ben had some ideas, but they didn't pan out. or they did, but not enough... i dunno
12:04karolherbst: I see
12:04imirkin: as i have no such hw, i haven't been paying close attention
12:05karolherbst: the memory is clocked higher than the pstate
12:20RSpliet: skeggsb: could you perhaps roll a build of libdrm 2.4.62 for Fedora?
12:20RSpliet: ... when you wake up :-D
12:24karolherbst: mhh I could also try out vdpau stuff and such...
12:25martm: i would not for example if i had nvidia card, never try out something but just use:)
12:26martm: estonian barbarian like i am
12:31martm: btw, in september there is like 20years after a new battle, euro 2015 and one of the matches is between neighboring countries, latvia vs estonia basketball, and here i go, before a ban, that i am considering maybe i should visit latvia
12:31martm: cheers, latvia is favorite, but estonians may suprise
12:42imirkin_: karolherbst: should work with the same DRI_PRIME flag
12:42imirkin_: there are some known issues in h264 decode, no idea why they happen
12:43imirkin_: some videos will produces unpleasant artifacts though. used to be extremely rare, but whatever the feature, it's starting to get used more
12:47karolherbst: I just need to compile mesa with vdpau support and the applications, too, right?
12:47imirkin_: and the nvidia-firmware package
12:48karolherbst: I see
12:48imirkin_: although for kepler it should be moderately easy to make nouveau firmware for it
12:48imirkin_: fermi and earlier would be trickier
12:48karolherbst: vaapi and xmvc aren't important things to test I guess?
12:48imirkin_: vaapi won't work. neither will xvmc
12:48imirkin_: xvmc will only work with older GPUs
12:48imirkin_: up to G96 (and GT200 which is out-of-sequence)
12:49karolherbst: for VDPAU I also need to set the driver to the right one I guess
12:49imirkin_: should Just Work (tm)
12:49karolherbst: mhh I have a vdpau to vaapi bridge installed
12:49karolherbst: so I think I have enforced this one currently
12:49imirkin_: er maybe not with dri3, dunno
12:50imirkin_: hehe ok
12:50imirkin_: the vaapi issue is probably fixable, but it's hard to care
12:50imirkin_: no useful software i'm aware of uses vaapi
13:01karolherbst: vlc uses vaapi
13:01karolherbst: on intel you don't have vdpau
13:01karolherbst: so you have to use vaapi
13:01karolherbst: and there is a lot of software supporting it
13:01imirkin_: i believe i've legislated that out... i said 'useful'
13:02imirkin_: ime vlc is great at not playing videos
13:02karolherbst: ffmpeg also have vaapi support
13:02imirkin_: hmmm... that must be recent
13:02karolherbst: there are also mplayer patches
13:02imirkin_: probably due to the popularity of intel gpu's and the fact that they don't have a native vdpau output
13:03imirkin_: glad you refrained from mentioning gstreamer ;)
13:03karolherbst: I don't use it
13:03karolherbst: I used the vlc backend for phonon since always
13:04imirkin_: i guess i'm pretty set in my ways... but like 10-15y ago, mplayer was the thing that actually was able to play back all videos flawlessly
13:04imirkin_: including corrupt videos, etc
13:04imirkin_: before that, avifile was the cool kid on the block. but mplayer destroyed that pretty handily. haven't seen a need to move on.
13:05Karlton: mpv is nice
13:05karolherbst: I use vlc for everything and it seems to work
13:06karolherbst: but has maybe the highest CPU usage of all
13:06imirkin_: try it with OTA mpeg2-ts files
13:06karolherbst: also I don't use vaapi with it, because of bad quality :D
13:06imirkin_: (or rather, streams)
13:06karolherbst: why shouldn't it?
13:06imirkin_: because of corruption in the streams
13:06karolherbst: yeah, well
13:06imirkin_: hence the OTA bit
13:06imirkin_: i'm sure if you make a TS container it'll play it back fine
13:08karolherbst: how do I know if vdpau is used?
13:09imirkin_: with mplayer it's pretty obvious -- just look at the output
13:09imirkin_: it'll die if you tell it to use a vdpau codec and vdpau's not there
13:09imirkin_: mplayer -vo vdpau -vc ffh246vdpau or whatever
13:09imirkin_: and on the off chance you don't want to type that every time, see http://nouveau.freedesktop.org/wiki/VideoAcceleration/#usingvdpau
13:27karolherbst: mhh doesn't seem to work
13:27imirkin_: did you do DRI_PRIME=1?
13:27imirkin_: and did you get the firmware?
13:27imirkin_: (nvidia-firmware ebuild on gentoo)
13:27karolherbst: "DRI_PRIME=1 VDPAU_DRIVER=nouveau vdpauinfo" gives me: "Error creating VDPAU device: 23"
13:27karolherbst: yeah I have it
13:28karolherbst: do I ahve to pass the option to the module too?
13:28imirkin_: can you strace -f -e open on that?
13:29karolherbst: it wants to access the intel card
13:29imirkin_: i bet that's the intel card, right? /dev/dri/card0
13:30imirkin_: there might be some additional trick for dri3... sorry, not sure
13:30karolherbst: "DRI_PRIME=1 VDPAU_DRIVER=va_gl vdpauinfo" uses the intel card as expected
13:30karolherbst: yeah, I think something has to be done as well, but this is strange
13:31imirkin_: quite sure it works with dri2
13:31imirkin_: but all this winsys stuff is well outside my knowledge area
13:32karolherbst: the thing is
13:32karolherbst: why should anybody bother using the nvidia card anyway?
13:32imirkin_: beats me
13:32karolherbst: intel vaapi performance is usually good enough anyway
13:32imirkin_: not all computers are laptops with intel gpu's
13:32karolherbst: yeah, but then you don't have the prime thing
13:33karolherbst: then this issue doesn't exist anyway
13:33imirkin_: which is why i haven't really worried about it
13:33karolherbst: I see
13:33imirkin_: i forget if intel can decode 4k
13:33karolherbst: should work
13:33imirkin_: also vainfo doesn't appear to report mpeg4 support
13:34imirkin_: (i.e. mpeg4p2) but perhaps i just don't know how to read it
13:34karolherbst: mhh only h264
13:34imirkin_: on the bright side it does mjpeg :)
13:34karolherbst: vdpau info with vaapi bridge :D
13:35imirkin_: this is what i get on my gk208: http://hastebin.com/jenuvawino.hs
13:35imirkin_: so i guess it doesn't claim to do 4k
13:36imirkin_: could just be an vdpau <-> vaapi adapter issue
13:36karolherbst: could be an issue with the brdige though
13:36imirkin_: and the vdpau st in mesa also does temporal deinterlace
13:37imirkin_: erm, those output surfaces in your list are whack too
13:56karolherbst: seems like since HD 4000 there are 4k decoders on the gpu, but only the haswell one seems to be usefull enough
14:00imirkin_: hd4000 == haswell...
14:00imirkin_: er actually, hd4000 == ivy bridge, but hd4x00 is haswell (x > 0)
14:00imirkin_: hd5000 is also haswell
14:01imirkin_: ((but hd5x00 is broadwell)
14:02karolherbst: yeah, confusing
14:03karolherbst: >=5200 is hsw iris
14:03martm: yeah broadwell
14:03martm: with some edram cache prolly 128mb
14:03karolherbst: 5200 is still haswell
14:04imirkin_: i think iris is in a parallel numbering scheme
14:04imirkin_: but not 100% sure
14:05imirkin_: the only thing i *am* 100% sure of is that the marketing people aimed to make it as confusing as humanly possible
14:05martm: i dunno what is the difference maybe 5600 or something was broadwell we saw with my mate it had 1,9 billion transistors
14:05martm: really strong stuff when mantle will be implemented, it will run the stuff on netbooks
14:05karolherbst: 5300 and up is broadwell
14:05karolherbst: and >=6300 is broadwell iris
14:06karolherbst: allthough 6000 is not iris
14:06imirkin_: i wouldn't be surprised if there were a 5200 non-iris broadwell
14:06karolherbst: actuall there is a hd graphics broadwell
14:06karolherbst: without a number
14:06karolherbst: but 5300 is the first broadwell
14:08imirkin_: looks like you're right
14:13martm: was it lz4 panasonic, my favorite laptop ever, but i don't have so much money, it has broadwell
14:13martm: i have but i have to spare some for the worst days which are coming
14:16martm: nowdays they do equipment that you rotate 360 degrees so that keyboard will face downwards, bit easier then before, good idea though if keys are locked
14:17martm: realistically i am thinking more to get one bail trail that is quite a same size and same techique, but soon
14:21karolherbst: what would you say how "easy" would it be to add support for providing manual clocking support if a pstate supports a gpu clock range?
14:21karolherbst: or is there already something planned in this direction?
14:22imirkin_: just setting the core clock frequency? _should_ be moderately easy
14:22martm: i really have no clue why it takes so long, i think there are too many cards to be honest
14:23imirkin_: i'm not aware of any specific plans in the reclocking area
14:24karolherbst: but inside "safe" ranges
14:24karolherbst: like with coolbits in the blob driver I can only increase/decrase by a small margin
14:24karolherbst: like 135MHz clock and 1.6GHz memory
14:24karolherbst: would be interessting if these value are read from the card or are inside the driver
14:27imirkin_: probably from the vbios
14:29karolherbst: switching to blob driver isn't as stable as expected :/
14:33karolherbst: imirkin: any idea how someone would implemet such reclocking? Maybe if I find some time I could do something like that
14:33imirkin_: take a look at subdev/clk
14:33imirkin_: [i think]
14:33martm: i am trying to motivate imirkin for some time, if we talk about open source drivers then some of the reclocking is missing, i never had any hw
14:34karolherbst: gk104.c for my card?
14:36karolherbst: calc_clk looks like something
14:36imirkin_: actually all the reclocking is already in place
14:36imirkin_: really you just want to provide an interface to pass the frequency
14:36imirkin_: normally this is done via pstates
14:36imirkin_: but you want an explicit frequency
14:36martm: yeah but, just take some mmiotrace of your card, clock it with coolbits and look whats wrong there in the code
14:37imirkin_: also if you move the whole thing into debugfs, that'd be much appreciated
14:37imirkin_: since then it wouldn't have to be behind that stupid pstate=1 flag
14:37karolherbst: I see
14:37karolherbst: martm: the thing is, "I" can't clock the card
14:37karolherbst: I can only say: please be -135MHz underclocked
14:38martm: yeah but with blob you can or not?
14:38karolherbst: but then the driver itself reclocks the card anytime to any value
14:38karolherbst: its automagically done
14:38martm: ouh why not?
14:38martm: aaah yeah ok
14:38martm: touches really
14:38karolherbst: the highest "pstate" has a gpu clock of 135-862MHz rannge
14:38karolherbst: and it will be somewhere in between
14:39karolherbst: I can only set offsets via coolbits, but then again only in "allowed" ranges
14:39karolherbst: -135 to +135MHz for clock is allowed
14:39martm: which card is that though, can you englighten me what is the row of cards with what coolbits does not work?
14:39karolherbst: coolbit kind of work
14:39karolherbst: because without it, I can't set the offsets
14:40karolherbst: I think this is because of architecture
14:40karolherbst: because there is also something like turboboost for gpus
14:40martm: ouh. they scream allreay here, what does it mean kinda works?
14:41martm: coolbits i mean
14:41martm: can you set the clock with coolbits or not?
14:41martm: what a shame, touches
14:42martm: imirkin: my apoligies again, i go to sleep, i did not know that
14:42karolherbst: GPU boost 2.0 is there since 7XXM and 750+
14:42martm: yeah its bit creapy to trace the automatic version i belive
14:43karolherbst: could be fine though :D
14:46pmoreau: Back to some MBP, cause some nice people wants it fixed, and fast
14:47karolherbst: imirkin_: idea: dump the struct gk104_clk_info eng; content of gk104_clk_info into debugfs or sysfs and let the used choose one of the settings
14:48imirkin_: karolherbst: aka nvbios in envytools?
14:48imirkin_: or you mean the current register content? i'm certainly not against it..
14:48karolherbst: yeah I meant was is currently there
14:48imirkin_: note that there's also nvapeek & co which can read regs
14:49karolherbst: I am not aware of most of the tools, so I have to guess a lot now
14:49imirkin_: and a whole bunch of tools to look at the current state of things at http://cgit.freedesktop.org/~darktama/nouveau/tree/bin too
14:49imirkin_: (specifically nv_perfmon, although i've never used it)
14:50karolherbst: is there a nice tool to dump the entire known clocking stuff?
14:51imirkin_: nvatiming has a bunch of stuff (in envytools)
14:53karolherbst: card turned off while running it :D
14:53imirkin_: yeah runpm will activate if there are no interrupts
14:53karolherbst: I see
14:53karolherbst: will reboot to turn off module singin requiernemt ... otherwise developing might be difficult
15:47pmoreau: RSpliet: I'll play with your patches tomorrow :-)
16:42pmoreau: Hum... I removed the if block from http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nouveau_display.c#n480 along with the backlight init for the G96, and I don't get the issue when loading Nouveau.
16:42pmoreau: However it hangs when loading X or powering down the G96.
16:45pmoreau: For powering down, it gets stuck at "waiting for kernel channels to go idle...", where as for X, it's after doing some PGRAPH reset and PFIFO stuff on the G96.
16:46tobijk: and after a while it just goes on?
16:46pmoreau: For X?
16:47tobijk: i see something similar lately
16:47pmoreau: Maybe I wasn't patient enough, I'll retry :)
16:47tobijk: at X shutdown
16:51imirkin_: pmoreau: well, that avoids creating a PDISP entirely
16:51imirkin_: pmoreau: i think what you want is to create a PDISP but leave it disabled
16:51imirkin_: and then enable it when switching GPU's
16:53pmoreau: How do I leave it disabled?
16:56imirkin_: clear its bit in PMC.ENABLE
16:56pmoreau: Oh right
16:56imirkin_: (isn't that what i was suggesting you do a few weeks ago)
16:57pmoreau: I had just forgotten about it
17:00tobijk: mh would thsat work for nve+ as well? or are we doing it already?
17:08imirkin_: i think it's different for those... this is for the more conventional switching setup
17:08zerwas: imirkin_: just wanted to let you know that the freezes are gone since the last xorg-edgers ppa update for me. :)
17:09imirkin_: can't say i remember what problem you had, but no more freezes sounds like a win
17:10zerwas: Definitely, yes
17:27pmoreau: Disabling PDISP at the end of nouveau_display_init does not avoid the "unable to handle page request error", putting it at the beginning results in some of the PDISP config timeout'ing (seems a reasonable behaviour)
17:30imirkin_: and by disabling you mean nuking it from PMC.ENABLE?
17:31pmoreau: There's something else wrong than having two PDISP engines: during the initialisation of the G96 (so before the MCP79 is init'ed), the steps after the message "MM: using CRYPT for buffer copies" takes way longer (~3-4 sec) when I will get the error, than when I will not (aka. by changing 0x8841c).
17:32pmoreau: (So between MM and I2C messages "[0x00000000] PAD:X:00: -> PORT:00")
17:33tobijk: pmoreau: if you find something in shared code let me know :)
17:33pmoreau: tobijk: I'll try to remember to :)
17:34tobijk: thanks :)
17:48pmoreau: I'll continue playing with it tomorrow
18:13boxfire_: imirkin_: on my return I am looking into this a bit and its all problems from teractions in the xserver hw/xfree86/ddc and modes code
18:15boxfire_: boxfire_: handle_edid_quirks checks the mode clock vs the detected clock, but for some reason the 300000 hz is not what is present in that function
18:17boxfire_: so either some implicit default gets set for OPTION_MAX_CLOCK, overwriting what gets detected, or black magick. I'm going with innane default here
18:28imirkin: well, it gets the max clock from the crtc in the kernel
18:28imirkin: in drmmode_* or whatever
18:31boxfire_: imirkin_: right, and the print statement from hw/xfree86/modes/xf86Crtc.c:1704 shows the 300000 KHz value
18:32boxfire_: that could only be overwritten by the slightly later call to parse the monitor option section for MaxClock
18:34imirkin: boxfire_: what do you get when you do 'grep . /sys/class/drm/card*-*/modes'
18:36boxfire_: imirkin: http://paste.pound-python.org/raw/ZVLKqpxKzDrjfXukWUa9/
18:37imirkin: that sucks :)
18:38imirkin: try rebooting with drm.debug=0xe nouveau.debug=DRM=debug,DISP=debug
19:00boxfire_: imirkin: dmesg: http://paste.pound-python.org/raw/lGJ72km9YfeiSw6OW0E9/
19:06imirkin: oh gr. sorry. PDISP=debug, not DISP. my bad :(
19:09boxfire_: imirkin: http://paste.pound-python.org/raw/ZC6poP7RLos90G05wEMT/
19:09imirkin: anyways... your link_bw should be 10 and link_nr should be 4
19:10imirkin: oh hm
19:12imirkin: hmmmm. it doesn't have some messages i was expecting
19:13imirkin: skeggsb: i think that one of your refactors may have broken the DRM=debug thing
19:13imirkin: errr... maybe not
19:13imirkin: maybe it didnt' work to begin with
19:16imirkin: boxfire_: i dunno what's going on
19:17imirkin: boxfire_: this is the function that validates the modes: nouveau_connector_mode_valid
19:17imirkin: i think that the HDMI adapter is causing some of the dp stuff to not happen
19:17imirkin: and so it gets bs values. or something.
19:20boxfire_: imirkin: hmm I am going to add some debug prints on my kernel source in there and see where I can go
19:21imirkin: it seems like nouveau_dp_detect() doesn't get called
19:21imirkin: or i would have expected its prints to get printed
19:21skeggsb: unless it's an active adapter, it wouldn't be
19:22imirkin: i guess there's no auxch there
19:22skeggsb: it'll be treated as tmds by the driver, because, it is :)
19:22imirkin: skeggsb: but then the link_bw isn't set
19:22skeggsb: yes, because it's not DP
19:22imirkin: skeggsb: is it DCB_OUTPUT_TYPE_DP or TMDS?
19:22skeggsb: it'll be TMDS for a passive adapter
19:23imirkin: so then it's max_clock = get_tmds_link_bandwidth(connector);
19:23imirkin: which for a nvc3 will return 165MHz
19:23imirkin: it can't do dual-link right?
19:24marcheu: you can never do dual link with a passive adapter
19:24skeggsb: we need to fix that for hdmi to allow 330MHz single-link, or whatever it is
19:24skeggsb: i thought i fixed that ages ago, but apparently not
19:24imirkin: oh, when did that happen?
19:24imirkin: is that hdmi 2.0?
19:24skeggsb: 1.4 i think
19:24imirkin: or can you do it with hdmi 1.4
19:24boxfire_: yeah its 1.4
19:25skeggsb: 1.3, 340MHz
19:25imirkin: so that's the problem then
19:25imirkin: boxfire_: you can still get a 1920x1200 mode into single-link i think... reduced mode
19:26imirkin: you'd have to set it manually
19:26boxfire_: yeah I can make a modeline. Still :(
19:26boxfire_: Time to go buy an active adapter it seems
19:26skeggsb: or we can fix the driver...
19:26imirkin: nouveau should be able to do it...
19:26imirkin: i didn't realize hdmi 1.3+ did 340mhz
19:27imirkin: skeggsb: as a hack, should it just be enough to make it return 340000? or is there more to it?
19:27boxfire_: 3840x2160@30 297 MHz, binary blob is fully willing to do it
19:27skeggsb: imirkin: it's never been tested, i don't *think* there'll be anything else to do, but i'm not certain
19:28imirkin: boxfire_: give it a shot? :)
19:28boxfire_: ill ginuea pig, as soon as I learn how to spell that damn word
19:28imirkin: just don't try to plug DVI in and expect it to do 680mhz ;)
19:29marcheu: skeggsb: if you use the tmds in DVI mode you remain limited to 165 by the DVI spec. so you have to detect that at runtime
19:29skeggsb: yeah i know
19:29marcheu: so.. there is more to do
19:30skeggsb: well, i meant for a hack to get it working for boxfire_ :)
19:31skeggsb: also will want to edit engine/disp/nv50.c line 1547 and remove the condition that sets the sor to dual-link mode - probably
19:32skeggsb: if it works, i'll write a proper patch shortly
19:33boxfire_:rebooted with old module installed XD
19:40boxfire_: hmm it is not successfully setting the modes
19:41boxfire_: no output on dmesg when it fails, just a flicker on the screen
19:41imirkin: is it listing them though?
19:41boxfire_: yes it is
19:41imirkin: progress ;)
19:41skeggsb: boxfire_: did you see my comment about what else to edit?
19:42boxfire_: skeggsb: I did not, looking
19:47boxfire_: skeggsb: commenting out the if statement to set the dual link flag did not make it work
19:56boxfire_: when I set the mode to something like the 1280x960, then I try to set the mode back to the 3840x2160 eventually the machine becomes unresponsive in X, but no log output of any kind
20:20mogorva: imirkin: Hi-ho! Are you suggesting that all the issues in bug #91232 are originating from wine (even though your patch fixes them)?
20:21imirkin: mogorva: well, wine is doing something undefined
20:21mogorva: in their GLSL code, right?
20:22imirkin: they set gl_FrontColor but not gl_FrontSecondaryColor in the vertex shader
20:22imirkin: and then they use gl_SecondaryColor in the fragment shader
20:23imirkin: chris, who knows a whole lot more about GL than i do, told me that this is undefined
20:23imirkin: mesa appears to agree
20:25mogorva: how come is that OK with the blob?
20:26imirkin: it probably forces it to be defined to 0,0,0,1 or something
20:30mogorva: thanks for your hard work investigating and fixing all those bugs I reported so far :)
20:30imirkin: mogorva: hehe np. looking at the tomb raider one now
20:31imirkin: mogorva: thanks for testing nouveau out so extensively ... the thing is that most driver devs don't actually play a lot of games :)
20:32imirkin: mogorva: looks like an alpha- or depth-test related issue
20:33imirkin: the issue is so far into the trace that it's annoying... and trim doesn't work (at least not easily)
20:38mogorva: on the tomb raider case i should have mentioned that i see lots of these in the terminal: WARNING: out of code space, evicting all shaders.
20:38imirkin: yeah, i see them too
20:38imirkin: the thing has gynormous shaders
20:38mogorva: and 'WARNING: value %xxx not uniquely defined' too
20:39imirkin: which i'm moderately sure are incorrect... i've looked into them in the past
20:39imirkin: i think the warnings are coming during the out-of-ssa pass, at which point the non-unique thing can happen
20:42boxfire_: skeggsb: anything else to try or should I give in and get an active adapter?
20:50mogorva: imirkin: what's your opinion, should I refrain from reporting bugs in games that run in Wine (due to the probability that the error comes from wine itself)?
20:50imirkin: mogorva: well, the first bunch were actually bugs in nouveau. and the bugs in wine should be tracked down too
20:50imirkin: esp if they work on the blob
20:51imirkin: specifically if the nouveau-generated traces replay ok on the blob
21:03boxfire_: skeggsb: I just rebooted to windows to confirm the DP->HDMI passive adaptor works in the 297 MHz pixel clock
21:04imirkin: yeah it should def work
21:04boxfire_: I dont know anything about nouveau / DRM in general as I have only done graphics programming for applications, but I am certainly willing to experiment
21:05skeggsb: boxfire_: if you can file a bug report, and a log (after the patches you did before) with a full "log_buf_len=1M nouveau.debug=trace" log attached, i'll take a look when i'm able to
21:05skeggsb: boxfire_: you might need to re-ping me occasionally, i'm rather busy atm so might forget
21:09boxfire_: skeggsb: okay no problem. I am leaving for about an hour in a moment here to pick someone up, but ill be back later to file a bug
21:09skeggsb: no rush :)
21:19boxfire_: skeggsb: it seems 1M wasnt enough, the log starts in the middle of a dump of things like RAM_RESTRICT_ZM_REG_GROUP
23:10boxfire_: skeggsb: https://bugs.freedesktop.org/show_bug.cgi?id=91236