14:01 infinity0: this devel-clk crashed my computer twice now with pstate = 07 and touch my mouse whilst xscreensaver was active
14:02 infinity0: no kernel logs available :(
14:02 karolherbst: infinity0: "devel-clk"? you mean on skeggsb branch?
14:02 infinity0: yes
14:03 karolherbst: fermi gpu?
14:03 infinity0: works well otherwise, no "spontaneous" crashes
14:03 infinity0: yes fermi
14:03 karolherbst: mhh, are you setting the pstate?
14:03 infinity0: yes to 07
14:04 karolherbst: mhh, well that did nothing before his pathces
14:04 infinity0: 01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560 Ti] (rev a1)
14:07 karolherbst: well right, but as I said, without his patches, that changing pstate did nothing at all
14:08 karolherbst: I am sure you can help skeggsb figuring out what went wrong
14:18 infinity0: yeah i'm just reporting this in case anyone wants me to poke around here further
14:18 infinity0: i checked syslog and kern.log already and no traces
20:38 iterati: Hi, any idea why this happens: https://bpaste.net/show/af67fc8e1750 and if there are plans to fix it.
20:39 iterati: It's all great the work that all contributors are doing, especially without much support from nvidia, but with so many crashes maybe the driver should not even be mainlined...
20:51 airlied: imirkin_: can you classify you anti nkr stance as anything other than personal feeling that everyone ignored nvir?
20:52 imirkin_: i have some beliefs about how things should be structured
20:52 airlied: as for private project rh stuff just ignore it, it really doesnt matter wrt to this
20:52 imirkin_: and they differ from what some other people have pushed
20:52 imirkin_: specifically, the situation is that nouveau's codegen is a perfectly capable optimizing compiler
20:52 imirkin_: (sure, it has some bugs, but what doesn't)
20:52 airlied: imirkin_: so is llvm but we still used nir on radv
20:53 imirkin_: but i don't necessarily think that's a good idea.
20:53 imirkin_: llvm should be capable of consuming spir-v directly
20:53 imirkin_: and ought to be able to do a better job than going through some intermediate first
20:54 imirkin_: since i suspect that information is lost in the spir-v -> nir conversion
20:54 airlied: what info?
20:54 imirkin_: this may matter less for VK than it does for CL
20:54 airlied: no bas in here, but spirv to llvmhas some downsides
20:54 imirkin_: but afaik nir doesn't have a "grown up" approach to rounding
20:55 airlied: well if you want a vk driver abd gl spirv doing non nir is stupid
20:55 imirkin_: sorry, have a hard time parsing that
20:56 imirkin_: in my ideal world
20:56 imirkin_: nouveau gains a SPIR-V input which can be used for both CL and VK (+ ARB_spirv)
20:56 airlied: if the end goal is to have a vulkan driver and support spirv in gl, then you are doing pointless make work
20:56 imirkin_: and keeps its existing TGSI input for plain GL
20:57 airlied: the spirv code has to interact with gl stack as well,
20:57 airlied: not just gallium
20:57 airlied: does nvir have a cross stage linker?
20:57 imirkin_: nope. (what would that do?)
20:58 imirkin_: DCE code based on outputs that aren't used?
20:58 airlied: allow for cross stage optikisations
20:58 imirkin_: right. no, it does not presently have that.
20:58 dziadu: hi guys, from time to time my X server (with plasmas 5) crasses completely on random events like pressing closing window butoton, clicking window on task bar, etc, and this is what I found in dmesg log
20:58 dziadu: https://pastebin.com/1kAjZGkv
20:59 dziadu: looks like nouveau is crashing
20:59 dziadu: at the moment I switched to nvidia since the crash happens average once per day
20:59 imirkin_: dziadu: lots of people have issues with nouveau and plasma5
20:59 dziadu: I am using 4.15.1
20:59 dziadu: imirkin_: what is then best solution?
20:59 airlied: imirkin_: i dont think maintaining a separate spirv makea sense and it will place nouveau at evem more of a longterm disadvantage
20:59 imirkin_: my recommendation thus far has been "either stop using nouveau, or stop using plasma5". i realize that's hardly perfect from your viewpoint though.
21:00 airlied: for cl it might provide some short term gains, but for vk/gl its a shitty idea
21:01 imirkin_: airlied: do you strongly believe that a NIR -> NVIR adapter is going to be more effort to maintain than a SPIRV -> NVIR adapter?
21:01 imirkin_: ignoring any initial "creation" costs
21:02 airlied: imirkin_: nothe opposite
21:02 dziadu: imirkin_: is the reason for crashes know, any solution on horizoin?
21:02 airlied: i believe a spirv to nvir has a larger cost
21:02 airlied: e.g
21:02 imirkin_: airlied: for maintenance once it exists? or initially creating it?
21:02 airlied: imirkin_: the former
21:02 airlied: i think creation is about the same
21:03 imirkin_: dziadu: nope. and the most likely person to debug it (me) has no interest in installing kde.
21:03 airlied: radv has picked up a bunch of free spirv exxtensions
21:03 airlied: without much backend work
21:03 imirkin_: airlied: what i really don't want to get into
21:03 airlied: we also fix app spirv bugs cross driver
21:04 imirkin_: is a situation where $other driver with a lot more development power needs something to be done a certain way
21:04 imirkin_: and that complicates matters for nouveau
21:04 imirkin_: or the inverse case, where nouveau needs something to be done a certain way
21:04 imirkin_: but that is detrimental to $other driver
21:04 imirkin_: or requires a lot of effort to be plumbed through "cleanly"
21:05 airlied: imirkin_: vs a large body like khronos?
21:05 imirkin_: hm?
21:05 airlied: you arent defining spirv either here
21:05 imirkin_: yeah, i know
21:05 imirkin_: i mean like ... spirv -> nir is done a certain way
21:06 imirkin_: and let's say something about it is inconvenient for nouveau
21:06 imirkin_: but presumably it's convenient for the other users
21:06 airlied: imirkin_: what is inconvient?
21:06 imirkin_: it's a hypothetical.
21:06 imirkin_: it's a shared bit of infra
21:06 imirkin_: and everyone has to play nice
21:06 imirkin_: what that means in practice is that the people with the most development power get what they need
21:07 imirkin_: and the people with little development power are stuck playing catchup
21:07 airlied: imirkin_: seems overly cynic
21:07 imirkin_: well, i ain't exactly known for being an optimist
21:07 airlied: you will always be playing catchup
21:07 imirkin_: but that's the current situation with e.g. the various gallium changes
21:07 airlied: keeping up with spirv isnt 0 effort
21:07 imirkin_: yeah, but it's 100% on us. other people aren't breaking us.
21:08 airlied: imirkin_: o had to rewrite atomic due to nouveau
21:08 airlied: so i have examples in the othet direction to!
21:08 imirkin_: not sure what that means ... but i wasn't involved in it
21:09 airlied: you wrote gallim atomics interface to suit nouveau
21:09 imirkin_: and discussed with radeonsi
21:09 airlied: yup but you still got to dictate a direction thst wasnt perfect for others
21:10 imirkin_: yes.
21:10 airlied: you arent powerless here
21:10 imirkin_: not completely.
21:11 airlied: i think you are overinflating the future possibilities
21:12 imirkin_: otoh i spent a bunch of time debugging stuff related to some gallium interface changes recently
21:12 imirkin_: (although i didn't know it was related to them before i started debugging)
21:12 imirkin_: but you're right. first-to-implement "wins" because they get to implement it however they like.
21:12 imirkin_: (within reason)
21:13 airlied: you make it sound like all your problems will be fixed if you didnt have to interact eith others
21:14 imirkin_: and fwiw i explicitly considered the r600 situation with atomics and we even discussed it, and iirc the result was "just do it however, we'll fix it up when r600 becomes a thing"
21:14 imirkin_: :)
21:14 imirkin_: not *all* my problems...
21:14 airlied: yup and i expect the same thing to happen eith nir
21:14 airlied: you get support to fix things when you need to
21:16 imirkin_: so you're right - it's a tough balance
21:16 imirkin_: the desire to not have others break your shit, balanced with the desire to benefit from others' work
21:17 imirkin_: i know i've jumped through a ton of hoops to pipe stuff through gl -> tgsi -> nvir which felt like they could have been much simpler if i didn't have to care about others
21:18 imirkin_: with spir-v, it seems like the sort of thing where the shared is less valuable. perhaps i'm underestimating how shitty spir-v is to consume.
21:20 airlied: well spirv isnt a single rhing either, and maybe a cl spirv parser needs to be a separate thing to gl/vk spirv
21:21 imirkin_: (probably doesn't need saying, but should be obvious that consume GLSL is such a giant disaster, that almost any amount of pain due to "shared" is worth it to have a single piece of code that parses it)
21:21 imirkin_: that would be extremely disappointing.
21:24 airlied: cl and vk spirv are quite different once you move past the initial same structure, and i dont think nir is quite ready for cl
21:42 imirkin_: main thing was unstructured i thought
21:42 imirkin_: plus a bunch of new alu-ish ops
21:43 airlied: and rounding, precision
21:43 imirkin_: right
21:43 airlied: ios
21:43 imirkin_: ios?
21:44 airlied: vk has descriptor sets
21:44 airlied: cl has global mem and buffers images
21:44 imirkin_: right
21:44 airlied: though gl also has buffers and images
21:45 karolherbst: well we would map those to different things in NIR, right?
21:46 karolherbst: I don't like the idea of sharing the same stuff across graphics and compute, I already had discussions with robclark about that, where he just wanted to map global memory to buffers first for example
21:46 karolherbst: if things are different, it should be different explicitly
21:47 imirkin_: well, nvidia does special things for images, but buffers are just addresses in memory
21:47 karolherbst: things like sign() are also different in CL and GL
21:47 karolherbst: but in spir-v the GL and CL sign() are different opcodes as well
21:47 karolherbst: and I hope that every difference is explicit like that
21:47 karolherbst: imirkin_: right, but with physical memory you can also "real" pointers
21:47 karolherbst: not some buffer mapped at X + your offset
21:48 karolherbst: but 0x0 + your pointer
21:48 karolherbst: so you could map a buffer at 0x0 and go on with live
21:48 imirkin_: yeah i know
21:48 karolherbst: but I would rather just have load/store global and move on
21:48 karolherbst: things are different, no need to be smart to try to hide it
21:49 karolherbst: imirkin_: another thing we didn't decide on yet is, that if we want to have an explicit load_param intrinsic or map inputs to uniforms
21:49 karolherbst: for nouveau going with load_param is the better choice, because it leaves the decision to the driver on how and from where to load the kernel input
21:49 imirkin_: you mean for CL?
21:50 karolherbst: yeah
21:51 airlied: also gl spirv parsing has to interact with gl stack
21:51 karolherbst: right
21:51 airlied: which is done for.you
21:51 karolherbst: also for compute though
21:51 karolherbst: like textures/sampler references
21:52 karolherbst: or rather images..
21:54 karolherbst: I mean, I tried to work with both, spir-v to nvir and nir to nvir and for me, dealing with nir seems to be much easier. I can't say anything about long term benefits of either path, allthough I think that being able to share work will be important for Nouveau, because we kind of lack devs all over the place
21:56 imirkin_: the flip side is the frustration of dealing with breakage caused by others, or having to carefully modify existing things to avoid breakage. and endless discussions of what is "the right thing"
21:56 karolherbst: right
21:56 karolherbst: but that's why we need a proper CI system
21:56 imirkin_: yeah, that'd be pretty awesome
21:57 karolherbst: right
21:57 karolherbst: and I am already working on getting something done for Nouveau here
21:57 imirkin_: mostly that just requires hardware sitting in an internet-connected space.
21:57 karolherbst: right
21:57 imirkin_: (dedicated hardware)
21:57 karolherbst: RH buildings for example
21:57 imirkin_: yep. that's a fine example of such a place.
21:57 karolherbst: :)
21:57 karolherbst: guess what I am planning to do here
21:58 imirkin_: copy janesma? :)
21:58 karolherbst: I was rather thinking of working on ezbench with mupuf for this
21:59 karolherbst: but yeah, we could also use somethign like this
21:59 karolherbst: but what is important, that we track down regressions and so on
21:59 karolherbst: so we need piglit runs and so on
21:59 karolherbst: automated
22:00 karolherbst: I am still at the very start here, but this is something I really want to do here as well
22:02 karolherbst: imirkin_: well, you are not alone with the frustration though. I already encountered that a few times working on the NIR stuff, but for me this is just a part when working together with others on the same thing
22:02 karolherbst: but yeah, good point nethertheless
22:12 karolherbst: imirkin_: also my opinion on stuff is, if somebody writes commits breaking other drivers, we should be free to just revert it. If somebody didn't feel the need to ask others to test stuff before merging, knowing it might break other drivers, I would also feel no hesitation reverting that stuff if it breaks something.
22:12 imirkin_: mmmm ... i'd say step #1 is "notice that there are regressions" :)
22:12 karolherbst: right
22:12 imirkin_: everything on top of that is just gravy
22:12 imirkin_: well like marek's change was noticed to break things 6 months later.
22:12 karolherbst: I mean, we should be still careful
22:13 karolherbst: right
22:13 karolherbst: having a proper CI might help us here detection some of the regressions early
22:13 karolherbst: *to detect
22:13 imirkin_: although i remember thinking about it at the time
22:13 imirkin_: but i was super-busy and couldn't do a review
22:13 karolherbst: mhh
22:13 imirkin_: i'm not even sure why it works on the other gpu's
22:13 imirkin_: i'm guessing luck
22:14 karolherbst: I had the same thing with some nir changes, looked at the patch as was like: "yeah, that will break stuff", but didn't check it out, so things broke on my branch...
22:14 karolherbst: imirkin_: so what we can do next is, just drop a comment and say: "I am sure this will break stuff on Nouveau, please ask somebody to test here before merging"
22:15 karolherbst: and if it gets merged, and it breaks stuff, you can always go "told ya"
22:15 karolherbst: and ask them to not ignore it the next time
22:16 karolherbst: for me working on a common driver infra also means to play by certain rules, and if some thing that ignoring those is fine, they can just fork the project and do their own thing
22:17 karolherbst: and this is valid for everybody equally
22:17 imirkin_: so my biggest point with nir
22:17 imirkin_: is that it seems incredibly wasteful to have *two* optimizing compilers
22:18 imirkin_: that do the same things and potentially even fight each other
22:18 karolherbst: understandable
22:18 karolherbst: but with nir those things are optional
22:19 karolherbst: even though st/nir does indeed a few opts, but those seems to be okay to do
22:19 karolherbst: like constant folding and dce and so on
22:19 karolherbst: and we can always add a nir option "disable_nir_opts" for gallium
22:20 imirkin_: perhaps the answer is to just suck it up, and nuke the codegen opt pipeline
22:20 imirkin_: rewrite all the lowering as nir
22:20 imirkin_: and then hook it up at the RA phase
22:20 imirkin_: (this would be a *considerable* effort, btw)
22:20 karolherbst: yeah, but we don't have to do that
22:20 karolherbst: I am calling nir passes/opts just to make conversion easier
22:20 karolherbst: not to generate better code
22:21 karolherbst: for example you could end up with (0 * 8 + 4) as the texture reference, sure you could use indirects here and let codegein optimize it away, but we could also just let nir opt it to 4 and have an easier start
22:21 karolherbst: there are also things which don't support indirects
22:22 karolherbst: so we kind of have to opt those things away to be able to translate in the first place
22:23 karolherbst: I don't mind having codegen being a rich compiler, and having TGSI -> nvir and nir -> nvir
22:23 karolherbst: I see it as a fun competition and if some shaders are better one path, we can improve the other path
22:27 imirkin_: having an nir path greatly reduces the need to create a spir-v path
22:27 imirkin_: which likely means it won't get done
22:28 imirkin_: that said, it seems eminently unlikely that i will have serious time to invest into creating one
22:28 karolherbst: most likely
22:28 karolherbst: but I am also not saying no to a spir-v to nvir path in general
22:28 imirkin_: which means that i kinda have to suck it up and let people who *do* have time do the things they feel like
22:29 karolherbst: just because I currently work on a nir to nvir path, doesn't mean I won't work on a spir-v to nvir path as well later
22:30 imirkin_: i learned OpenGL by implementing stuff in nouveau
22:30 karolherbst: nothing should be set in stone here and if we indeed run into so many issues later on, we just might do a proper spir-v to nvir one and see if that goes better
22:30 imirkin_: (it was one of the reasons i started contributing to the GL driver -- learning all that stuff from the inside out)
22:31 karolherbst: well my reason was to have a fast enough open source driver for my hardware, I didn't really care about learning anything here
22:31 imirkin_: i wonder if SPIR-V is not conducive to such learning
22:31 imirkin_: since it's pretty opaque to start with
22:32 karolherbst: I wouldn't say so
22:32 karolherbst: spir-v just doesn't map as nicely to nvir than nir or tgsi do
22:32 imirkin_: do you have specific examples?
22:33 karolherbst: nir uses blocks which just map nicely to BBs, spir-v doesn't have this
22:33 karolherbst: which makes CFG in generally a lot easier to implement and deal with
22:33 karolherbst: *general
22:33 imirkin_: so... i think it's mildly busted
22:34 imirkin_: but codegen has a "auto-edge-thing"
22:34 imirkin_: i.e. you just make edges, and it assigns TREE / etc
22:34 karolherbst: well right, but with nir I was able to basically generate the same edges than we do with TGSI
22:34 karolherbst: I didn't see the same possibility with spir-v
22:35 karolherbst: and while working on it, I wasn't really able to get the same result as we would gotten with TGSI
22:35 karolherbst: well, of course we could get there somehow
22:35 karolherbst: but this would mean to do some anaysis work and be a lot smarter about stuff
22:36 karolherbst: imirkin_: mhh, what kind of "auto-edge-thing"?
22:36 karolherbst: it always seemed like that codegen really cared about the edges somehow
22:39 karolherbst: I mean, in the end I ended up with roughly 2,8k loc for nir to nvir. pmoreaus code is at around 4kloc? + that spir-v to nir thing is how big? 10kloc?
22:52 imirkin_: there was a thing in the graph thing
22:52 imirkin_: to do the edge type assignment
22:52 imirkin_: i forget what it was called. i'd have to read it.
22:59 imirkin_: the edges are basically a MST of the DAG
22:59 imirkin_: or rather, the "TREE" edges are the edges that make up the MST of the DAG
22:59 imirkin_: unfortunately it's all a little broken
22:59 imirkin_: and i've been too afraid to fix it :)
23:02 imirkin_: (because it influences code layout and RA)