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