00:08 RSpliet: nyef: afaik that looks reasonable
00:12 nyef: Thank you.
01:35 iterati: hi, it's possible after a driver crash to recover without reboot via ssh from another machine ? Running gdm/gnome with wayland or X.
01:56 gnarface: iterati: maybe. if the hardware isn't froze, you could try to kill gdm and unload the nouveau module. then reload the module and restart gdm. it could work.
02:06 iterati: gnarface: thanks. I am giving nouveau another go. Since kernel about 4.6 or so, experiences many freezes, with "gr engine fault" etc. Let's hope now should be fine.
02:07 gnarface: iterati: there has also been a lot of action on mesa lately. so, just fyi, if you're upgrading your kernel to try to squash bugs, you should probably consider upgrading mesa too.
02:08 gnarface: (i can't tell you what version to use, but i know 17.x is in debian experimental now)
02:09 iterati: gnarface: yep, it's everything current, I used the nvidia driver for several months. If I experience hard locks due to nouveau I guess going to get back to it.... with wayland currently, let's hope that is more stable.
02:09 iterati: I use ~amd64 in gentoo, so it's as current as it comes, no prob about that. Just upgraded to kernel 4.10.9 too.
02:11 gnarface: outside of steam, nouveau has been very stable for me
02:12 gnarface: performance somewhat lacking though
02:12 gnarface: it really hates steam "big picture mode" for some reason though
02:14 iterati: performance will come eventually. Driver locks are unacceptable, though, for a mainlined one.
02:16 gnarface: yea, i agree, but steam for linux is just so cluelessly coded it's hard to tell really where the fault lies when it crashes or locks up
02:17 iterati: btw, in gnome the nvidia driver chokes for some reason (650 gtx). With nouveau reclocked the performance is acceptable.
02:18 gnarface: hmm. interesting
02:18 gnarface: how is nouveau in wayland for you? i havne't tried wayland \
02:20 iterati: I don't know why about the blob, it's invariable, multiple versions of gnome and I think in arch too before as well as in gentoo now.... but anyway, wayland testing it right now. No crashes so far.
02:24 Satchelboi: imirkin: Would you like to to leave a comment next to NVISA_SMxx declarations with the chipsets that were there before in case anyone needs to reference them for ease of use?
02:25 Satchelboi: Like "#define NVISA_SM30 0xe0 // GK104"
03:59 imirkin: Satchelboi: i'd like to have a enum sm_isa { SM10, SM20, SM30, SM35, SM50 }
04:01 Satchelboi: imirkin: Alrighty. Wasn't sure if anyone who find the comments useful, haha
04:01 imirkin: you can add comments like // Tesla, // Fermi, etc
14:19 leberus: hi people!
14:19 leberus: i'm about to be ready for sending a patch that fixes this https://trello.com/c/jMlCWGHs/173-hwmon-device-register-is-deprecated-please-convert-the-driver-to-use-hwmon-device-register-with-info
14:19 leberus: where should I send it?
14:21 dboyan_: leberus: nouveau@freedesktop.org
14:24 imirkin: leberus: nouveau@lists.freedesktop.org + dri-devel@lists.freedesktop.org
14:25 dboyan_: yeah, imirkin was right
14:26 dboyan_: I guess my mind is quite dumb at night
14:27 leberus: it's ok if i'm not subcribed? I tried to subscribe to nouveau@freedesktop.org, but never got the confirmation e-mail :(
14:27 imirkin: leberus: it's ok, it just means it'll get held for review before being posted
14:28 leberus: ok, thanks a lot ;)!
14:29 imirkin: things make it through within 24h, often much less
14:30 leberus: not a problem
14:30 leberus: if something is wrong with the patch, am I gonna get some feedback back? (since i'm not subcribed)
14:31 imirkin: if someone replies to the email, yeah
14:33 leberus: ok, thanks :)
14:34 imirkin: Lyude: if you want to take a break from the viewport thing btw, no worries - i bet ARB_post_depth_coverage should be trivial.
14:34 imirkin: (whereas the viewport thing was one i had already personally tried and not been able to work out, albeit with very limited hw access)
16:51 Lyude: imirkin: sure, was hoping to get back to looking at nouveau stuff today
16:53 imirkin_: Lyude: my main point is ... don't get stuck on making one feature work. it can be hard. there's other stuff to do.
16:53 Lyude: gotcha
16:53 imirkin_: take notes on what you did and log them somewhere for the next person (perhaps even future-you) to look at
16:53 imirkin_: ideally in the trello
16:53 Lyude: sure thing, I'll make sure to leave the personal notes I've got on there
16:54 imirkin_: eventually one has to learn to cut their losses... aka the various bugs you see up on the trello :)
16:55 leberus: ok, i've sent the patch to nouveau@lists.freedesktop.org + dri-devel@lists.freedesktop.org, let's see if it can make it :)
17:06 jamm: imirkin,
17:06 jamm: i think i have gotten the hang of how sched works, now i'm trying to figure out how to get a sense of the stall count each instruction requires
17:06 imirkin_: read what emit_gm107.cpp does.
17:06 hakzsam: jamm: a hang?
17:07 imirkin_: and/or read the control codes stuff in the maxas docs
17:07 jamm: hakzsam: i mean, just a basic understanding XD
17:07 hakzsam: ah okay
17:07 imirkin_: diff op types require a diff amount
17:07 hakzsam: jamm: why are you looking at maxwell sched codes? just for fun?
17:07 imirkin_: also depends when the result of that op is used
17:08 jamm: i've been spending little bits of time i get a day so i might be very slow in the weekdays, but i really am looking into working on getting the proper sched codes for nouveau's shaders compiled using envyas
17:08 imirkin_: he's adding sched info to the ddx
17:08 hakzsam: ok
17:08 hakzsam: cool task :)
17:08 jamm: :D
17:08 nyef: HDMI v3 patch series finally out the door.
17:08 imirkin_: jamm: fwiw envyas doesn't compile anythin
17:08 jamm: i saw your presentation on the performance counters, very cool
17:08 imirkin_: jamm: envyas is an assembler
17:09 jamm: my bad, s/compiled/assembled
17:09 jamm: so what does envyas do vs maxas?
17:10 hakzsam: maxas is maxwell only
17:10 hakzsam: mostly sched codes
17:10 jamm: ah, makes sense
17:10 imirkin_: and it's written with a compute focus
17:10 jamm: so envyas is superior ;)
17:11 hakzsam: different :)
17:11 jamm: yeah, i think the proper use case for maxas would be for complete to the metal optimisation to get as close to theoretical flops as possible, if i understood correctly
17:11 hakzsam: well, maxas has some doc that envyas doesn't have
17:12 hakzsam: also, I think nouveau codegen has some doc about maxwell sched codes
17:12 hakzsam: (I probably added comments, etc)
17:12 imirkin_: hakzsam: maybe you were just dreaming it :)
17:12 jamm: hakzsam: right, thanks for those! i've been trying to make sense of your commits as i go along
17:12 jamm: the comments ,at
17:12 hakzsam: imirkin_: maybe :]
17:12 jamm: at least*
17:12 jamm: sigh, this mechanical keyboard is very sensitive
17:13 imirkin_: mechanical keyboard? is there a crank on the side? you punch the key, then turn the crank to get it to register it?
17:13 jamm: heh, more like even a feather touch kind of triggers the keystroke
17:13 imirkin_: https://en.wikipedia.org/wiki/Mechanical_calculator
17:14 imirkin_: it's phenomenal how those things worked, btw
17:14 jamm: yeah, amazing, everything in gears, no power at all
17:14 imirkin_: and even did the printing
17:14 hakzsam: jamm: anyway, when you have something for the DDX (even a small patch) you can ask me directly
17:14 RSpliet: ah that's how you program a Pascal!
17:15 jamm: hakzsam: sure! thanks a lot! i'll look up on emit_gm107 and start working on filling in the sched codes for src/shader/*110.fp
17:16 hakzsam: sgtm
17:17 jamm: the biggest gaps in knowledge i'm facing right now is making sense of a lot of these instructions, as i come from a very basic x64 nasm background.. although the maxas grammar and gm107.cpp has helped somewhat
17:17 jamm: s/cpp/c
17:17 jamm: anyways, night! got work in the morning
17:30 karolherbst: hakzsam: patch 9 got lost
17:30 karolherbst: it's the one with the builtin_functions.cpp changes most likely?
17:31 hakzsam: karolherbst: should be approved soon
17:31 karolherbst: ohhh, big patches have to be approved, got it
17:31 hakzsam: yes
17:32 karolherbst: is there a significant improvement in the games using bindless?
17:32 karolherbst: just interested
17:32 hakzsam: I can't say for now, I have to improve radeonsi support first
17:33 karolherbst: okay
18:49 Lyude: imirkin_: got work stuff out of the way, I'm going to try a couple of last ditch efforts on https://trello.com/c/IAqZXMmt then dump notes with all of the stuff I tried, mind if I give a go at NV_viewport_array2 afterwards?
18:51 imirkin_: that'll be a bunch more work :)
18:51 imirkin_: and much more painful to pipe through mesa
18:52 Lyude: imirkin_: ah, maybe https://trello.com/c/Zjm7vs5h then?
18:52 imirkin_: i'd really recommend ARB_post_depth_coverage. that is by far the easiest.
18:52 Lyude: imirkin_: sure thing
18:53 imirkin_: just needs a trace, the method of doing it should be obvious
18:53 imirkin_: there already are piglit tests and a mesa impl
18:53 imirkin_: so just need to pipe it through gallium
18:53 Lyude: alright, I can definitely do that bit
18:56 Lyude: imirkin_: btw, what was that shader header part you mentioned before regarding https://trello.com/c/IAqZXMmt ?
18:57 imirkin_: Lyude: oh, so look at the decoded shaders
18:57 imirkin_: they have a code section
18:57 imirkin_: and a header section
18:57 imirkin_: the header dword0 iirc contains a "SASS_VERSION"
18:57 imirkin_: i believe the one nouveau sets is diff from blob
18:57 imirkin_: i haven't the faintest clue what it's used for
18:57 imirkin_: also iirc blob sets some unknown bit somewhere, not sure
18:57 imirkin_: my memory's a bit mush in the area =/
18:58 Lyude: ah, alright
19:07 Lyude: imirkin_: btw, where does the shader header stuff happen in mesa?
19:07 imirkin_: nvc0_program.c
19:24 Lyude: would be nice if the shader header here used macro definitions for setting the shader header instead of just plain hex numbers...
19:26 Lyude: regardless though, one of those header changes at least made a difference, but not the difference we wanted
19:32 karolherbst: Satchelboi: how is it going on your end?
19:32 karolherbst: Satchelboi: I have a nidea idea how we can have a smooth transition
19:37 imirkin_: Lyude: the order of things wasn't necessarily (a) write up nice definitions and (b) totally ignore them and use hex everywhere :p
19:37 airlied: though skeggsb does pref hex :-P
19:37 airlied: prefer
19:37 Lyude: imirkin_: I figured as such :P
19:39 imirkin_: airlied: for kernel registers, yeah... i tend to sorta agree with him actually
19:56 RSpliet: It was hard to write... it should be hard to read
19:57 Lyude: hehe
19:59 karolherbst: :O
20:00 pmoreau: The hex looks cooler and more mysterious!
20:00 pmoreau: RSpliet: Going to get you some data you asked me about
20:00 Lyude: imirkin_: just wondering, is there also a chance we might need to change some of the headers for the fragment shader as well?
20:01 Lyude: or should this just be limited to the shader we're trying to set gl_ViewportIndex from
20:03 pmoreau: RSpliet: GF100 -> "fb: missing link training data, using defaults" and I was able to boot, so success I guess! (Note: the GF100 is not the one driving the screen)
20:04 pmoreau: RSpliet: There are a few OOB though for the bios: "bios: OOB 1 01452301 01452301", and 4x "bios: OOB 1 222348cc 222348cc"
20:07 RSpliet: pmoreau: that's good news
20:07 RSpliet: the OOBs are fixed by a patch in Bens tree
20:07 RSpliet: and... can you clock it up to the middle perf lvl? :-P
20:07 RSpliet: (without breaking)
20:07 pmoreau: Anything you want me to extract from that card? Otherwise, I’ll proceeed on the MMIO for the GF107 or whichever it was.
20:07 pmoreau: I’ll try that
20:10 imirkin_: Lyude: and after that, i'm *guessing* that ARB_sample_locations is easiest after post_depth_coverage. not sure. would require re-reading the spec.
20:10 imirkin_: Lyude: in general i'd focus on ARB_* over NV_*
20:11 pmoreau: RSpliet: Reclocking to 07, "fb: invalid/missing rammap entry", but otherwise core reclocked properly.
20:11 RSpliet: invalid/missing rammap is bad
20:11 imirkin_: pmoreau: i got those OOB things too. skeggsb has a fix in his repo, might cover your case.
20:11 RSpliet: Guess it's shorter than expected. Probably means your DRAM just didn't clock up
20:12 imirkin_: Lyude: there's always a chance about having to change frag shader header. but unlikely. it's an input to rast...
20:12 pmoreau: imirkin_: Could be, I am just testing Roy’s improvements to GF100 reclocking.
20:12 pmoreau: RSpliet: Yeah, memory clock stayed the same.
20:12 RSpliet: Either way, happy to hear that using defaults doesn't brick your card
20:12 imirkin_: pmoreau: https://github.com/skeggsb/nouveau/commit/2f0dae367c426f8e411554196350f382fd7b00e6
20:12 pmoreau: \o/
20:12 RSpliet: or nouveau
20:13 pmoreau: imirkin_: Ah, thanks. Will give it a try
20:16 pmoreau: RSpliet: Would you need some more info for this card, some MMIO trace / VBIOS?
20:18 RSpliet: pmoreau: well, mmio trace is always welcome
20:18 RSpliet: but also
20:19 pmoreau: imirkin_, RSpliet: You were correct: Ben’s patch got rid of those OOB. :-)
20:19 imirkin_: yay
20:21 RSpliet: I guess in ramgf100.c you could change the test on line 250 to read len < 0x0d (or something even lower, think 0x0d is appropriate for your VBIOS) and retry
20:38 Lyude: also, what is VP_A and VP_B? https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_shaders.xml#L8
20:40 nyef: ... Vertex Program, maybe?
20:40 imirkin_: Lyude: VP_A = ??, VP_B = vertex shader
20:40 Lyude: ah
20:41 imirkin_: i've never seen VP_A used
20:42 imirkin_: in one of the old DX's there was a funny "tessellation" concept, perhaps it's related to that? i dunno.
20:42 imirkin_: (DX9 perhaps?)
20:43 Lyude: ah
21:20 mooch: why no gk100 stuff in rnndb?
21:20 mooch: or should i add that in?
21:20 imirkin_: there wasn't a gk100 chip...
21:21 mooch: so it just started with gk104 then???
21:21 mooch: that's od
21:21 mooch: *odd
21:22 mooch: then again, maxwell started with GM107 sooo
21:22 imirkin_: no gm100, only gm107 and gm108
21:22 imirkin_: nor is there a gk200
21:23 Satchelboi: karolherbst: Going fine on this end, I replaced all the getChipset( ) with getIsa( ), working on the magic numbers now
21:23 mooch: well okay
21:23 mooch: why no gk104 stuff in rnndb?
21:29 imirkin_: mooch: because your grepping skills need improvement?
21:34 mooch2: fair enough
21:35 imirkin_: (hint: there's a ton of gk104 stuff in rnndb)
21:36 mooch2: oh
21:36 mooch2: what about gp100 stuff?
21:39 imirkin_: that's not really there
21:39 mooch2: fucc
21:41 imirkin_: weren't you trying to emulate nv4? gp100 seems like quite a jump forward...
21:44 mooch2: i'm trying to emulate nv3
21:44 iterati: hi, I get "nouveau 0000:01:00.0: gr: TRAP ch 10 [003f650000 epiphany[1442]]" & ultimately "nouveau 0000:01:00.0: fifo: gr engine fault on channel 10, recovering..."
21:44 mooch2: but i'm interested in all nvidia gpus
21:44 mooch2: well, nv4 and nv5 are also there
21:44 mooch2: in the same code
21:44 iterati: That "fifo: gr engine fault on channel 10, recovering..." is going on for months, multiple versions of the kernel. On gtx 650.
21:45 mooch2: GK107...
21:46 mooch2: imirkin_, do you know anything about how the nv3 drivers work?
21:47 imirkin_: nothing
21:49 mooch2: damn
22:28 Lyude: imirkin_: about to put my notes on that viewport index card, should I put them in a comment or just as part of the card description
22:28 imirkin_: probably comment
22:29 imirkin_: the description is "what is this card"
22:29 imirkin_: comments are ... comments
22:29 imirkin_: i'm probably guilty of mixing up the 2
22:53 karolherbst: Lyude: just tried running plasma on wayland, immediatly got like 10 issues :(
22:54 karolherbst: I am sure most are plasma related, but still. I need to report them at some point
22:54 Lyude: karolherbst: yeah, they're all gonna be bugs with kde's compositor
22:54 karolherbst: yeah
22:54 karolherbst: display scaling doesn't work
22:54 karolherbst: so some things are doubled in size and the others got the normal scaling
22:54 karolherbst: really ugly
22:54 karolherbst: might be even toolkit related
22:55 karolherbst: and when I tried to log out, the logout process just crashed
22:57 Lyude: yikes
22:58 Lyude: also, it would be very nice if trello actually let you preview markdown before posting it...
22:58 imirkin_: Lyude: just edit it :)
22:58 karolherbst: yeah, I think trellos only goal is to be fast
22:58 karolherbst: previews are one click more -> useless :p
22:58 Lyude: ah
22:58 karolherbst: at least I see trello as something where only speed matters
22:59 karolherbst: I already said at work: we need some usable bug tracker, but as fast as trello.
23:00 imirkin_: i like redmine... it's nice and simple.
23:00 imirkin_: not as fast as trello though
23:00 karolherbst: we just Jira....
23:00 karolherbst: *use
23:00 imirkin_: jira is the worst
23:00 karolherbst: yeah, I know
23:00 imirkin_: i also just migrated us from jira to redmine
23:00 karolherbst: :)
23:00 imirkin_: so i have the script all nice and hacked up for it :)
23:00 karolherbst: I could suggest redmine
23:00 karolherbst: but well
23:00 karolherbst: it has to be used also by non hackers :p
23:01 Lyude: we've got jira too, I've never (the same goes for my whole team I'm pretty sure) used it once
23:01 imirkin_: why
23:01 karolherbst: because our product owners use it for sprint planning ;)
23:01 Lyude: actually I went through the effort of just setting up our own wiki server instead...
23:01 imirkin_: that's fine, product owners can operate redmine
23:01 imirkin_: it's just not for end users
23:01 mupuf: Jira has nice features, but gosh is our instance slow!
23:01 imirkin_: i dunno, i couldn't figure out how to operate jira
23:01 imirkin_: that's a bad sign for usability
23:01 karolherbst: yeah
23:02 karolherbst: you can't even assign to groups...
23:02 mupuf: it forces a workflow down your throat
23:02 imirkin_: little things like ... getting notifications
23:02 karolherbst: so we had to create fake accounts to assign to roles
23:02 karolherbst: ....
23:02 mupuf: imirkin_: we receive emails for every change
23:02 imirkin_: i'm not saying it's impossible.
23:02 karolherbst: I reveive emails for changes I make :D
23:02 mupuf: yep, same :D
23:02 karolherbst: *receive
23:02 imirkin_: i wanted to receive all changes for a project.
23:02 imirkin_: er, emails for all changes
23:02 karolherbst: mupuf: since this week?
23:02 karolherbst: or last one?
23:02 karolherbst: I think they broke something
23:03 mupuf: karolherbst: nope, since forever
23:03 karolherbst: mhh odd
23:03 karolherbst: it worked for me (tm)
23:03 nyef: One of the main problems that I have with jira is the email spam. And not even *useful* email spam. Another is the lack of keyboard shortcuts for some operations.
23:03 mupuf: nyef: as opposed to bugzilla? :p
23:03 imirkin_:likes email
23:03 imirkin_: but it's all configurable in redmine, which is nice.
23:04 nyef: mupuf: As opposed to some possibly-hypothetical system which doesn't suck horribly.
23:04 mupuf:used to have a redmine instance on his server
23:04 mupuf: nyef: ahah!
23:04 karolherbst: imirkin_: do you think redmine would somehow fit into a Scrum kind of working?
23:04 nyef: Email is nice when it gives enough context to actually know what's going on.
23:04 imirkin_: karolherbst: i've seen it used that way in the past, so it's definitely doable.
23:04 karolherbst: k
23:04 imirkin_: i'm sure you could find guides online for how to operate it in a scrummy manner
23:04 imirkin_:hates scrum
23:05 karolherbst: well, I don't like it either
23:05 karolherbst: but there are things you can't change that easily
23:06 imirkin_: well, depends. if you have an easy time finding jobs, you could just make sure to find out if such a ridiculous process is used, and if so, go to a different place.
23:06 karolherbst: :D
23:06 karolherbst: good plan
23:06 imirkin_: given the level of demand for software engineers, it's a pretty reasonable way to go
23:06 mupuf: Ah ah! I guess it's true
23:06 karolherbst: hihi
23:14 mooch: hey does anybody have any knowledge on how the nv3 drivers work?
23:14 mooch: maybe you, mwk?
23:15 mupuf: well, if anyone here knows, then it is likely mwk :D
23:15 mooch: yeah
23:15 mooch: i need some assistance getting them to not hang lol
23:22 Lyude: imirkin_: https://trello.com/c/kuMPh88f were there ever piglit tests written for this? I'm not finding anything in piglit
23:40 karolherbst: Satchelboi: I had the idea of giving the enum fields the same numeric values as the currently used constants have, so that the getChipset -> getIsa transition could be done in a seperate patch
23:41 karolherbst: and don't do too much anymore, you should calculate with +2 days after your final posting on the mailing list until you get it upstreamed for real