08:50 ntz: hello
08:51 ntz: what's please this http://www.starenka.net/ntz/dmesg.txt ??? it's FULL dmesg, ``dmesg | head'' shows beginning of this
08:51 ntz: beyond the x on box are broken it wiped up a dmesg buffer ?
08:51 ntz: okay, taking back, dmesg is no longer since the start
08:55 mjg59: ntz: The dmesg buffer is only a certain size
08:56 mjg59: If you get too much kernel output you'll lose the start of it
08:56 ntz: yeah I see, I took it back
08:58 ntz: mjg59: anyhow, I'd be more interested if you can read ouyt something interesting nouveau related from my dmesg ... it's about old and supported:
08:58 ntz: 01:00.0 VGA compatible controller: NVIDIA Corporation G72 [GeForce 7300 GS] (rev a1)
08:58 mjg59: I'm afraid I'm not an expert on that side of nouveau
08:58 ntz: I had there old linux with 3.4 kernel that worked for many years
08:59 ntz: and yesterday reinstalled that I have kernel 4.4.87-25-default
08:59 ntz: result is as in here http://www.starenka.net/ntz/dmesg.txt
09:00 RSpliet: ntz: There's a kernel parameter that lets you increase the size of the log. Setting it to something ridiculously large might help capture the start of it
09:01 RSpliet: I suspect the first message will give away more valuable information that subsequent ones
09:48 ntz: http://www.starenka.net/ntz/dmesg-1.txt
09:49 ntz: content of my dmesg on 4.13.3-4.ge890e3e-default
09:51 ntz: http://www.starenka.net/ntz/messages_nouveau.txt
09:51 ntz: ^^ grep nouveau /var/log/messages
10:10 imirkin: ntz: sure you only changed the kernel and not the rest of userspace as well?
10:10 imirkin: 2017-09-26T11:34:51.072567+02:00 pajin kernel: [ 55.888550] nouveau 0000:01:00.0: sddm-greeter[1740]: multiple instances of buffer 36 on validation list
10:11 imirkin: that means that you either have a weird libdrm version or sddm-greeter is a multi-threaded GL app
10:11 imirkin: iirc libdrm 2.4.60 was the weird libdrm version that happened with, but i could be off by +/-2 versions
10:14 imirkin: aaronp: https://devtalk.nvidia.com/default/topic/1024022/linux/gtx-1060-no-audio-over-hdmi-only-hda-intel-detected-azalia/post/5211273/#5211273 -- which gpus does this apply for?
10:14 ntz: o.O
10:16 imirkin: ntz: iirc there was some distro where that broken libdrm was the version it shipped... some debian variant iirc? or fedora? i really don't remember.
10:16 ntz: libdrm_nouveau2-2.4.76-1.2.x86_64
10:16 imirkin: ah ok, that should be fine.
10:17 imirkin: i guess now we know whether building a gdm variant on top of gnome-shell was a good idea...
10:17 ntz: http://susepaste.org/view/raw/23638697
10:17 imirkin: i gtg. good luck
10:17 ntz: it behaves kinda random .... this is afrer reboot, just only these
13:45 halfline: imirkin: "gdm variant on top of gnome-shell" ← isn't your debug output for sddm ?
13:47 imirkin_: it is
13:47 imirkin_: i have no clue what sddm is
13:47 imirkin_: i was more generically referring to the giant frustration i have with opengl becoming a required component of regular life in 'modern' linux
13:48 karolherbst: imirkin_: skeggsb pushed a backport to nouveau, which may fix issues where there are a lot of concurrent memory page deallocations, could fix some silly memory issues
13:48 imirkin_: karolherbst: i saw. not holding out hope.
13:49 karolherbst: well, it's someting nvidia did on their tree as well
13:49 karolherbst: I am sure they had their reasons to do so
13:49 imirkin_: yeah. but it only matters if you access that zero'd PDE
13:49 imirkin_: which we shouldn't be accessing in the first place
13:49 imirkin_: unless we're doing something with sparse or something.
13:49 karolherbst: mhhh
13:49 karolherbst: not entirely sure if that's true
13:50 imirkin_: yeah - with sparse it should actually be populated
13:50 karolherbst: I mean, it's caching related, not sure what the MMU caches exactly
13:50 karolherbst: maybe could have triggered if the same physical region was allocated again?
13:50 karolherbst: regardless of the pgt entries
13:50 imirkin_: MMU caches page tables.
13:51 karolherbst: mhh, right, make sense
14:05 pq: imirkin_, use weston, it can run just fine on KMS without OpenGL! ;-P (I know, I'm wrong in so many ways.)
14:05 imirkin_: pq: yeah, on my infinitely-long list of things to do, is a ddx for weston
14:07 karolherbst: pq: by the way, skeggsb found one important mmiotrace bug, which might solve all remaining issues
14:07 pq: imirkin_, I think it would be much more useful to invent a 2D acceleration API you would be happy with.
14:07 karolherbst: pq: https://paste.fedoraproject.org/paste/gzlaoyx-g4yaTFlm~~Z9SQ
14:07 imirkin_: pq: isn't that what a DDX is?
14:07 imirkin_: the implementation of such an API
14:07 pq: imirkin_, I wasn't sure if you meant something weston or Xorg specific - I'd hope it'd be tied to neither.
14:08 imirkin_: well, maybe not specific, but informed by them?
14:08 imirkin_: i.e. supporting their various ops in a non-ridiculous fashion
14:08 imirkin_: but the chances of this ever happening are exactly 0
14:08 imirkin_: so i wouldn't be too worried about specifics :)
14:09 pq: sure, that'd be awesome - but who'd write and maintain all the drivers? Or would it have, errm... implementation on top of Vulkan? :-)
14:09 imirkin_: no clue. i'd write the nouveau one.
14:09 imirkin_: and everyone else would continue to be happy with their gles one.
14:12 pq: karolherbst, you mean nvidia does non-page-aligned ioremaps?
14:12 karolherbst: pq: exactly
14:13 karolherbst: pq: no idea why mmiotraces messes here up though, because I thought it doesn't touch the actual returned address
14:13 pq: I have very very vague recollection of the topic... but I cannot remember if it was "we thought we implemented it" or "we know no-one will do it"
14:13 karolherbst: guess I was wrong or the arming is buggy here
14:13 karolherbst: pq: in doubt the latter?
14:13 karolherbst: or maybe this is exactly what I messed up back then after adding support for huge pages?
14:14 pq: well, you cannot arm parts of a page, so maybe if you have two non-overlapping iomaps touching the same page, it'll explode?
14:14 pq: maybe, I dunno :-D
14:15 karolherbst: most likely
14:15 karolherbst: I arm the page masked by the page size mask
14:15 karolherbst: well
14:15 karolherbst: not exactly true
14:15 karolherbst: but I mark that page as existing
14:16 pq: the page tables deal only with whole pages, so
14:16 karolherbst: yeah
14:16 karolherbst: I don't see why it matters
14:16 karolherbst: but obviously it does
14:19 karolherbst: pq: anyway, this is a very good pointer, much better trying to find the issue if you have no clue what's actually broken
14:52 karolherbst: without comments: https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-tang.pdf
17:44 karolherbst: imirkin: okay, I can verify that this crysis tex shader compiles with my patches, but still need to fix the last issues
18:17 karolherbst: imirkin_: I have a problem now, I have to run that register merging stuff of splits/merges right before doing the actuall register allocations, because otherwise allocated registers are being ignored, because the liveness doesn't go beyond the split/merges, which is probably the reason it was done in the first place. Any ideas why it might be a bad idea to move that part to a later place (aka after having spilled enough to be able to allocated
18:17 karolherbst: registers)?
18:34 imirkin_: karolherbst: sorry, i don't have time to look at this
21:10 karolherbst: meh.. after RA it looks like this: https://gist.github.com/karolherbst/354af6fcfee8ddb141d57dd614a1dcd5
21:11 karolherbst: which looks technically correct, but still ...
21:11 imirkin_: the self-mov's get removed later
21:12 karolherbst: that's not the problem
21:12 karolherbst: the splits vanish into nothing
21:12 tobijk: i just wanted to ask about them :)
21:12 karolherbst: so we end up with both lds and some movs, cause the merged got resolved
21:12 karolherbst: but not the splits
21:12 imirkin_: "got resolved"?
21:12 karolherbst: imirkin_: https://gist.github.com/karolherbst/85b7f8d5ad6892ec72b30e8a3f090da1
21:12 karolherbst: kinda
21:15 karolherbst: maybe by removing those splits, I should simply move the initial load target, but this sounds super hacky to me
21:16 karolherbst: dunno if this happens because I skip filling the compMask or not