00:14 imirkin: skeggsb: know if nv30 had the clipdist varyings like nv40? or if we're supposed to program in the fixed clip planes in?
00:14 imirkin: [clipping doesn't appear to work, trying to work out why]
00:48 skeggsb: imirkin: i suspect it wouldn't, but, i don't recall
00:49 imirkin: well, i tried the fixed clip planes but that didn't work
00:49 imirkin: i suspect that's for the fixed function pipeline
00:49 airlied: I'm guessing nv30 only had clipvertex
00:49 imirkin: hm, well nv40 had 6 clip distances
00:50 airlied: hmm internet says nv30 did as well
00:50 airlied: https://www.beyond3d.com/content/articles/74/3
00:50 imirkin: clip planes are "emulated" by dotting the pos/clipvertex with the plane eqn
00:50 skeggsb: imirkin: ok, actually, it should
00:50 skeggsb: GL_NV_vertex_program2 exposes them
00:50 skeggsb: iirc that's the nv30 one
00:51 imirkin: i don't suppose you have any left-over traces?
00:54 skeggsb: doubtful
00:55 imirkin: and i never finished my disasm for nv30
01:11 imirkin: skeggsb: there's lots of dragons in that nvfx compiler =/
01:11 imirkin: struct nvfx_src ceqn = nvfx_src(nvfx_reg(NVFXSR_CONST, 512 + i));
01:11 skeggsb: imirkin: i don't suppose nir is suitable...
01:12 imirkin: like why does it start at 512
01:12 imirkin: it's not *unsuitable*, but it'd be a huge undertaking to convert it
01:12 imirkin: and you'd still have to deal with RA
01:12 imirkin: which is the main thing we don't have now
01:12 skeggsb: i, um, ignored the compiler*cough*assembler*cough* when doing nv30.. pretty much stole it from nvfx and cobbled it together
01:13 imirkin: yeah
01:13 imirkin: but the other code sticks the plane equations at the bottom of the const space
01:13 imirkin: otoh, consts don't go up to 512 anywhere
01:14 imirkin: there's also funky relocations which i need to recheck
01:20 imirkin: /* Vertex program resources (code/data), currently 6 of the constant
01:20 imirkin: * slots are reserved to implement user clipping planes
02:08 mooch3: what do you guys think about pascal?
02:09 imirkin: i learned it for a programming competition a very long time ago. forgot it promptly thereafter.
02:09 skeggsb: lmao
02:10 airlied: begin/end
02:10 imirkin: all i remember was i couldn't figure out how to pass something by reference
02:10 imirkin: or something to do with arrays...
02:11 imirkin: wow, this was almost 20 years ago. am i that old? =/
02:12 imirkin: i guess more like 18. phew.
02:15 mooch3: no i mean
02:15 mooch3: nvidia pascal
02:15 mooch3: gtx 1080
02:15 mooch3: that shit
02:15 imirkin: i think we all knew. just being funny.
02:16 imirkin: the marketing around it suggests all sorts of fancy new features, but from what i can tell, these are all features available since DX10
02:17 imirkin: i'm sure there's something more to it
02:17 airlied: compute
02:18 airlied: nobody knows what else to do with graphics
02:27 mooch3: RAYTRACING ACCELERATION
02:27 mooch3: DO IT NVIDIA
02:27 mooch3: oh wait, there's optix
04:33 skeggsb: imirkin: btw, the gm108 airlied has on his desk works ok.. i have nfi what's up with the other one in the bug report though
04:33 airlied: runs gears at least :)
04:33 imirkin: ok :)
04:34 skeggsb: airlied: that's all you need - right?
04:34 airlied: actually I ran elemental in glsl1.50 mode on it under prime as well
04:34 imirkin: did it work? :)
04:34 airlied: it rendered stuff
04:35 imirkin: any correlation to what the demo was trying to render?
04:36 imirkin: afaik the maxwell code emission hasn't received too much battle testing yet, so i wouldn't be surprised if we still got some stuff wrong in there
04:37 imirkin: also there's some odd issue in xonotic where the ground turns red sometimes. and the glamor-induced issues which have allegedly subsided
04:37 airlied: well I can see stuff though I don't think it's in any ways perfect
04:38 airlied: yeah it looks pretty broken
04:38 imirkin: ok. any ILLEGAL_OPCODE or similar messages in dmesg?
04:39 imirkin: (those are my favorite since they tend to be easy to track down)
04:41 imirkin: skeggsb: btw, is it unusual that my NV34 is reporting a DVI-I port when it's really just VGA?
04:43 imirkin: [the DCB really does appear to describe a digital connector... not nouveau's fault i suppose]
04:44 airlied: imirkin: no dmesg is clear
04:44 skeggsb: imirkin: there's a few cases of that, especially on older boards
04:44 imirkin: airlied: oh well. it'll be a more subtle issue then.
04:45 Leftmost: Stepping back and making sure I understand tess before trying to write tests to suss address calculation.
04:47 imirkin: skeggsb: nv34 already had hwsq scripts??
04:47 skeggsb: yeah, was used for something lvds-related
04:50 Leftmost: imirkin, in the traces you provided from gm107, there were multiple code uploads to the TCP. Is that expected, or is it an artifact of the shader runner in piglit?
04:50 imirkin: Leftmost: an artifact of something... i wouldn't worry what
04:50 imirkin: Leftmost: look at the last TCP that's uploaded
04:50 imirkin: the one that's not nonsense
04:51 imirkin: [there's a provision for having a "passthrough" TCP, but you still need to upload one because the number of patch variables is in the header, and otherwise the TEP can't read in the tessellation parameters]
04:52 Leftmost: Alright. Mostly just trying to figure out the easiest way to write some shader tests with relatively uncluttered output from valgrind.
04:53 imirkin: use nop.shader_test as a template.
04:53 imirkin: or sanity
05:00 Leftmost: imirkin, should I bother with the sched calls, or are those just barriers (and, presumably, not relevant to mem access)?
05:00 imirkin: every 4th op is scheduling information - ignore it
05:01 imirkin: even if it doesn't say "sched" it's still scheduling information
05:01 imirkin: sometimes it comes out as a weird fadd32i
05:01 imirkin: but that's just a decoding issue - envydis doesn't have a great way of dealing with that restriction
05:02 imirkin: i.e. it's all done in groups of 32 bytes. the first 8 bytes are sched info, next 8 bytes are op 1, op2, and op3.
05:16 Leftmost: I'm not quite understanding what happens for, say, "mov32i $r0 0x7e 0xf". The PTX docs suggest this is packing a vector into a scalar register, but is it just a roundabout way of setting a scalar for later manipulation?
05:16 Leftmost: Or just a weird decoding?
05:21 imirkin: Leftmost: ignore the 0xf at the end... that's just there to confuse you (it's the lanemask)
05:21 imirkin: that's just "store value 0x7e in $r0"
05:22 Leftmost: Okay.
05:23 imirkin: i'm off, good luck!
05:23 Leftmost: Thanks. I'll have more questions tomorrow. :)
07:03 hakzsam: imirkin, oh you did a bunch of commits this night :)
08:35 mupuf: Ah ah, I second hakzsam :D
08:35 mupuf: and have fun with nv30 :p
08:38 mupuf: hakzsam, imirkin: What happened to the "let's not expose 4.3 until unreal demos are fixed"? Did I miss anything?
08:38 hakzsam: 4.3 is not exposed
08:39 hakzsam: only the robustness thing has been turned on
08:39 hakzsam: (ie. not the GLSL version)
08:40 hakzsam: mupuf, if we figure out the UE4 fails, we could bump to 4.3 for the next release
08:40 hakzsam: but... it's not trivial
08:40 mupuf: ack!
08:40 mupuf:expected that something like this would be done in gallium: https://cgit.freedesktop.org/mesa/mesa/commit/?id=856587909c3fa508529a659d789f4517080ee4dc
14:02 Lekensteyn: Is Pierre Moreau here? He sent some patches related to DSM in nouveau_acpi.c last year, I wonder what the status is with those cleanup patches
14:03 Lekensteyn: I am about to refactor nouveau_dsm_pci_probe to get rid of the NOUVEAU_DSM_HAS_xxx flags and add two functional fixes on top of that
14:27 mupuf: Lekensteyn: Pierre Moreau's nick is pmoreau
14:28 Lekensteyn: mupuf: thanks, I think I fat-fingered tabcompletion because it did not show up before
14:32 mupuf: Lekensteyn: no worries :p
14:33 imirkin_: mupuf: can you look at https://bugs.freedesktop.org/show_bug.cgi?id=91413 ?
14:34 mupuf: imirkin_: oh shit!
14:34 mupuf: using alarm has been more of a pain than an actual help
14:35 imirkin_: mupuf: btw, infinite loop may have been the wrong categorization. might be a deadlock instead.
14:35 mupuf: I may just stop using it
14:35 mupuf: imirkin_: would be nice if you could run with lockdep
14:36 imirkin_: mupuf: sure, but from the call trace it should be pretty obvious what's going on
14:36 imirkin_: i think something takes that spinlock, and then it's acquired again further down the callchain
14:36 mupuf: will see :)
14:37 imirkin_: (and the fact that it's in an interrupt certainly doesn't help matters)
14:37 mupuf: well, I do not like the fact that I see nvkm_fantog_update twice
14:38 karolherbst: mupuf: nice, my fix from yesterday seems to work :)
14:38 karolherbst: mupuf: this one: https://github.com/karolherbst/nouveau/commit/49dbf55a2664d354ecc55c4678062f0468461357
14:38 karolherbst: maybe there is a more elegant solution for this though
14:39 imirkin_: the elegant solution would be the one where each engine can insert stuff into the sequence at the appropriate times
14:39 imirkin_: but ... seems complex and unnecessary
14:40 karolherbst: yeah
14:40 karolherbst: maybe we should have some flag array like device->engineExists[PDISPLAY] or something like that
14:41 karolherbst: allthough nvkm_device_engine is exactly doing this somehow
14:41 imirkin_: what do you think you're doing now? :)
14:41 karolherbst: switch against the parameter and return
14:41 karolherbst: though
14:41 karolherbst: one thing
14:41 karolherbst: default: "WARN_ON(1)"
14:41 karolherbst: ohh
14:41 imirkin_: for an unknown engine type, sure
14:41 karolherbst: well doesn't matter
14:42 karolherbst: yeah, I was stupid
14:42 karolherbst: it is just a pointer check for device->disp->engine
14:42 karolherbst: yeah, looks fine
14:42 karolherbst: and there is a disable_mask check
14:42 imirkin_: and presumably it's inlined, so in actuality, it's no extra work
14:42 karolherbst: nope
14:42 karolherbst: well
14:43 karolherbst: maybe GCC is smart, but that would only be inlined with lto
14:43 karolherbst: the functions is impleneted in nouveau/nvkm/engine/device/base.c
14:43 imirkin_: ah, it's not in a header? oh well =/
14:43 karolherbst: yeah, doesn't matter much
14:43 karolherbst: it's not like we call it that often
15:00 pmoreau: Lekensteyn: Indeed, I am here :-) I was planning on resubmitting them soon. Probably will resend them tonight, otherwise I’ll end up letting them linger a month or two, or forget all together
15:04 Lekensteyn: pmoreau: there are some cleanups (1/8 is nice and trivial) but also some additions (gmux, 7/8)
15:05 Lekensteyn: i was hoping to get rid of the retval bitmap for nouveau_dsm_pci_probe and make it arguments for _DSM instead
15:05 Lekensteyn: s/_DSM/nouveau_dsm_pci_probe/
15:06 Lekensteyn: the current code is a bit ugly with the same loop duplicated for PCI class VGA and 3d, it (wrongly) suggests that two different devices can have a valid _DSM handle
15:46 Lekensteyn: pmoreau: re https://lists.freedesktop.org/archives/dri-devel/2015-May/083448.html, I've also seen 0x80000001 when the revision ID/UUID mismatches, what about checking for just the MSB?
15:50 Lekensteyn: 0x80000001 seems to mean "not implemented" or something like that, https://github.com/Lekensteyn/acpi-stuff/blob/master/dsl/Clevo_P651RA/ssdt7.dsl#L196
16:00 pmoreau: Lekensteyn: And back again. I was on my way home, sorry.
16:01 pmoreau: Right: my initial aim was to add gmux support to get runpm on my laptop working. Along the way I learned some more about ACPI, decided to tackle the warning messages, and ended up doing some cleanup.
16:02 Lekensteyn: pmoreau: welcome back
16:02 Lekensteyn: i think that the 0x80000002 check should not be done in nouveau_optimus_dsm, subfunctions may return values in any form
16:02 pmoreau: During the review process, l1k notified me that some more general work had already started (and runpm should not be implemented for some of the MBPs, as you ended with a blank screen or hang), so I dropped the whole serie
16:03 pmoreau: The MSB seems like a good idea
16:03 Lekensteyn: Lukas has done a lot of work recently for that
16:03 pmoreau: Exactly, and he told me he is currently looking at the runpm stuff.
16:03 pmoreau: So I’ll only resubmit the cleanup parts
16:10 Lekensteyn: hmm, actually this HDSM function is not called anywhere
16:36 hakzsam: karolherbst, do you have alien isolation?
16:36 hakzsam: or someone else?
16:38 karolherbst: I think
16:38 karolherbst: ohh no
16:38 karolherbst: don't have it
16:38 imirkin_: you have shadow of mordor though right?
16:39 karolherbst: mupuf has that one
16:39 karolherbst: shadow of mordor that is
16:39 hakzsam: yeah, but I need a new HDD for it :)
16:39 karolherbst: :D
16:40 karolherbst: you can also delete other stuff for now? :p
16:40 hakzsam: nope, I can't
16:40 hakzsam: my HDD is like 64G
16:40 hakzsam: and shadow uses 50G
16:40 hakzsam: so...
16:41 karolherbst: uhh
16:41 karolherbst: yeah, that's too bad then :/
16:42 hakzsam: mupuf, did you already try shadow of mordor on nouveau?
16:42 hakzsam: it would be good to test
16:42 hakzsam: especially because this game will use compute shaders
16:47 imirkin_: Leftmost: you have a GM20x right? would you be able to test some patches for me? (not written yet, but want to see if there's an audience in case i do)
16:50 pmoreau: imirkin_: Depending on what the test consists in, I could do it since I have a GM206, and a working computer. :-)
16:51 Leftmost: imirkin_, GM204, and yeah.
16:52 imirkin_: well, the test would consist of applying a mesa patch and running a few piglits
16:52 pmoreau: Should be doable then ;-)
16:54 Leftmost: No, I wanna do it! :-P
16:54 imirkin_: Leftmost: you concentrate on tracing tess
16:54 Leftmost: Yep.
16:56 pmoreau: I guess imirkin_ isn’t going to complain if two persons test it, is he?
16:56 imirkin_: pmoreau: patch: http://hastebin.com/eruxelejeq.m
16:57 pmoreau: Thanks! Let me update the computer, and I’ll test it
16:57 imirkin_: pmoreau: and then try running the amd_vertex_shader_layer and amd_vertex_shader_viewport_index piglits... oh, and arb_fragment_layer_viewport too while you're at it
16:57 imirkin_: i think they should Just Work (tm), but if not, i'll have to think some more.
17:07 Leftmost: Oh, I had another question about the trace from sanity. There are various lines like "isberd o $r0 ?[$r0]" or "isberd o $r5 ?[$r2]". The logs suggest it's loading from memory, but I'm not clear on what would be there.
17:07 imirkin_: ah yes... the "is it a beard" primitive...
17:07 imirkin_: so that's one of the big questions
17:08 imirkin_: my suspicion is that it's IS BE RD
17:08 imirkin_: where IS = "input space" maybe
17:08 imirkin_: and RD = "read"
17:08 imirkin_: the O modifier is for outputs instead of inputs
17:08 imirkin_: and i think that BE is in reference to the same thing that BEADDRESSHI/LO are talking about
17:09 imirkin_: but ... i'm not 100% sure of anything further
17:13 mupuf: hakzsam: nope, never tried shadow of mordor ever
17:14 mupuf:is looking forward to playing with it though :D
17:14 Leftmost: Hmm, okay. If I'm not misreading, it's getting some sort of address information out of that, since it reads to r0 from that, then does r0 = directbewritelow + (128 * ((r0 + 3) >> 2)).
17:15 imirkin_: Leftmost: yeah, that sounds likely.
17:15 imirkin_: Leftmost: the question is ... what is the input and what is the output
17:15 imirkin_: and when to use it ;)
17:15 Leftmost: I assume the (r0 + 3) >> 2 is basically an align.
17:15 Leftmost: Yep.
17:15 imirkin_: also you might run into some AL2P's eventually
17:15 Leftmost: I'll keep digging on that, just making sure I'm understanding up to this point. :)
17:15 imirkin_: once you throw in enough indirection
17:16 imirkin_: which feed into all this somehow too
17:16 imirkin_: i modeled them as AFETCH in codegen for kepler, but this may work differently on maxwell
17:21 hakzsam: mupuf, you have 50G free ? :)
17:21 mupuf: sure
17:25 karolherbst: ha! may who owns which game on steam game came in handy! :D
17:26 mupuf: karolherbst: I am sorry, I completely forgot that I needed to install this on my server...
17:26 karolherbst: mupuf: well daily cron job "php file > html_file" is enough
17:27 mupuf: yep yep
17:27 karolherbst: and I can generate one file only with embedded js
17:28 karolherbst: mupuf: repository is here: https://github.com/karolherbst/SteamDevGameOverviewer
17:28 karolherbst: mupuf: I give you the config.php whenever you have time to set it up
17:29 mupuf: karolherbst: good, tighten up the security on it, plz
17:29 karolherbst: :D
17:29 karolherbst: ahh
17:29 karolherbst: mhh
17:29 karolherbst: well
17:29 karolherbst: I do only some http calls
17:29 karolherbst: *https
17:29 mupuf: that was not my point
17:29 karolherbst: what do you mean then?
17:29 mupuf: open_basedir should be set to the only folder than needs it, if open at all
17:29 mupuf: extensions should be disabled
17:30 mupuf: etc...
17:30 karolherbst: mhhh
17:30 karolherbst: right
17:30 karolherbst: well
17:30 karolherbst: never done that
17:30 mupuf: ack, then nevermind
17:30 karolherbst: well it only needs the directory where the files are anyway
17:32 l1k: Lekensteyn, pmoreau: current nouveau runpm code is a leaky bucket, I've posted a series to dri-devel an hour ago to fix the most egregious offenders. runpm for muxed dual GPU laptops needs patches on top of that.
17:35 pmoreau: imirkin_: Mesa compilation started, otherwise I have everything else ready, so I should be able to soon test
17:35 imirkin_: cool, let me know how it goes
17:36 pmoreau: l1k: Yup, saw them
17:37 pmoreau: I need to retry switching between both GPUs on my laptop. IIRC, it would lock up after a few switches…
17:44 pmoreau: imirkin_: All ./bin/amd_vertex_shader_layer_* with "-auto -fb"?
17:44 imirkin_: and vertex_shader_viewport_index-*
17:44 imirkin_: -fbo -auto
17:45 imirkin_: and all the shader_tests in tests/spec/arb_shader_layer_viewport
17:47 pmoreau: So far they fail :-/
17:47 pmoreau: Let’s try the shader_tests ones
17:48 imirkin_: hm, o well
17:48 imirkin_: nah, don't worry about it... there must be something more to it.
17:49 pmoreau: I don’t have tests/spec/arb_shader_layer*, and I just cloned piglit
17:50 imirkin_: https://cgit.freedesktop.org/piglit/tree/tests/spec/arb_fragment_layer_viewport
17:50 imirkin_: i was close :)
17:50 pmoreau: Ah :-)
17:50 imirkin_: all the *-vs-* ones
17:52 l1k: pmoreau: wasn't this because hardware acceleration of the console fb wasn't working after waking the G96?
17:54 pmoreau: imirkin_: Only the viewport-vs-write-simple fails, the other ones pass
17:55 imirkin_: does layer-vs-write-simple pass?
17:55 pmoreau: l1k: Right, there was some lockup so Nouveau reverted to soft fb, and then if I switched one more time, the laptop would completely lockup
17:55 pmoreau: Yup :-)
17:55 imirkin_: interesting.
17:55 imirkin_: but amd_vertex_shader_layer tests failed?
17:56 pmoreau: Yes, both the texture 2d and the depth one
17:56 imirkin_: curious.
17:56 imirkin_: verrrry currrrious
17:57 imirkin_: oh, duh
17:57 pmoreau: Do you want me to get some MMT traces of those with the blob?
17:57 imirkin_: yes please!
17:57 imirkin_: i think i have a trace already somewhere
17:57 pmoreau: Just need to find where? :-D
17:57 imirkin_: https://people.freedesktop.org/~imirkin/traces/gm206/
17:57 imirkin_: can you look at the vs-viewportindex.mmt one
17:58 imirkin_: and see what it sets LAYER to when drawing?
17:58 imirkin_: does it set it to 0x10000, or some other value?
17:59 imirkin_: [don't have demmt here, don' want to install]
18:00 imirkin_: [or else i'll be further tempted to procrastinate on real work]
18:00 pmoreau: :-D
18:01 pmoreau: There is a single occurence of layer: "0x00010000 GM204_3D.LAYER = { IDX = 0 | USE_GP }"
18:01 imirkin_: ok cool
18:01 imirkin_: that's what i figured
18:01 imirkin_: give me a minute.
18:02 pmoreau: I’ll get MMT on the computer in the mean time
18:02 imirkin_: no need for this -- i know what the issue is
18:02 imirkin_: [i think]
18:05 l1k: pmoreau: when you turned off hwaccel for fbcon, I recall that switching worked without a hitch. would be interesting to see if it works with hwaccel now, perhaps this has been fixed in the meantime.
18:07 pmoreau: imirkin_: Even if you know the issue, I’m sure that someone, at some point, will want an MMT. And that machine is dedicated to Nouveau testing so… ;-)
18:08 pmoreau: And there we go, cloned and compiled
18:08 pmoreau: l1k: Could be. I’ll retest tonight, before/after retesting the ACPI patches.
18:11 imirkin_: pmoreau: v2 patch: http://hastebin.com/ecujidomag.diff
18:11 imirkin_: pmoreau: oh wait, crap. forgot a line.
18:11 pmoreau: Who needs them!
18:11 imirkin_: pmoreau: http://hastebin.com/efekomahih.diff
18:12 imirkin_: although that doesn't explain why the viewport stuff didn't work
18:12 imirkin_: but this should at least fix the layer ones
18:13 imirkin_: [ok, there's a compile failure in there ... prog -> last in nvc0_layer_validate]
18:16 pmoreau: So, the 2d-texture and depth works now
18:16 imirkin_: w00t
18:16 imirkin_: and the vs-layer-write-simple still works too?
18:16 pmoreau: Yes
18:16 imirkin_: i assume no change on the viewport ones?
18:17 pmoreau: Right
18:17 imirkin_: can you check that the ARB_viewport_array piglits pass?
18:17 pmoreau: A bit later, gtg
18:17 imirkin_: k
18:27 pmoreau: And back
18:28 pmoreau: All of the ./bin/arb_viewport_array* ?
18:29 imirkin_: at least some :)
18:30 imirkin_: also does viewport-gs-write-simple.shader_test pass?
18:31 pmoreau: The latter was passing before and still passes
18:31 imirkin_: ok
18:31 imirkin_: actually this is interesting ...
18:32 pmoreau: Ok, because for arb_viewport_array-bounds, I get a few "Mesa: User error: GL_INVALID_VALUE in glViewportArrayv: index(0) width or height < 0 (-10.300000, 0.00000)" for example
18:32 imirkin_: it was setting LAYER in that trace
18:32 pmoreau: But otherwise it passes
18:32 imirkin_: that's a bad one
18:32 pmoreau: :-D
18:32 imirkin_: call one with render in its name
18:33 pmoreau: They all pass (the ones with render at least)
18:33 imirkin_: ok
18:33 imirkin_: what if you change that line to
18:33 imirkin_: prog_selects_layer = !!(last->hdr[13] & 0x600);
18:34 imirkin_: does that help the amd_vertex_shader_viewport_index tests?
18:36 pmoreau: Sadly not
18:36 imirkin_: ok. i'll have to look at the trace for real then.
19:26 Lekensteyn: l1k: that would explain an issue I hit before, nouveau somehow remained in resumed state after a module reload (requiring removal of the pci device+rescan to fix rpm)
20:37 karolherbst: Lekensteyn: that happens as long as you loaded nouveau at least once with runpm=0
20:37 karolherbst: Lekensteyn: maybe there are other reasons as well for that to happen
21:19 l1k: Lekensteyn: you may want to merge these commits onto your working branch to fix those issues: https://github.com/l1k/linux/commits/drm_runpm_fixes_v1
21:19 l1k: Lekensteyn: if you do notice any runtime pm ref leaks, please let me know
21:20 l1k: Lekensteyn: the number of runtime pm refs can be obtained from /sys/bus/pci/devices/<device>/power/runtime_usage (should be 1 if nouveau is not loaded)
21:20 Lekensteyn: l1k: I'll test them later this hour, currently writing a cover letter for https://git.lekensteyn.nl/peter/linux/log/?h=nouveau-acpi-v2
21:21 l1k: no hurry :)
21:22 Lekensteyn: do you/nouveau use patchwork btw?
21:22 imirkin_: not enough patch flow to really care
21:22 imirkin_: dri-devel is hooked up to a patchwork instance though
21:27 mooch2: on NV40_3D, what is depth format 0?
21:27 mooch2: a game in rpcs3 is using this format, but https://github.com/envytools/envytools/blob/master/rnndb/graph/nv_3ddefs.xml#L232 says that's only for NV10_3D-NV17_3D
21:28 imirkin_: depth format as taken where?
21:28 imirkin_: texturing or rendering?
21:28 imirkin_: https://github.com/envytools/envytools/blob/master/rnndb/graph/nv30-40_3d.xml#L147
21:28 mupuf: imirkin_, Lekensteyn: the nouveau ML is also hooked up to patchwork
21:28 mwk: mooch2: you doing NV40 now?
21:29 mupuf: https://patchwork.freedesktop.org/project/nouveau/series/?ordering=-last_updated
21:29 mooch2: mwk: eh, i figured i'd help rpcs3
21:29 mooch2: imirkin_, rendering, i think
21:29 imirkin_: RT_FORMAT? iirc it's illegal
21:30 mooch2: eh, i'll implement it as Z24S8 and see what the game think
21:30 mooch2: *thinks
21:30 imirkin_: you get an INVALID_VALUE interrupt
21:30 mooch2: well, someone got it while playing a game
21:30 mooch2: https://github.com/RPCS3/rpcs3/issues/1711
21:30 imirkin_: or INVALID_BITFIELD, i forget
21:30 imirkin_: buggy game :)
21:30 mwk: INVALID_BITFIELD only exists on G80+
21:31 imirkin_: so INVALID_VALUE then. i'm like 95% sure.
21:31 imirkin_: this is what we do: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv30/nv30_state_validate.c#n68
21:31 mwk: I don't remember what the NV04-era interrupts were called, but the hierarchy was totally different
21:31 mooch2: well, have you actually TRIED it on nv40?
21:31 mooch2: because i'm not sure the game would be using that format if it didn't expect it to work
21:31 mooch2: this is the ps3 we're talking about
21:32 mooch2: you can't just have random interrupts everywhere
21:32 mwk: mooch2: a word of warning...
21:32 mwk: this is PS3, *not* NV40
21:32 mwk: no one of us has one, as far as I know
21:32 imirkin_: mooch2: iirc yes
21:32 mooch2: ehhhh
21:32 mwk: mostly it should be the same as NV44, but who knows
21:32 imirkin_: (i mean on nv40/nv44)
21:32 mwk: it also has a totally different driver
21:33 mooch2: what are the chances that it's Z24S8?
21:34 imirkin_: 0
21:34 mwk: let me see
21:34 mooch2: or even worse
21:34 mooch2: something exotic like Z16S8 or Z16S16
21:34 mwk: hold on, I have to find my laptop...
21:34 mooch2: it's most likely that's not the case tho
21:35 mooch2: i have a c51
21:35 l1k: Lekensteyn: in nouveau_check_pr_support(), I think you can use "ACPI_COMPANION(&pdev->dev)" instead of "acpi_bus_get_device(ACPI_HANDLE(&parent_pdev->dev), &ad)"
21:36 l1k: Lekensteyn: sorry, I should have pointed you directly to ACPI_COMPANION in my e-mail
21:37 mwk: mooch2: I'm going to bet anything you won't see Z16S8 or Z16S16
21:37 mooch2: oh? why not?
21:37 mooch2: is it because gl doesn't use it? :^)
21:37 mwk: actually I think GL might have an enum somewhere...
21:38 mwk: but anyhow
21:38 mwk: anything involving S16 is basically unicorns
21:38 mwk: noone ever used it, noone ever implemented it
21:38 mwk: Z16S8, otoh, won't happen because it's 3 bytes, and that's not PoT
21:39 pmoreau: Lekensteyn: I started pulling out the patches, will try to finish that before going to sleep. Maybe not send them to the ML, but at least have an (almost) updated version sitting on a public branch.
21:39 mooch2: i wonder why nobody wanted 16 bits of stencil buffer POWAA
21:39 Lekensteyn: l1k: seems sensible based on the definition of acpi_device_handle, acpi_bus_get_device is a bit more magic that is harder to understand
21:40 l1k: Lekensteyn: since this function returns a bool, I think the name should be the answer to a yes/no question, e.g. nouveau_pr3_present() or somesuch
21:40 Lekensteyn: l1k: thanks for your suggestions, it is possible that the pci/pm fixes end up in v4.8, then there is one more cycle to ensure everything is working
21:40 l1k: yes, I saw mika's e-mail :)
21:41 l1k: the whole thing would probably be a bit rushed if we tried to squeeze it into 4.7
21:41 mwk: well
21:41 mwk: 0 is most definitely illegal
21:42 l1k: Lekensteyn: I'm not sure if you saw that, Dave Airlie did a series a few weeks ago for this PR3 thing...
21:42 l1k: but it wasn't merged AFAIK
21:42 mooch2: well shit
21:42 l1k: he postponed it in favor of mika's series
21:42 l1k: at least that's my understanding
21:44 l1k: Lekensteyn: https://lists.freedesktop.org/archives/dri-devel/2016-March/102535.html
21:44 Lekensteyn: l1k: yes I saw Dave's patches and also noticed that they wer edropped in favor of Mika's patch
21:44 l1k: ok good.
21:44 Lekensteyn: but I could not find a follow up for the nouveau patches
21:45 l1k: my guess is that he was too busy to continue working on it.
21:45 l1k: but if you pick that up it's cool
21:46 Lekensteyn: this laptop is sitting here unused since January, I really need to have it fixed before I leave in June :p
21:46 Lekensteyn: my old laptop is about dead
21:48 mwk: mooch2: maybe there are problems in PFIFO simulation and it's getting wrong commands?
21:52 mooch3: mwk: i don't think it even really simulates much of pfifo at all
21:52 mooch3: just enough to get commands
21:52 mooch3: and to hle most of the rest of the graphics libraries
22:06 Lekensteyn: l1k: do you have any hybrid amd graphics laptops? I wonder how those react to Mika's patch
22:07 l1k: Lekensteyn: nope. I have a MacBook Pro with Intel HD4000 + Nvidia GK107
22:07 Lekensteyn: with special gmux handling :)
22:09 l1k: lovin' it
22:10 l1k: Lekensteyn: where are you going to? (because you say you're leaving.)
22:11 Lekensteyn: travelling to Sharkfest in the USA, having a working laptop with sufficient battery would be nice as developer
22:12 Lekensteyn: currently I have to swap batteries every 3-4 hours and put them in a "charging station" (a different laptop which is unreliable, but sometimes works for charging)
22:12 imirkin_: and swap the batteries REALLY fast, before the capacitors notice :)
22:13 Lekensteyn: I wish that worked :p
22:13 l1k: it's good to be able to hot swap batteries at all. with the MacBook Pros sold today the battery is glued in. :(
22:13 l1k: mine is the last one where it's still user serviceable. I deliberately bought that one.
22:14 Lekensteyn: the battery of this new Clevo laptop is not directly accessible, but if you unscrew 12 cover screws (and maybe four more for the battery), THEN you can replace it
22:15 Lekensteyn: not ideal, but at least if the battery degrades replacement is an option
22:15 l1k: this is much worse than the old PowerBooks of yore. right now I'm sitting in front of my trusty PowerBook (2000), that one even supported dual batteries. and hotswapping on top (after going to standby).
22:16 l1k: Lekensteyn: then at least it's not glued in, which is good.
22:16 Lekensteyn: I believe there are also some Lenovo's which have a backup battery and a secondary battery (from last year?)
22:16 l1k:is wondering when the EU finally declares this verboten.
22:17 Lekensteyn: but I don't buy Lenovo because superfish and preinstalled malware
22:42 pmoreau: :-/ I’m getting confused by some of my choices in those patches… And as the night advances, it’s not really helping.
22:45 Lekensteyn: pmoreau: maybe you can already push your WIP
22:45 Lekensteyn: I'll collect some email addresses and fire the patches with l1k's feedback already incorporated
22:46 pmoreau: Will soon do that
22:46 pmoreau: It’s mainly one thing that is annoying me, so I’ll pick something, push it, and think over it while sleeping
23:01 Lekensteyn: meh, unknown chipset (ffffffff) issue when loading nouveau
23:02 Lekensteyn: also unbinding the device from nouveau and binding it again results in EEXIST
23:02 Lekensteyn: nouveau: probe of 0000:01:00.0 failed with error -17
23:02 imirkin_: forgot the vtcon unbind?
23:02 Lekensteyn: (actually, that happened when 1 > remove and then rescan pci bus)
23:02 Lekensteyn: nope, optimus laptop
23:03 Lekensteyn: or what?
23:03 Lekensteyn: echo > /sys/bus/pci/devices/0000\:01\:00.0/remove 1; (wait for a bit) echo > /sys/bus/pci/devices/0000\:00\:01.0/rescan 1
23:04 l1k: then the GPU is off
23:04 Lekensteyn: then I get EEXIST unless I reload nouveau module
23:04 l1k: ffffffff sounds like the read from the PCI device timed out
23:04 Lekensteyn: lspci -H1 showed that it was on last time I checked
23:05 l1k: perhaps the root port went to D3?
23:05 Lekensteyn: the workaround for that is to rmmod nouveau, remove the device from the PCI bus, rescan and load nouveau again
23:05 l1k: if the root port is in D3hot, the devices below it aren't accessible
23:06 l1k: even if they're powered on
23:07 Lekensteyn: I am testing with v4.6 + pci/pm + 4 patches from my nouveau-acpi-v2 branch
23:08 Lekensteyn: just put the root port in d0 again (by disabling its runtime pm), waited for some secs and then modprobed nouveau; this still results in "unknown chipset"
23:09 Lekensteyn: l1k: can the runtime_usage count ever become negative or will the kernel warn about it?
23:09 l1k: not sure.
23:10 l1k: I'd have to look at the code but my guess is that the kernel would warn
23:15 Lekensteyn: that's funny.. if it reports 'unknown chipset', then remove the device from the bus, then rescan, somehow I get a 01:00.1 Audio device: NVIDIA Corporation GM204 High Definition Audio Controller (rev a1)
23:16 Lekensteyn: happened before, just noticed it again
23:16 Lekensteyn: this device normally does not show up, I would only have a 01:00.0 VGA device. This laptop allows you to disable the integrated video card, not sure if that matters for this
23:17 pmoreau: Lekensteyn: I pushed a version here https://phabricator.pmoreau.org/diffusion/NOUVEAU/history/fix_T22_v2/
23:18 pmoreau: I need to go through it again, but mainly to reorganise the commits, rather than change the code.