10:37 tomeu: imirkin: what do you think of this for systems such as tegra? http://paste.debian.net/1022306/
10:38 tomeu: not sure if this shouldn't happen in libdrm instead, or even in the kernel
10:46 RSpliet: tomeu: that would introduce a hard dependency on Linux, which for mesa is unacceptable
10:49 RSpliet: tomeu: I think "Thierry Reding" is the man you want to talk to about these kind of problems, he
10:49 RSpliet: 's the closest person we have to a Tegra expert :-)
10:50 RSpliet: Not sure if he's on IRC here (if he is, I forgot his nickname
10:50 RSpliet: but you can find him on the mailing lists
11:33 karolherbst: tomeu: also for mobile chips without dedicated RAM ;)
11:33 karolherbst: tomeu: worth checking how Intel reports it
11:34 karolherbst: on my intel GPU: "Video memory: 3072MB"
11:34 karolherbst: and this is also just sytem memory
11:35 karolherbst: intel hard allocates a small buffer like 256 or 512 on boot which is stolen from sys ram, but the other amount is just dynamically allocated
11:35 karolherbst: imirkin: getting that OP_CVT lowering right is kind of annoying. So many rules to keep in mind
11:38 karolherbst: there are F64 to S32 conversions and F32 to S16 and S32 to S8 (saturated), but no F32 to S8 or F64 to S16... :(
11:38 karolherbst: and even nvidias implementations is quite buggy in some places
11:39 karolherbst: buggy in the meaning of adding useless ops
11:40 karolherbst: f64 -> s8: https://gist.github.com/karolherbst/4e792878926dc1a59244236fabef4a42
11:40 karolherbst: I don't see the point of this last "I2I.S16.S8 R0, R0;"
11:42 karolherbst: mhh, maybe I spend some time figuring out what all those xmad variations are doing
11:43 karolherbst: pendingchaos: if you are getting tired of implementing extensions, you could also figure out what XMAD is :) it is some kind of weirdo instruction which doesn't only do MAD
11:43 tomeu: karolherbst: hmm, so maybe the kernel should be reporting system ram as vram?
11:43 karolherbst: it's some 16 bit alu instrucion, which can implement imad faster than using imad
11:44 karolherbst: tomeu: maybe? dunno
11:44 tomeu: tagr: what do you think of the above?
11:44 karolherbst: check the code if anything depends on that value being 0
12:30 pendingchaos:nods at karolherbst
12:31 karolherbst: duh... cvt.s8.s64.sat is not supported as well
12:32 snico: noticed that this was a major bug in the Ubuntu 18.04 release notes - i suppose there's been no recent activity around it? https://bugs.freedesktop.org/show_bug.cgi?id=103351
12:32 snico: asking as i have a gm204 card + DP monitor
12:33 karolherbst: uhh, seems like even cvt.s32.s64.sat isn't
12:33 karolherbst: snico: uhh, let me check
12:33 karolherbst: snico: what kernel is 18.04 on?
12:34 snico: karolherbst, 4.15
12:35 karolherbst: snico: on monday I can check if I can reproduce that issue. It is unlikely but maybe
12:35 snico: karolherbst, cool, thanks for having a look
12:35 karolherbst: snico: do you have by any chance a DP-MST hub or something? or is it directly connected?
12:36 karolherbst: DP-MST hub can be whatever device between the display and the GPU (usually these days)
12:36 pmoreau: karolherbst: Yup, they aren’t :-) Anything involving s64 or u64 isn’t supported by cvt, either as source or dest.
12:36 snico: karolherbst, it's directly connected. I haven't however tried if I can reproduce that bug yet, as I was just reading the release notes and noticed that (and figured it probably affects my setup)
12:36 karolherbst: pmoreau: duh :(
12:37 karolherbst: snico: ohh
12:37 karolherbst: snico: well if I can't reproduce it and you can't, we can't really figure out what's wrong and fix the bug :)
12:37 karolherbst: so best would be if you could just test it with a live boot image or something
12:37 snico: karolherbst, yeah i'll download an image today and try a live boot
12:38 karolherbst: snico: can you use a different cable like HDMI in case you can reproduce it?
12:38 snico: karolherbst, I do have a 2nd monitor with HDMI yes, but the DP monitor only supports DP
12:38 karolherbst: okay
12:38 karolherbst: remind me on Monday though, otherwise I might forget
12:39 snico: karolherbst, I actually lied, it's a DVI monitor, not a HDMI :p but yeah, that should get something on the screen if DP fails
12:39 snico: karolherbst, sure
12:40 karolherbst: pmoreau: right, I never noticed, because for !saturate I just lowered that to a split...
12:41 pmoreau: Yeah, which is what the blob does as well.
12:41 karolherbst: mhh to lower that saturated thing is a bit annoying
12:43 karolherbst:is currently wondering if he can be smarter lowering 8b/16b ops by checking what the previous up returns
12:45 pmoreau: I had a patch handling sat for at least some cases.
12:46 karolherbst: ohh, I am already pretty much done with the complete thing
12:46 karolherbst: complete means it passes all CL conversion tests
12:46 pmoreau: Ah okay, nice!
12:47 karolherbst: pmoreau: current status: https://gist.githubusercontent.com/karolherbst/a1f0979adc74dfba231b224b8a6be502/raw/a2f5b0387498f45fca0b5a9f869bb9f898d01a55/gistfile1.txt
12:48 karolherbst: long -> float is the other thing left I guess
14:22 tagr: tomeu: ugh... bad timing, I need to run now
14:22 tagr: tomeu: but I used to use this: http://paste.debian.net/1022339/
14:27 snico: karolherbst, I just tried but couldn't reproduce the DP problem
14:27 snico: running a live image
15:07 tomeu: tagr: hmm, do you think it's correct to use the gart for that?
15:08 tomeu: tagr: and, what have you been doing with compute and nouveau, if I may ask? :)
15:09 imirkin_: he's sent patches to fix up the compute class we use for tegra :)
16:38 karolherbst: pmoreau: your lowering was in that lower64bit opt pass, right?
16:59 pmoreau: karolherbst: Lowering of what?
17:00 karolherbst: 64 int cvts
17:24 pmoreau: Could be
17:24 pmoreau: I need to find the patch again
17:27 pmoreau: karolherbst: This is what I had: https://hastebin.com/inoxacizum.php
17:28 pmoreau: And no, it was in the regular pre-SSA lowering pass.
17:30 karolherbst: pmoreau: I see
17:30 karolherbst: pmoreau: this is my entire CVT lowering so far: https://github.com/karolherbst/mesa/blob/760db0121876279efe734c8ceacbac9dc6e4473b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_helper.cpp#L87-L180
17:59 tagr: tomeu: my understanding, though I admittedly get confused about it sometimes, GART represents the system memory that can be used by the GPU, so I think that's correct for Tegra
18:00 tagr: tomeu: I've been trying to keep track of what karolherbst, pmoreau and others have been doing with OpenCL, which is very interesting work
18:01 tagr: compute is one of the missing features upstream, but we're very close with OpenCL
18:01 karolherbst: tagr: "we" as in nvidia or "we" as the people working on the nouveau stuff :p
18:04 tagr: karolherbst: the latter =)
18:04 karolherbst: :)
18:04 karolherbst: did you get something working?
18:05 tagr: karolherbst: I haven't tried in a while because I got side-tracked with some multimedia stuff
18:05 karolherbst: ahh
18:05 karolherbst: currently I try to fix all the CTS compiler bugs :) and I think I am pretty close
18:05 tagr: but last time I tried I think some basic tests were succeeding, though not reliably (perhaps a missing fence or something)
18:05 karolherbst: yeah..
18:05 karolherbst: I guess you used the v3 branch?
18:06 tagr: I think so, or maybe v2?
18:06 karolherbst: I wrote a non crappy runner for running inside test_conformance: https://gist.github.com/karolherbst/1373fa96baa1e1045573dbb91d125290
18:06 karolherbst: pass rate should be around 70 to 75%
18:06 karolherbst: but you need llvm7 and the new LLVMSPIRV-Translator + v4 of my branch
18:06 tagr: I have occasionally updated my tree and was seeing all of the interesting updates, I'm looking forward to go back and try the new work again
18:08 tagr: heh... not looking forward to LLVM 7 very much, I'm sure it's going to be a pain to get it to cross compile like LLVM 6 was
18:10 karolherbst: robclark was able to crosscompile it for his freedreno stuff
18:10 karolherbst: (I think)
18:10 tagr: tomeu: my long-term goal is to be able to run our proprietary CUDA on top of Nouveau, but before I go anywhere near that I want to be sure all the basics are in place
18:10 robclark:not cross compiling
18:11 karolherbst: ohhh right, you compile on the arm device
18:11 tagr: karolherbst: I guess it's possible that the cross-compile changes aren't big
18:11 tagr: admittedly once I had everything figured out it was cross-compiling pretty reliably
18:12 tagr: robclark: oh boy... natively compiling LLVM on ARM doesn't sound like fun, how long did it take?
18:13 robclark: hmm, not sure exactly.. I just left it building while I was doing something else ;-)
18:14 tagr: well, I guess if you don't need to rebuild all the time it's probably okay
18:14 tagr: cross-building was actually really fast, didn't take much longer than 20 or 30 minutes
18:21 robclark: heh, natively building basically killed my laptop (but I was building w/ debug symbols and not limiting number of linker threads.. so >4 linker processes in parallel each trying to use ~4G and hitting swap hard didn't go so well)
18:22 robclark: well, I'll time llvm build, I rewound to an older commit to match karolherbst and seems like it is rebuilding the world..
18:22 tagr: robclark: yeah, I had the problem when building with debug symbols, it kept running out of memory
18:22 karolherbst: I kept running out of memory while linking
18:22 karolherbst: :(
18:23 robclark: probably swapoff first so oom killer kills stuff before it makes your compute unresponsive ;-)
18:23 karolherbst: :)
18:26 karolherbst: tagr: it really annoys me a little that the hardware can't do 64 bit conversions :(
18:26 karolherbst: or not really
18:28 tagr: karolherbst: I'm not at all familiar with any of those details, I'm afraid
18:29 tagr: are you sure it can't or is it just that you don't know how?
18:33 karolherbst: tagr: it can't
18:33 karolherbst: cvt only supports all 32/16 combinations
18:34 karolherbst: limited fp64 to ints
18:34 karolherbst: and no int64 at all
18:34 karolherbst: converting from fp64 to u8 works like this: fp64 -> u32 -> u8
18:34 pmoreau: tagr: I get invalid encoding when running such a cvt on my Kepler, even if nvdisasm properly parses the instruction.
18:34 karolherbst: which is quite trivial as long as no rounding modes + saturation gets involved
18:35 karolherbst: but with rounding and saturation? Have a fun time writing the lowering in the driver :)
18:41 tagr: that's somewhat surprising
18:41 tagr: I thought there were changes in the ISA for Volta, perhaps the CVT instruction was improved?
18:44 juri_: ok! nouveau test box completed!
18:45 tagr: karolherbst: https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#type-conversion
18:45 karolherbst: tagr: PTX supports those, yes
18:45 karolherbst: not the hw though
18:46 karolherbst: PTX is a lie :p
18:46 tagr: heh... there's certainly some irony there =)
18:46 imirkin_: tagr: there are encodings that nvdisasm recognizes but the hw doesn't like
18:46 juri_: i now have a machine with option rom execution disabled, USB boot, onboard amd video as the primary adapter, a 'bitcoin' riser, and twelve cards for hacking on!
18:46 imirkin_: tagr: PTX is a high-level language which compiles into actual ops, so isn't necessarily a great reference for the hw's capabilities
18:47 tagr: imirkin_: understood
18:48 imirkin_: (not high-level like cuda is high-level, but ... still ... not-the-isa)
18:48 tagr: hopefully the goal is to eventually support everything that PTX allows
18:48 imirkin_: karol is just complaining that he has to do work for some stuff
18:48 imirkin_: instead of having it be nice and simple and directly supported by the hw :)
18:48 HdkR: tagr: ptx has always been similar to the isa, but never a direct match :P
18:49 karolherbst: exactly, I wished I had less work to do
18:49 karolherbst: imirkin_: I think I am pretty much done though
18:50 imirkin_: if one were inclined to convey thoughts to the hw team, one might mention that they should stop changing the f@#king TEX operation's argument orders
18:50 HdkR: imirkin_: never
18:50 karolherbst: imirkin_: I am sure they changed it with volta, but now that's a 128 bit ISA, I doubt they actually have to anymore
18:50 imirkin_: i assume it's different again in volta...
18:50 HdkR: :P
18:51 karolherbst: maybe they just do
18:51 imirkin_: the fermi -> kepler change is the most vexing
18:51 karolherbst: to annoy devs
18:51 imirkin_: since it's the same ISA encoding
18:51 imirkin_: but the args just mean different things
18:51 imirkin_: they did have a good reason there. but still annoying
18:51 imirkin_: and then they just got crazy on maxwell, changing things around for seemingly no good reason
18:53 HdkR: :>
18:53 imirkin_: i assume it's all shuffled around on volta again
18:53 imirkin_: coz why not
18:53 HdkR: :>
18:53 imirkin_: i was half-surprised it wasn't different on pascal
18:53 HdkR: hehe
18:53 imirkin_: maybe with 128-bit they get rid of the TEX-style thing and just do TEXS-style
18:54 imirkin_: that'd be nice
18:54 imirkin_: no more quad-wide groups
20:34 karolherbst: pmoreau: you also forgot long<->ulong saturate conversions :)
20:35 karolherbst: but this is like one of the more trivial cases
21:00 john_cephalopoda: Hey. I just experienced a system freeze with Kerbal Space Program and nouveau. I have experienced many freezes with nouveau, but never one that looked like that.
21:00 john_cephalopoda: https://ahti-saarelainen.zgrep.org/~jmf/tmp/nouveau.jpg
21:02 john_cephalopoda: After sysrqing, I was able to escape X, but the tty text was pretty glitched out and neither "clear" nor "reset" could solve that.
21:02 john_cephalopoda: Here's a complete kernel log from boot until crash: https://bpaste.net/raw/5ce8bef64323
21:03 john_cephalopoda: Linux 4.14.12, Mesa 17.3.9, xorg-xf86-video-nouveau 1.0.15, VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 645 OEM] (rev a1)
21:09 john_cephalopoda: I can't reproduce that error, might be related to anything :/
21:12 imirkin_: i've seen that before
21:12 imirkin_: something gets messed up
21:12 imirkin_: and there are random blocks that appear
21:13 john_cephalopoda: I didn't have those blocks before, usually everything just freezes. Maybe this case is related to the other ones but this time some shader interfered or something.
21:14 imirkin_: based on limited investigation there's no way out
21:15 imirkin_: i.e. gotta reset the thing
21:15 imirkin_: i'm sure there is in practice, if we knew exactly what was messed up
21:15 john_cephalopoda: Ah, thanks, good to know.
21:15 imirkin_: but in practice, we have to figure out how to reset the board "at runtime"
21:15 imirkin_: without messing up userspace more than necessary
21:16 imirkin_: but this is painful and thankless work
21:16 imirkin_: and invites crazy people saying "hey, i have this undiagnosable issue which is IDENTICAL to this other undiagnosable issue" and wanting you to fix the universe
21:17 imirkin_: i just ignore any bugs filed that result in a hang of some sort
21:18 john_cephalopoda: I could try to find a way to reliably reproduce that issue. Maybe that way through debugging a solution could be found.
21:18 imirkin_: even if you did
21:18 imirkin_: it's still unsolvable.
21:18 imirkin_: we need a way to recover from shitty situations
21:18 imirkin_: until that happens, this is all just an exercise in avoiding the hang in the first place
21:19 imirkin_: and that's not always possible given our resources
21:19 imirkin_: (and i'm not even talking about time)
21:21 karolherbst: john_cephalopoda: is there a fast way to reproduce that?
21:21 karolherbst: or just happens randomly?
21:21 imirkin_: every so often there's a reproducible hang which is debuggable
21:22 imirkin_: but it still takes a lot of effort
21:22 john_cephalopoda: karolherbst: I'll try if the specific action I did in KSP triggers it.
21:22 imirkin_: and relies in part on noticing something specific
21:22 karolherbst: imirkin_: sure, but if I can reproduce this within a few minutes I could work on that
21:22 imirkin_: right
21:22 imirkin_: i'm just thinking back to the issue i fixed with dirt rally + bindless hanging
21:22 imirkin_: had absolutely nothign to do with bindless, of course
21:22 karolherbst: right
21:22 karolherbst: just random stuff
21:23 john_cephalopoda: I got ideas how to trigger a freeze, but I don't know if the KSP one is related to my usual freezes :þ
21:23 imirkin_: but it did repro at the exact same point in the load sequence
21:23 imirkin_: which allowed me to add 10000 prints
21:23 imirkin_: which eventually led me down the right path
21:23 karolherbst: john_cephalopoda: everything which doesn't take a long time to hit is nice
21:23 imirkin_: [missing kick when changing the code segment? something like that.]
21:23 karolherbst: annoying are those "freezes once in a week" issues
21:24 karolherbst: imirkin_: I find those sched opcode bugs pretty annoying as well, no idea how many of those are still out in the wild and we just don't know that's just that
21:24 karolherbst: like missrendering because address calculation got screwed up or something silly like this
21:24 imirkin_: well, i just have the one GM107 board, and it's rare that i have it plugged in
21:25 john_cephalopoda: Ok, the KSP error doesn't seem to be reproducible.
21:25 karolherbst: right, I am more talking about our random maxwell issues we still have
21:25 imirkin_: i just mean - they don't annoy me that much :)
21:25 karolherbst: :D okay
21:25 karolherbst: maybe I take some time and investiage those unigine issues
21:25 karolherbst: this would be nice to actually fix
21:25 imirkin_: might be easier to investigate the issue in xonotic
21:26 imirkin_: i think it's simpler software
21:26 imirkin_: and it's 100% reproducible
21:26 karolherbst: ohh
21:26 imirkin_: although iirc it didn't actually always happen on the same frame
21:26 karolherbst: yeah, that's nice
21:26 imirkin_: but i had an apitrace which repro'd a random red block
21:26 imirkin_: floor tile or something, i forget
21:26 imirkin_: i stared at it for a while and there was no good reason for it
21:26 imirkin_: which leaves a lot of bad ones :)
21:27 karolherbst: :)
21:27 karolherbst: did you disable sched? :p
21:27 imirkin_: there was no sched stuff at the time
21:27 karolherbst: ahh
21:27 imirkin_: so it was all 0x7e0
21:27 imirkin_: which afaik is not 100% sufficient
21:27 imirkin_: but i don't think this was a sched issue.
21:27 imirkin_: iirc MESA_DEBUG=flush fixed it
21:28 karolherbst: We need to rework codegen a bit to allow settings opts in non debug builds and also disable the sched opcode
21:28 karolherbst: just, what to do with the builtin lib?
21:28 imirkin_: can jam it at upload time
21:28 karolherbst: imirkin_: uhh, sounds like an annoying bug then
21:28 imirkin_: definitely annoying.
21:28 karolherbst: imirkin_: right, but two versions or just replace every fourth row?
21:29 imirkin_: replace every 4th 64-bit op with a fixed value
21:29 karolherbst: mhh, yeah, sounds reasonable
21:29 imirkin_: slightly hacky, but ... meh
21:29 karolherbst: just, I think we need proper sched for some stuff?
21:29 imirkin_: i've done worse :)
21:30 karolherbst: disabling opts in CL shouldn't result into things not working...
21:30 imirkin_: that'd be nice.
21:30 imirkin_: i don't think sched is optional though
21:30 imirkin_: 0x7e0 isn't always sufficient, i think
21:30 karolherbst: nvidia disables it in ptxas if compiled with O0 at least
21:30 imirkin_: it's just sufficient in enough cases
21:30 karolherbst: but maube it is still properly done for the cases which really need it
21:31 karolherbst: "-cl-no-signed-zeros" "Allow optimizations for floating-point arithmetic that ignore the signedness of zero."... does that matter so much, that it makes sense to actually add this to the spec?
21:32 karolherbst: "-cl-finite-math-only" is fine as well
21:32 karolherbst: *fun
21:32 imirkin_: yeah, all this stuff matters
21:32 karolherbst: I meant for performance
21:33 imirkin_: rarely.
21:33 karolherbst: sure it matters, but are there use cases which get a significant perf boost by being a bit more sloppy?
21:33 imirkin_: half our opts are sloppy
21:33 karolherbst: :)
21:33 karolherbst: I think they stay that way until the CTS complains or some application is annoyed
21:34 imirkin_: thing is that foo + 0.0 -> foo is sloppy
21:34 karolherbst: NaN?
21:34 imirkin_: if e.g. foo is -0, one result will be 0, one will be -0
21:34 imirkin_: NaN too.
21:34 imirkin_: actually no
21:34 imirkin_: NaN + 0 == NaN
21:35 imirkin_: so that's fine
21:35 karolherbst: mhh, right
21:35 karolherbst: foo * 0.0 -> 0.0
21:35 karolherbst: :)
21:35 imirkin_: that's extremely sloppy
21:35 imirkin_: coz NaN / Inf blow this up
21:35 karolherbst: yeah
21:35 karolherbst: but then "cl-unsafe-math-optimizations" helps
21:36 imirkin_: but it seems perfectly safe in a glsl world
21:36 imirkin_: where just about anything one can care about is undefined
21:36 karolherbst: nicne
21:36 imirkin_: i even added a MUL_ZERO_WINS property
21:36 karolherbst: *nice
21:36 imirkin_: for st/nine
21:36 karolherbst: ahh
21:37 imirkin_: which is literally telling mul to not generate a NaN if either arg is 0
21:37 karolherbst: so d3d defines things a bit more precise than glsl?
21:37 imirkin_: mmmmm ... d3d9 was from a time before NaN existed in graphics
21:37 karolherbst: ohhh
21:37 imirkin_: there were lots of programs that made this assumption
21:37 karolherbst: I see
21:37 imirkin_: so NaN's coming into the middle of careless computations would destroy the universe
21:37 karolherbst: makes sense
21:38 imirkin_: d3d10 either requires or at least encourages IEEE rules
21:40 karolherbst: oh well
21:40 karolherbst: I just hope things are good enough
21:41 HdkR: D3D10+ has nan things?
21:42 HdkR: Is it as much as GLSL nan things? :P
21:42 imirkin_: i dunno from a spec standpoint
21:42 imirkin_: however from a practical standpoint, the expectation is that nans exist
21:42 imirkin_: and that 0 * inf = nan
21:42 HdkR: How curious
21:42 karolherbst: mhh
21:42 karolherbst: it is a bit weird that 0 * inf = nan though
21:43 imirkin_: should it be 0 * inf = 1?
21:43 karolherbst: I mean from a math perspective you kind of would expect 0
21:43 imirkin_: since inf = lim x as x -> inf, while 0 = lim 1/x as x -> inf
21:44 imirkin_: so inf * 0 = lim x/x as x -> inf = 1 ?
21:44 imirkin_: (this is why it's nan)
21:45 karolherbst: inf is weird anyway
21:46 imirkin_: there are various rules that exist in math to avoid impossible thigns from happening
21:47 imirkin_: one such problem comes up when multiplying 0 and infinity
21:47 imirkin_: infinity is not a nice clean thing that exists in the reals
21:47 karolherbst: well 0 multiplied with inf isn't defined
21:47 imirkin_: and as such, multiplication with it is not well defined
21:47 karolherbst: inf isn't a number to begin with
21:48 imirkin_: iirc there are other groups (fields?) like super- or hyper-reals, which talk about infinity and epsilon in intelligent ways
21:48 karolherbst: uhh
21:48 karolherbst: okay right, but that's a bit advanced then
21:49 imirkin_: https://en.wikipedia.org/wiki/Hyperreal_number
21:49 imirkin_: hyper-reals
21:50 imirkin_: but without that, infinity (and epsilon) are weird not-well-defined things
21:50 imirkin_: that it's hard to reason about in terms of regular math operations
21:51 imirkin_: those operations are defined in terms of members of the real field, and since infinity/epsilon aren't single members of that field, it's a bit moot
21:51 imirkin_: (similarly, infinity - infinity = nan)
21:52 karolherbst: mhh well infinity isn't defined at all for real numbers
21:52 karolherbst: simply doesn't exist
21:52 imirkin_: exactly.
21:53 imirkin_: so it's thrown in with some basic rules to avoid silly situations
22:10 karolherbst: nice, all conversions subtests are passing now :)
23:05 nullspoo1: Well, I'm back at it. I vaguely recall getting pgraph errors a previous time I tried troubleshooting this. Any tips on a 1050ti getting 'nouveau 0000:01:00.0: timeout' when executing anything with DRI_PRIME=1?
23:06 nullspoo1: I also get "nvc0_screen_create:891 - Error allocating PGRAPH context for M2MF: -16"
23:08 imirkin_: the latter means that acceleration didn't come up
23:09 imirkin_: generically speaking it should work ... is this a mobile setup, or a desktop board?
23:10 nullspoo1: mobile
23:10 imirkin_: ah, iirc there are a bunch that don't come up properly due to a variety of power management fail
23:10 nullspoo1: I recall reading about that
23:11 nullspoo1: The tip I got last time I tried working on this was modprobe nouveau with runpm=0
23:11 imirkin_: right. did that help?
23:11 nullspoo1: sadly, no
23:11 nullspoo1: It used to work
23:11 nullspoo1: When I do it now, /var/log/kernel dumps a few traces.
23:11 imirkin_: there's also various pcie pm stuff
23:12 nullspoo1: looking that up now
23:12 imirkin_: pcie_pm=off or something?
23:12 imirkin_: i forget exactly
23:12 nullspoo1: Would that be a kernel level param, or module level?
23:13 imirkin_: kernel (pci core)
23:13 nullspoo1: hokay
23:13 nullspoo1: looks like it might pcie_port_pom?
23:13 nullspoo1: pm*
23:13 imirkin_: yeah, that sounds better
23:15 nullspoo1: Hmmm
23:15 nullspoo1: Odd. Looks like my slots directory is empty
23:23 karolherbst: nullspoo1: pascal GPU?
23:23 karolherbst: ahh 1050ti
23:23 imirkin_: 1050ti usually is.
23:24 karolherbst: yeah, there are secboot issues
23:24 karolherbst: imirkin_: its not fun, but this helps: https://github.com/karolherbst/nouveau/commit/67c57185d716792f806b73f24bf3826040b217a1
23:24 imirkin_: lol
23:25 imirkin_: bbl
23:25 karolherbst: nullspoo1: if you want, you could compile your own kernel with a patch like this applied
23:25 karolherbst: this should get things kind of working
23:26 karolherbst: allthough you propably want nouveau.runpm=0 as well
23:26 karolherbst: nullspoo1: but you say it used to work?
23:39 nullspoo1: Sorry about that - had to reboot and fix a few things
23:40 nullspoo1: karolherbst: Yeah, I got it working...once
23:40 karolherbst: ahh
23:40 nullspoo1: Incidentally, I got rid of these traces
23:40 karolherbst: yeah, that doesn't really count
23:40 nullspoo1: Had some really weird xorg issues that were happening. deleted my xauthority file and all seems fine now with that.
23:40 nullspoo1: I modprobe nouveau with runpm=0 and it doesn't hang like it was.
23:41 nullspoo1: now with DRI_PRIME=1 I get 'nvc0_screen_create:821 - Base screen init failed: -19
23:42 nullspoo1: No messages in kernel log at all.
23:43 nullspoo1: erm, should I be using the modesetting driver?
23:44 karolherbst: mhh, there should be something coming up in dmesg
23:44 karolherbst: the x log doesn't matter here really
23:44 nullspoo1: ah, yes, got 'DRM: Pointer to TMDS table invalid'
23:45 karolherbst: mhh, sad
23:45 nullspoo1: Also see BIT table 'A' and 'L' not found messages.
23:45 karolherbst: there should be something else though
23:45 karolherbst: like a wait timeout or something
23:45 nullspoo1: nope
23:46 nullspoo1: I amazingly, the logs look like everything worked.
23:46 nullspoo1: ' [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 1'
23:46 nullspoo1: Grepping -i for 'time', nothing that looks like an error or warning of any sort.
23:47 nullspoo1: My xorg log does show me that glamor initialization failed. something about 'EGL_MESA_drm_image required'
23:48 nullspoo1: ohhhh. I bet this is my fault. I booted up with nouveau.noaccel=1
23:48 karolherbst: uhhh
23:48 karolherbst: yeah
23:48 karolherbst: that will make things not work as well
23:51 nullspoo1: There we go. Booted without that arg and now my system freezes again with runpm=0
23:51 nullspoo1: Got traces in my logs again.
23:52 nullspoo1: Annnnnd the timeout. ' nouveau 0000:01:00.0: timeout '
23:55 nullspoo1: Also got 'nouveau 0000:01:00.0: gr: init failed, -16' and 'nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 409800 [ TIMEOUT ]'. Running with DRI_PRIME causes the command to hang.
23:57 RSpliet: EBUSY? ...
23:57 imirkin: i think that's what happens when a nvkm_wait fails