01:48 mangix: nouveau 0000:01:00.0: disp: dcb 6 type 8 unknown
01:48 mangix: anyone know what that is?
01:51 mangix: DRM: Pointer to flat panel table invalid :(
02:10 nyef`: Okay, got a very plausible line on getting the 3D modes to appear at the DRM modeset level.
02:24 mangix: so DCB_CONNECTOR is type 70 is unknown
02:24 mangix:thinks it's thunderbolt
02:29 nyef`: mangix: "Virtual connector for Wifi Display (WFD)".
02:30 nyef`: Doesn't thunderbolt count as a mini-displayport connector, or did that change at some point?
02:30 mangix: no idea
02:30 mangix: actually you might be right
02:31 mangix:has no idea what he's doing
02:31 nyef`: Should be somewhere in the 0x56 - 0x59 range?
02:32 nyef`: For the benefit of those of us who don't know what you're doing, either, what *are* you doing? (-:
02:32 mangix: looking at these error messages in the code. trying to make sense of them
02:33 nyef`: So, what's the context? You've got some hardware, and some error messages, possibly some undesired behavior?
02:33 mangix: the weird thing is, i have a GM204 GPU and i'm getting errors defined in nv50_display.c
02:33 mangix: bah this is confusing
02:34 nyef`: That seems reasonable once you know that there was a major change to the hardware design as of nv50, and everything after that builds on the new paradigm.
02:34 nyef`: A lot of stuff in nouveau is named after the first hardware version to use it.
02:34 mangix: Ah ok
02:34 nyef`: (Well, as far as I've been able to tell, at least.)
02:35 mangix: I was thinking more of mesa and how nv50 is the pre-fermi driver
02:36 mangix: this laptop is quite interesting TBH. Brightness control works on nouveau and is totally broken with proprietary driver
02:37 mangix: proprietary driver also can't turn the screen off. lulz
02:54 mangix: alright
02:55 mangix:thinks DCB_OUTPUT_eDP = 0x4 and mDP = 0x8. need to verify
02:55 nyef`: Okay, so I drmSetClientCap() for DRM_CLIENT_CAP_STEREO_3D, and I can see the 3D modes from userspace now.
02:55 nyef`: mangix: http://http.download.nvidia.com/open-gpu-doc/DCB/2/DCB-4.x-Specification.html
02:55 mangix: yeah i'm looking at it
02:56 mangix: they list both as reserved
02:56 nyef`: Okay, wasn't sure if you had it or not, given your earlier suggestion about type 0x70.
03:02 mangix: lawl one of the errors is guarded by #ifndef __powerpc__
03:04 nyef`: Okay, next step... finding the i915 X drivers.
03:08 nyef`: ... and nothing. No mention of DRM_CLIENT_CAP_STEREO_3D.
03:20 nyef`: Ah, intel-gpu-tools it is.
03:44 nyef`: So, rough plan, now that I have a userspace example to work to: Get the kernel side into shape for 3D modesetting.
03:45 nyef`: Once that's done, and the 3D modes actually work, then concentrate on getting the X driver working properly in 3D (which is to say, in 2D over a 3D framebuffer).
03:45 nyef`: Then mesa.
03:46 nyef`: On the other hand, seeing how much (if any!) support there is in mesa already would help to scope some of this mess.
10:19 GaivsIvlivs: Is renouveau still a thing?
11:56 RSpliet: we've been using renouveau-next-next for years...
12:20 karolherbst: what's renouveau? :D
12:50 gnarface: would it be expected that the nouveau driver could do hardware decoding for steam in-home streaming on linux? does anyone know?
12:50 karolherbst: gnarface: you mean like using nvenc?
12:50 karolherbst: ohh wait
12:50 karolherbst: decoding
12:51 gnarface: karolherbst: vdpau is the only possible option for nvidia hardware as far as i know, but i could be wrong
12:51 gnarface: vdpauinfo does seem to show that its working
12:52 gnarface: i installed the 32-bit libraries matching the 64-bit ones (that i know of) that steam seemed to want
12:52 gnarface: no luck
12:52 gnarface: just wondering if anyone else had succeeded
12:52 gnarface: i figure i'm probably just missing a package or a symlink
12:55 marduk: i am today entering with tor, i bet you have ways to block it somehow, just a little bit technical stuff for today, probably final thoughts
12:58 marduk: so i was thinking what is the hw mechanism to come back to a memory operation inside instruction queues..group of warps take it, as the data is not available they all threads will skip it, we keep them in i-buffers with a recursion
12:58 marduk: but hw wise what is the mechanism to queue it for execution once the data comes available, i think hw has a scoreboard for that
13:05 marduk: it is important in sense, i have to reread some notes, whether..you know the skipped commands would be thrown out of queues or kept in, because queues could be busted unexpededly otherwise, and in that case hw would fot entire i-buffer flush
13:20 gnarface: ah ha! firmware: failed to load nouveau/nv84_xuc00f
13:20 gnarface: maybe that's the problem
13:24 marduk: i knew it once, but have forgatten, complex is it, because it's essentialy exactly the same instruction that would be run on different elements, will the scoreboard be decoupled then, needs reading
13:27 gnarface: i wonder if i should be trying to use va-api instead
13:33 marduk: in my opinion scoreboard would give free lights to anything that by programmers fault, is decoded before that the reg was written, and it would be just NOP
13:34 marduk: but if someone were to have a long memory operation and not ready bit is set i.e instruction coming later is blocked cause of long latency op in flight, then those will be kept in queues
13:38 marduk: would need to do a test to confirm this hypothesis, starting a shader with an instruction with all of the operands having unitinialized value, as far as i see , it would finish and do nothing, and remove the instruction as it was invalid from i-buffer too
13:44 karolherbst: gnarface: you need to extract the firmware from the binary driver
13:44 karolherbst: gnarface: there are scripts for that
13:45 karolherbst: gnarface: https://nouveau.freedesktop.org/wiki/VideoAcceleration/ "firmware"
13:47 marduk: wikipedia says, that some instruction set have no NOP instruction, and use NOP emulation with different instructions doing the equivalent
13:48 gnarface: karolherbst: yea, i just did that, but thank you for looking out for me. i guess the real thing is that i'm bewildered this isn't in any debian package already
13:49 gnarface: karolherbst: whether it actually works or not however, that test will have to wait until tomorrow i guess
13:49 gnarface: (later today, technically)
13:50 gnarface: karolherbst: it doesn't complain about firmware in dmesg now anyway. i think it says a bunch of other new stuff instead. on that example on the nouveau.freedesktop.org, they have a specific nvidia driver version they extract from. i picked that one, but should i have picked the latest version instead?
13:50 marduk: it may reaise some of the exceptions, for instance malformed arithmetic like division by zero
13:50 gnarface: karolherbst: i picked 325.xx or whatever it was, like their example
13:51 marduk: but i bet it is still as cheap as NOP
14:55 marduk: https://pdfs.semanticscholar.org/40b3/b66225fc03097a55c982c7b91a0f72fc6bea.pdf
14:58 marduk: demonstration of that theory on x86, best to do little program tomorrow on gpu too, zero operanded operation as flush-to-zero and denormals are zere ftz and daz capability of todays processors
14:59 marduk: if excpetion is raised that some value is a Nan, then processor changes the values to zeros and makes the arithmetic for free
15:14 karolherbst: mwk: did you want to also include your rnndb changes into that commit?
15:24 RSpliet: karolherbst: renouveau-next-next abbreviates to rnn...
15:24 mwk: oh fuck.
15:25 mwk: yeah, that wasn't supposed to go in
15:25 mwk: ah well, too late
15:31 mwk: RSpliet: actually, it's rules-ng-ng :p
16:04 marduk: no more rambles...
16:04 marduk: tried to find more information, but failed generally, should ask from #asm, in verilog there are 0 1 and z states, confuses me
16:05 marduk: uninitialized is z, but generally if 0 remains 0 on operands it will be skipped too
16:06 marduk: the whole instruction that is
16:09 mwk: well, that took some time
17:16 imirkin: gnarface: the 325.x firmware is fine
17:16 imirkin: gnarface: note that if you have a G92 it will hang your gpu
17:16 imirkin: gnarface: but it should work OK on all other chips
17:17 karolherbst: mhhh
17:17 karolherbst: imirkin: the g92 is mostly configued like a g8x GPU
17:17 karolherbst: maybe it is related to that, or the g92 is indeed an oddball
17:18 imirkin: karolherbst: all g84-g96 have the same video decoding unit - the VP2 generation
17:18 imirkin: [and g200 as well; g98 has vp3]
17:18 karolherbst: this might be true, but I was more refering to other subdevs/engines
17:18 imirkin: the firmware loads
17:18 imirkin: and basic things work
17:18 karolherbst: like g92 uses the nv50 bus implementation and g94 uses the g94 one
17:18 imirkin: but as soon as we try to do any actual decoding, the engines hang.
17:19 karolherbst: disp as well
17:19 imirkin: i don't see how that's relevant to the video thing.
17:19 imirkin: anyway, i spent some time staring at traces, and never found anything useful
17:19 imirkin: and i was never able to get my hands on a G92 myself so i couldn't fiddle with it myself
17:20 karolherbst: mhh, maybe there are also some strange things going on in userspace where a g92 is also treated more like a g8x. Just a thing I noticed
17:21 imirkin: ok. just so we're clear, all g8x and g9x have the same video decoding engine. and that is the engine that hangs.
17:21 karolherbst: okay
17:21 imirkin: [except g80, which has the nv41+ engines, and g98 which has the next gen engine which is totally different]
17:23 imirkin: it could be something subtle, like messing up memory types, which other configurations tolerate
17:23 karolherbst: might be, yes
17:23 imirkin: that was the reason that vp3/vp4 would hang on tesla's
17:23 imirkin: but ... it works on all the other chips =/
17:24 imirkin: [which have an identical engine which takes identical firmware]
17:25 karolherbst: we really need more devs to look into stuff like that :(
17:26 imirkin: yeah, and that one's #75 on the list of things that need looking into
17:26 karolherbst: exactly
17:27 karolherbst: and we have the problem, that it isn't exactly easy for new devs to know how and where to start, which is like the thing I get toled 90% of the time
17:27 karolherbst: *told
17:28 imirkin: well, if you can find me anyone interested in video decoding, i could help them get started with the h264 issues.
17:28 karolherbst: well sure, we can do everything over IRC, but this is sup optimal
17:31 imirkin: ok
17:31 imirkin: well i'm not gonna write a ton of docs for no one to read
17:31 karolherbst: that's true
17:32 imirkin: i'd rather take that knowledge to the grave :)
17:32 nyef`: Heh.
17:32 karolherbst: but we could write something if somebody is interested and instead of just telling stuff in IRC, we should store it elsewhere so that it can be read up again later
17:32 karolherbst: doesn't need to be perfectly written or something
17:32 karolherbst: even the IRC dumps would be okayish
17:32 karolherbst: but
17:32 karolherbst: we should store it categorized and everything
17:33 nyef`: While I'm fairly sure that I'm not currently interested in video decoding, I'm ready to take a break from wading through the quarks of atomic modesetting, so I'll ask: As an end-user, what benefit would I derive from working video decoding?
17:34 karolherbst: nyef`: less CPU load while decoding videos
17:34 karolherbst: if the implementation is good, even higher power efficiency
17:34 imirkin: nyef`: the intense satisfaction of knowing that you're using fixed function hardware instead of generic hardware
17:34 nyef`: So... my DVDs won't be as affected by high CPU load?
17:35 imirkin: heh. well DVD's are pretty much free to decode on modern CPUs
17:35 imirkin: but your 1080p, 40mbit h264-encoded blurays will not impact cpu usage at all.
17:35 karolherbst: nyef`: today it's more like about 4k videos
17:35 karolherbst: imirkin: 4k :p
17:35 karolherbst: nobody talks about 1080p anymore
17:35 karolherbst: :D
17:35 imirkin: obviously i do! :p
17:36 nyef`: Okay, so if and when I end up with some bluray disks, I might care. Good to know!
17:36 chillfan: blueray is evil :p
17:37 karolherbst: nyef`: video streams
17:38 nyef`: karolherbst: So... youtube, vimeo, google hangouts, and twitch?
17:39 karolherbst: those usually provide h.264 videos
17:39 karolherbst: and I think they also support 4k, or at least some of them
17:39 karolherbst: youtube does
17:39 nyef`: Okay, now that's a bit more interesting.
17:39 chillfan: since the reclock patches I am finding video is playing fine for me without external firmware
17:40 imirkin: also fyi, h264 is the only one with issues - mpeg2 and mpeg4p2 work fine
17:40 karolherbst: nyef`: I think on kepler gpus nouveau should be able to decode 4k h.264 videos without issues
17:40 karolherbst: there are a few general h.264 issues
17:40 karolherbst: but it shouldn't be related to the resolution
17:40 imirkin: there are artifacts on some h264 videos. orbea gave me a good test one
17:40 nyef`: ... More interesting, but not as interesting as getting stereo working.
17:40 karolherbst: or this :D
17:40 karolherbst: but this will be a lot of work I figure
17:43 nyef`: I want the kernel side of HDMI stereo to be in 4.11.
17:44 karolherbst: you have ~6 weeks
17:44 nyef`: Plenty of time for the technical side.
17:45 karolherbst: I meant with the implementation and everything
17:45 karolherbst: and review process
17:45 nyef`: Right.
17:45 karolherbst: so your code should be ready in about 3 or 4 weeks, otherwise it won't get in most likely
17:47 nyef`: So noted.
17:47 nyef`: Still seems doable.
17:48 karolherbst: it sure is doable, but I actually wanted to land my reclocking patches in 4.7
17:48 karolherbst: took a bit longer :p
17:48 nyef`: Fair enough. (-:
17:48 karolherbst: and it was implemented by then, but reviewing just took so long
17:49 nyef`: And just getting something working locally would be a huge win, TBH.
17:49 karolherbst: sure
17:49 karolherbst: the REing work is very important
17:49 karolherbst: because if this is done, soembody else could also just implement it later
17:56 nyef`: Main thing I need to RE is the gk104 InfoFrame registers. And that can wait, since most of my test hardware is gt215. I probably also need to scare up a g84 to test with, but I don't expect any surprises there.
18:11 nyef`: And now I come to the point where I just have to ask... "what's nvif?"
18:12 nyef`: And, for that matter, what's cl5070?
18:19 pmoreau: nyef`: A display class
18:19 pmoreau: http://http.download.nvidia.com/open-gpu-doc/Display-Class-Methods/1/README.txt
18:22 pmoreau: All those methods should be available in rnndb, in NV_EVO_XXX, where XXX can be CORE, OVERLAY, BASE, CURSOR, OVERLAY_IMM
18:26 nyef`: Okay, that starts to make sense, but the given documentation and headers don't include cl5070.h itself?
18:29 pmoreau: No, but you have cl507a.h for the cursor channel doc, cl507b.h for the overlay immediate channel doc, etc.
18:29 mwk: nyef`: xx70 are software classes, they're implemented in the driver
18:30 mwk: so there's nothing to document
18:31 nyef`: Okay, and the kernel header files not matching up with the nvidia header files is also expected somehow?
18:31 nyef`: Does this mean that we're free to add and alter methods here?
18:41 karolherbst: nvidia header files?
18:42 nyef`: The ones from the same directory as the README.txt linked above.
18:42 karolherbst: I see
18:43 karolherbst: what is qmd?
18:43 karolherbst: uiuiui http://http.download.nvidia.com/open-gpu-doc/pascal/1/gp100-mmu-format.pdf
18:44 karolherbst: dropped support for 128kb pages, interesting. This was for the ppc stuff, right?
18:47 karolherbst: ohhh
18:48 karolherbst: mupuf: no idea how I missed this, but "Devinit scripts are signed and executed on the PMU so that these scripts can configure protected registers like thermal shutdown parameters."
18:54 nyef`: I guess my next question is, does anyone else know their way around this whole NVIF / NVKM thing, or is it basically just skeggsb ?
18:57 karolherbst: nyef`: nvif is the interface
18:57 karolherbst: and nvkm is where everything gets implement
18:57 karolherbst: but not for display
19:05 nyef`: Okay, nv50_display.c / nv50_hdmi_enable() invokes NV50_DISP_MTHD_V1_SOR_HDMI_PWR via nvif_mthd(). This is dispatched in nvkm/engine/disp/rootnv50.c / nv50_disp_root_mthd_(), and it ends up calling, in my example, nvkm/engine/disp/hdmigt215.c / gt215_hdmi_ctrl(). gt215_hdmi_ctrl(), among other things, trashes the HDMI InfoFrames.
19:06 nyef`: In nv50_hdmi_enable(), I can generate the InfoFrame data required, and I can easily enough hack up gt215_hdmi_ctrl() to do what I want with the data. How do I get the data from point A to point B?
19:07 nyef`: It seems likely that I need to either modify the current method or add a new one for this, but I have no idea what constraints are in play around the whole interface.
20:04 imirkin: nyef`: the general idea is that things outside of nvkm should use nvif_mthd to get things done
20:04 imirkin: nyef`: there's also some theoretical backwards compatibility concerns, but in practice, most methods aren't really fixed in stone
20:04 imirkin: so in theory you'd create a V2 of an interface and use that, but in practice, you can generally just keep modifying the V0 interfaces as long as there are no external users
20:04 imirkin: which, for 99.9999998347% of interfaces, there aren't
20:26 nyef`: imirkin: Okay, and is there a definitive list of externally-used methods, or even just of external users?
20:28 nyef`: I realize that there being an external user of NV50_DISP_MTHD_V1_SOR_HDMI_PWR is a little unlikely, but it's worth checking.
20:49 nyef`: Is the literal 0 in the calls to nvif_mthd() in nv50_display.c / nv50_hdmi_{en,dis}able() meant to be NV50_DISP_MTHD?
20:50 imirkin: nyef`: libdrm and mesa and xf86-video-nouveau are the only legit external users today
20:51 imirkin: the only thing i remember about those nvif calls is that they are too clever for their own good
20:51 imirkin: nvif_unpack is a macro btw
20:51 nyef`: Yeah, I was just about to get to nvif_unpack.
20:51 nyef`: And that list of legit external users means that I'm clear to do what I need here. Thank you.
20:52 imirkin: well, skeggsb may have different ideas. but i think the past he's fixed up methods too.
20:52 imirkin: nothing ever calls the disp methods externally though
20:52 nyef`: He's welcome to offer input here as well. (-:
20:52 imirkin: i guess what i mean to say is that his word is final while mine is not ;)
20:53 nyef`: As long as I'm somewhat unblocked here. I don't mind rewriting to order if necessary, but not having any direction at all didn't help. (-:
20:54 imirkin: ok, so the "0" gets stuck into args->mthd.method
20:55 nyef`: And that looks to wind up in nvkm/engine/disp/rootnv50.c / nv50_disp_root_mthd_().
20:55 imirkin: and i can't see where args->mthd.method is ever read out
20:55 imirkin: but it could be something subtle
20:55 nyef`: Yeah, the ioctl dispatch in nvkm/core/ioctl.c, IIRC?
20:55 imirkin: yeah maybe.
20:55 nyef`: Err... core/object.c?
20:55 nyef`: Maybe it bounces one to the other.
20:56 nyef`: The bit that gets me lost is not having any sort of overview documentation.
20:56 imirkin: i guess it's to distinguish disp_mthd_v0 vs disp_mthd_v1? i have no clue.
20:56 imirkin: just leave it alone for now.
20:56 imirkin: just assume it works.
20:57 imirkin: i've never understood the glue of all this stuff in any of ben's rewrites :)
20:57 nyef`: nvif_unpack(r,d,s,m,vl,vh,x)? Wha?
20:57 imirkin: so i'm used to just accepting this stuff as working and not worrying too much about it
20:58 nyef`: Okay, vl and vh are a version bound...
20:59 nyef`: r is some sort of accumulative return value?
20:59 nyef`: d and s are data and size.
20:59 imirkin: r is the return code
20:59 imirkin: which it will set on exit
21:00 nyef`: Yes, but it checks it on entry.
21:00 imirkin: yeah, and returns a new error code
21:00 imirkin: so you can have one check at the end
21:01 imirkin: instead of checking after every nvif_unpack call
21:01 nyef`: Hence "accumulative return value".
21:01 imirkin: ;)
21:08 nyef`: Okay, I think I see most of what this is doing, though I'm not sure that I can explain it yet.
21:08 nyef`: (So, clearly, I don't know what it's doing yet, but I'm at least getting some idea.)
21:14 nyef`: If x is false, then there is no more data expected, so if there's any left then fail with an -E2BIG. If x is true, then more data is possible.
21:17 nyef`: ... And NV50_DISP_MTHD_V1_SOR_HDA_ELD shows how to have a variable-length data block as a method parameter.
22:02 RSpliet: karolherbst: protip: Ben doesn't (/shouldn't) work over weekends, best ping him during the week if you don't want to end up in a long stream of e-mails to overlook ;-)
22:05 karolherbst: :(
22:05 karolherbst: damn
22:07 RSpliet: Makes me wonder if there might be a postfix plugin that can hold e-mails based on the receiver, to make sure it's sent only during receiver's working hours
22:11 karolherbst: RSpliet: I think I will just write an IRC bot
22:11 karolherbst: posting skeggsb all the pending stuff he got at noon
22:12 karolherbst: and he has to mark each thing as done seperatly :p
22:19 Jeansf: i was all wrong about that skipping with non-zero operand, hw did not do that
22:19 Jeansf: but i am working on a fix , i dunno if nvidia has similar instruction as...
22:20 Jeansf: V_CMPX_CLASS_F32 is the one that should fix for radeon, i think nouveau might have zero flags
22:30 Jeansf: i only guess, what this instruction does, i have not yet tested, it should cmp for positive zero, and broadcast it to all the threads
22:34 Jeansf: it also is capable of using or reading exec mask, so it might be some of the workaround
22:54 Jeansf: ah heck, i am totally broken today skipping with zero operand, i should had said earlier
22:55 Jeansf: anyways the idea behing that function was to release all the poller ds if original instruction were to get a zero onto one lane
23:57 mwk: ugh, Celsius
23:57 mwk: the NV10 is broken in so many ways
23:57 karolherbst: :D
23:57 karolherbst: that bad?
23:57 gnarface: nyef`: "what benefit would I derive from working video decoding?" you asked earlier, and it was overlooked in the discussion that the Steam "in-home streaming" feature could also benefit from this, to reduce latency and provide an overall better experience when using lower-end hardware for the client
23:58 gnarface: nyef`: (which is what i hope to use it for if i can get it working)
23:58 mwk: karolherbst: context switching on that thing is just *horrible*
23:58 mwk: so, there's the vertex buffer state
23:59 mwk: there's a format reg for each of the 8 vertex attributes