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