02:33 imirkin: milesrout: what sort of contribution are you looking to make?
02:39 imirkin: pmoreau: anyways, my inclination is to just push my branch and then shuffle code around later as use-cases arise, rather than trying to get it "perfect" in my branch. let me know if you disagree.
02:44 milesrout: imirkin: from what I gather from the nouveau website, hardware-accelerated video decoding doesn't work well on GM200 cards, is that right?
02:44 imirkin: milesrout: well, s/well/is not implemented/
02:45 milesrout: I'd be interested in contributing to that effort, I have a GM200 card.
02:45 imirkin: starting with GM107 they changed the engine around. allegedly it should still take the data in largely the same format, but with some obvious differences
02:46 imirkin: and note that you wouldn't be "contributing to that effort" as much as "performing that effort" - no one's currently working on it.
02:47 imirkin: with that in mind it should be a lot more tedious than it is hard. hopefully. first you need to figure out how to operate the video engines - the previous (kepler) generation had a falcon processor that was expected to service requests on each of the 3 "sub" engines. we never RE'd anything regarding that and just reused nvidia's blobs.
02:48 imirkin: [well, a bunch of RE was done on VP1 and VP2, but not the newer engines]
02:48 imirkin: starting with maxwell, there's a single combo engine which handles the bitstream, video decoding, and post processing logic
02:48 imirkin: previously these were each in their own engines
02:49 imirkin: (BSP, VP, and PPP, respectively)
02:50 imirkin: you can find some code from early in my VP2 RE efforts from a while back, it won't be useful as-is, but could provide some inspiration for some approaches - https://github.com/imirkin/re-vp2
03:02 milesrout: thanks
03:03 milesrout: if nobody is working on this, is that just that you don't have enough manpower, or nobody is really interested in working on it, or what?
03:38 milesrout: I'm going to go read all of this stuff https://nouveau.freedesktop.org/wiki/IntroductoryCourse/
04:35 milesrout: what specifically is 'reclocking'
04:36 milesrout: oh 'manual performance level selection'
12:19 dboyan: imirkin, please take a look at Bug 99532, I think I've found its root cause.
12:25 dboyan: Although atomic operation handling in nouveau is quite different with nvidia, I see nothing wrong with it. The problem lies within depth texture sampling
12:54 pmoreau: imirkin: That seems perfectly reasonnable. :-) I will have a run of your patches tonight, and see if I can review any of your patches.
13:56 nailyk: hi. Sorry askinging this, but any news on https://bugs.freedesktop.org/show_bug.cgi?id=94757 ?
14:00 dhoelzer: Good morning! I've read the FAQ... Yet, I'm wondering if there's an easy pointer to any documentation that has been generated that would allow me to simply initiate something like a cudaMemcpy from system RAM to VRAM for a backbuffer in a custom OS project..
14:00 dhoelzer: I can go and just read the source, but it seemed wiser to ask first.
15:03 pmoreau: :-/
15:05 pmoreau: The switch statement is a PITA for the linking, because in order to iterate over the ID of the case blocks, I need to know the size of the variable. But I do not have a direct pointer to the type of the variable, so I need to keep track of all types, and all variables created throughout the program… --"
15:06 RSpliet: pmoreau: size of what variable?
15:07 pmoreau: The variable used in the switch statement, i.e. `foo` in `switch (foo) { case 42: ... } `
15:08 RSpliet: how does that differ from a regular if-[else if]*-[else]? block?
15:09 pmoreau: The SPIR-V opcode looks like `OpSwitch | nbr_args | selector_id | default_bb_id | literal | case_bb_id | literal | case_bb_id | ...`
15:10 pmoreau: So, if you want to access the id of the first case BB, you need to know how many words the literal takes, and that is defined by the size of the variable referenced by selector_id.
15:11 pmoreau: An if-else block, will look like `OpIf | nbr_args | cond_id | if_bb_id | else_bb_id` where else_bb_id is optional, but you can guess its presence from the number of arguments
15:11 pmoreau: (For the if-else block, the opcode is from the top of my head).
15:12 RSpliet: okay, the difference kind of makes sense... not sure what fall-through looks like in the SPIR-V case
15:12 pmoreau: I guess the two cases refer to the same case BB id.
15:12 pmoreau: But I haven't checked
15:12 RSpliet: that wouldn't make sense
15:13 pmoreau: Ah, true
15:13 RSpliet: case 1: do something; case 2: do something more; break;
15:13 RSpliet: case 1 should execute both bbs
15:14 RSpliet: so the case 1 bb should unconditionally continue its control flow in the case 2 bb
15:14 pmoreau: Then, case 1 BB will branch to case 2 BB, and literal 1 will refer to case 1 BB and literal 2 to case 2 BB
15:14 kattana: is opencl harder than opengl to complete?
15:14 RSpliet: kattana: yes and no. It's mostly just very different
15:14 pmoreau: gtg, it's boarding time
15:14 pmoreau: bbl
15:15 RSpliet: but considering opengl is pretty much complete*, that's not a major challenge anymore :-D
15:15 pmoreau: :-D
15:15 RSpliet: pmoreau: we can talk about this kind of stuff a bit more tonight if you like
15:15 RSpliet: although I might have to ask you to reiterate over the problems you face
15:16 RSpliet: (refreshing my compiler knowledge as we speak by supervising parsing/lexing and following lectures on optimising compilers :-P)
15:47 MarcinWieczorek: Hello. I'm getting various errors on dmesg. My screen flickers and also Xorg hangs, I don't know if that's related yet. http://sprunge.us/BJXF
15:52 RSpliet: MartinWieczorek: you seem to have filtered out some vital information
15:53 RSpliet: like your kernel version and boot params. We prefer to do the filtering ourselves
15:53 MarcinWieczorek: cool
15:53 MarcinWieczorek: http://sprunge.us/STFV
15:53 RSpliet: Better, thanks
15:54 MarcinWieczorek: I thank you.
15:54 RSpliet: do you know the version of libdrm you're using?
15:55 MarcinWieczorek: 2.4.75
15:56 RSpliet: MarcinWieczorek: again new... mmm, just for completeness, could you check the version of the nouveau "ddx" please?
15:57 MarcinWieczorek: What's DDX?
15:57 RSpliet: the X.org driver for nouveau
15:57 MarcinWieczorek: How can I check that?
15:57 RSpliet: that being said, I find the presence of a "java" application in your logs suspicious, considering Java is notoriously bad with multithreading and nouveaus libdrm and/or mesa is not thread safe
15:59 RSpliet: MarcinWieczorek: I think that depends on your distribution, should be a package
15:59 MarcinWieczorek: What can I do about it?
15:59 MarcinWieczorek: I'm using nouveau from git, fairly new
15:59 RSpliet: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/ you mean?
16:00 MarcinWieczorek: I think
16:00 RSpliet: Those unreleased-but-three-months-old changes make the difference between using the nouveau module and "GLAMOR" (a generic driver with OpenGL back-end), could make a difference in your case
16:00 RSpliet: (where the nouveau module would be the good guy ;-))
16:01 MarcinWieczorek: Ok what can I do about it?
16:01 RSpliet: As for threading related issues, unfortunately we don't have a fix for that yet. It's a rather big change to the existing code base and hard to judge exactly how big would be "big enough"
16:01 RSpliet: check your Xorg log to see whether you're using nouveau or the generic modeset driver
16:04 MarcinWieczorek: Want to take a look at the log?
16:05 RSpliet: please
16:06 MarcinWieczorek: http://sprunge.us/fcAY
16:07 RSpliet: Nouveau it is... sad, I was hoping for an easy fix, but on the bright side your set-up is correct
16:08 MarcinWieczorek: Oh that was unexpected. It's usually my fault
16:10 RSpliet: not with these kind of errors. I suspect these are serious bugs in nouveau which may or may not be the result of threading
16:10 RSpliet: Unfortunately this goes slightly beyond my expertise... which java program were you running by the way?
16:10 MarcinWieczorek: What information can I provide to help?
16:10 MarcinWieczorek: It might be either Minecraft or Intellij
16:10 MarcinWieczorek: Or dbeaver
16:12 RSpliet: I'm guessing minecraft. karolherbst: are you aware of issues with recent minecraft on nouveau?
16:13 RSpliet: (sorry, going slightly beyond my expertise here. I can help you with basics but unfortunately have too little time to keep up with the real issues O:-) )
16:13 karolherbst: no
16:13 karolherbst: RSpliet: it's like 2 years ago that I touched it the last time
16:13 MarcinWieczorek: I was having various glitches when using Minecraft with nouveau, I've been advised to use latest from git and it helped.
16:13 karolherbst: all I know is, that minecraft uses lwjgl
16:14 karolherbst: MarcinWieczorek: did you test the latest release of mesa vs git?
16:14 MarcinWieczorek: RSpliet: Thank you for your time anyway. I've noticed flickering, I'm busy and I have lots of stuff open, I would restart the PC and see if the flickering occurrs because of Minecraft or something
16:14 RSpliet: MarcinWieczorek: flickering does sound odd, a dual full HD should be no problem for nouveau
16:15 karolherbst: uhm
16:15 karolherbst: this is kepler, right?
16:15 RSpliet: 1st gen Maxwell
16:15 MarcinWieczorek: I don't have mesa from git, I could not build it, I don't remember. I'm using mesa 13.0.4
16:15 karolherbst: RSpliet: even worse
16:15 karolherbst: I guess flickering is to be expected then
16:15 RSpliet: why?
16:15 karolherbst: depends on the flickering
16:15 MarcinWieczorek: The flickering is very subtle I'd say. Hardly noticeable
16:15 karolherbst: because afaik there is no vblanking on kepler/fermi+
16:16 MarcinWieczorek: 750Ti
16:16 MarcinWieczorek: So Maxwell as far as I know
16:16 karolherbst: MarcinWieczorek: did you try to reclock the gpu?
16:16 karolherbst: on 4,10
16:16 MarcinWieczorek: I can try it
16:16 karolherbst: I had weird display issues on my tesla gpu which went away with higher clocks
16:17 karolherbst: MarcinWieczorek: are you on a 4.10 kernel?
16:17 MarcinWieczorek: yes
16:17 karolherbst: ahh you are
16:17 karolherbst: good
16:17 karolherbst: you should be able to change the pstate without issues then
16:17 karolherbst: will give you a significantly perf boost as well
16:17 MarcinWieczorek: Yeah I know how to do that
16:18 karolherbst: so you have 2 FullHD displays running?
16:18 karolherbst: could be that the stock memory clock isn't enough for it
16:18 RSpliet: karolherbst: those two monitors require less than 1GB/s, should work fine in low perf modes...
16:18 karolherbst: RSpliet: you would be surprised
16:19 RSpliet: 1920*1080*4*60*2 / 1048676 ~= 950...
16:19 MarcinWieczorek: I have two displays. Want exact models or have you found them?
16:19 karolherbst: MarcinWieczorek: no, just try out higher pstates
16:19 karolherbst: if that works, it's fine
16:20 karolherbst: RSpliet: on my MCP79 fullHD was also too much on a certain connector type
16:20 karolherbst: on lower pstates
16:20 karolherbst: had to use the highest one
16:20 RSpliet: karolherbst: yes, but an MCP79 doesn't have a 128bit GDDR5 bus
16:20 karolherbst: it hast 17 GB/s bandwidth though
16:20 karolherbst: *has
16:20 RSpliet: seriously, it can deliver all required data at like 32MHz
16:20 karolherbst: I know
16:21 karolherbst: I am not saying it shouldn't work theoretically, but practically
16:21 RSpliet: MCP79 is sharing that bus with the CPU...
16:21 MarcinWieczorek: I can't see the flickering, I might have gotten used to it. I'll let you know.
16:21 MarcinWieczorek: Do you think something from my logs can be related to xorg crashes?
16:22 karolherbst: RSpliet: I am aware, it could be just, that nouveau does something wrong. Anyway, changing pstates did _change_ the issue I had
16:22 karolherbst: allthough vmem clock wasn't changed at all
16:22 karolherbst: because there is none
16:22 karolherbst: there are other engines related here as well
16:22 RSpliet: not to mention I forgot that GDDR5 is DDR< so a 16MHz DRAM clock would be sufficient... and generally the clock doesn't go below 135MHz ;-)
16:22 MarcinWieczorek: http://sprunge.us/fGNF
16:22 RSpliet: there's 90% headroom mate...
16:22 karolherbst: yeah
16:23 karolherbst: but I just remembered, that vram wasn't the issue, silly me
16:23 karolherbst: ID 0x3 Core 150MHz Memory 0MHz Shader 300MHz Vdec 150MHz Dom6 200MHz Voltage 90[*10mV] Timing 255 Fan 100 PCIe link width 16 --
16:24 karolherbst: mhh well, the lower doesn't matter anyway
16:24 karolherbst: -- ID 0xe Core 350MHz Memory 0MHz Shader 800MHz Vdec 350MHz Dom6 350MHz Voltage 90[*10mV] Timing 255 Fan 100 PCIe link width 16 --
16:24 karolherbst: -- ID 0xf Core 450MHz Memory 0MHz Shader 1100MHz Vdec 450MHz Dom6 400MHz Voltage 101[*10mV] Timing 255 Fan 100 PCIe link width 16 --
16:24 karolherbst: 0xe made parts of the screen cut off
16:24 karolherbst: 0xf didn't
16:24 karolherbst: Dom6 maybe?
16:24 karolherbst: no idea though what the exact issue was
16:26 karolherbst: I should look into it again at some point
16:27 RSpliet: don't forget to skip 4.8 to 4.10rc7, they break HDMI
16:27 RSpliet: (fix was merged in 4.10rc7)
16:27 RSpliet: MarcinWieczorek: sorry for going off on a tangent
16:27 MarcinWieczorek: What breaks HDMI?
16:28 RSpliet: don't worry, not your GPI
16:28 RSpliet: *GPU
16:28 MarcinWieczorek: Yeah not literally I guess
16:28 MarcinWieczorek: Just asking :p
16:34 RSpliet: MarcinWieczorek_: regression creeped in for MCP77 and MCP79 (NVIDIA ION, some Macbooks) in kernel 4.8 which wasn't chased aggressively enough until Fedora started shipping (and I got affected myself)
16:34 RSpliet: As for your problem: we have a bugs page that explains the kind of information you can gather to report a bug on the freedesktop bugzilla
16:34 RSpliet: I'd appreciate it if you could report so the smart people can take a look in their time(zone) ;-)
16:34 MarcinWieczorek_: Yeah, I could not even build that test utility
16:35 RSpliet: https://nouveau.freedesktop.org/wiki/Bugs/
16:35 RSpliet: There's no need to worry about VBIOS right now, the kernel log and xorg.0.log would be helpful to attach
16:35 MarcinWieczorek_: I'll report it there. Thank for your time
16:36 RSpliet: Consider it a bug in the 2D driver for now
16:36 MarcinWieczorek_: cool
16:36 RSpliet: it would be very helpful if you could find out whether it's the Java application that triggers issues, and which one it is (I suspect Minecraft, but would be good to be sure :-))
16:37 MarcinWieczorek_: Yes I'll try it
16:37 karolherbst: RSpliet: yeah I know. I found the issue while playing with bens atomic patches, but this issue also ocurse before 4.8
16:38 RSpliet: And sorry you're having a bad experience... If you want I can propose some scapegoats
16:39 RSpliet: (seems to be politicians' preferred course of action to deal with problems currently)
16:45 MarcinWieczorek_: I'm used to the fact that nothing works on Linux
17:04 nyef`: ... Am I likely to have any more trouble with a GM107M than I would with a GK107M or a GF119M?
17:06 NanoSector: holy balls my 950M reclocks on 4.10
17:06 NanoSector: no issues
17:07 MarcinWieczorek_: Good for you, it works good for me too.
17:07 NanoSector: I kind of expected it to follow thep ath of my 750M and have all sorts of random issues. I guess this laptop is more sane
17:07 MarcinWieczorek_: I can share a cool script if you use i3
17:08 nyef`: (I need to get a new card to work with anyway, so I'm looking at options, and the probably-a-gm107m is actually at a workable price point.)
17:20 NanoSector: MarcinWieczorek_, I use GNOME, but thanks :)
17:23 NanoSector: ok at least suspend and resume works, but if I then try to use the card my system locks up :P
18:31 NanoSector: "DRM: failed to idle channel 0 [DRM]" after resume, and power usage stays high
19:35 pmoreau: RSpliet: Sounds good. :-) I got some ideas about it during the flight, but I’ll have to remember them. :-D
19:36 pmoreau: I need some time to have dinner and finish a pull request for CMake, but then we can have another look.
20:06 mart193: generally quite nice time on systems, i have gotten everything i need to work
20:08 mart193: used couple days for fixing up all the computers i have, turned out everything worked out of the box, when i googled a bit
20:13 mart193: as all my comps are stable, it seems the hard work has been shown to materialize recently, chrome also works finally on all drivers, and yeah my thinpc worked all nicely too, it had iommu too, this gallium stuff is finally in a good shape to use and maybe minorly hack on
20:27 mwk: imirkin: you there?
20:30 mart193: yeah i did not only try hw video decoding with nouveau, i get my card back, and may try then
20:32 mart193: but used it for a while, and it was stable otherwise, have tested many cards now, all are stable, different vendor ones
20:39 mart193: connected HDMI and kinda have office at home, to say good bye to excessive drinking, i know what to hack on also, i chat about it privately if there are questions, in case some mistakes are in the theory yet
20:43 mart193: i am not sure if someone has the answe, what is the atomicity or operational phenomen on indirect addresses across different instructions against the indirect operands?
20:43 mart193: is it atomic or non-atomic explicitly or implicitly?
20:55 mart193: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.725.2761&rep=rep1&type=pdf i'd actually bet on not-atomic, which is the only prequisite or requirement, and it would make sense more
21:07 mart193: https://www.hillsoftware.com/files/atari/jaguar/jag_v8.pdf page 134 is the only information i have found confirming my assumption
21:08 mart193: the data on indexed stores is not subjected to any score-board protection
22:11 imirkin: dboyan: i'll have a look. the fact that depth texture sampling doesn't work makes no sense. that said, we have had, over time, a collection of inexplicably-failing depth-related tests. perhaps it's something to do with that.