04:05 rhyskidd: more therm docs on the ML from nv!
07:12 pmoreau: \o/
10:12 Benau: http://kobato.stan.hk/nan_minimap.jpg
10:12 Benau: http://kobato.stan.hk/correct_minimap.jpg
10:12 Benau: nan onevwad in nouveau gt240
10:13 Benau: i wonder what can cause this...
10:22 karolherbst: Benau: compiler opts or some other screw up
10:22 Benau: do u want a trace file?
10:23 karolherbst: I only have a gp107, but I could check if it also happens to me
10:23 karolherbst: what is the driver/hw for the "correct" file?
10:25 Benau: amd and intel on mesa
10:25 Benau: radeonsi, hd4600
10:25 Benau: http://kobato.stan.hk/stk_minimap.trace.lzma
10:25 Benau: heres trace
10:29 Benau: btw if i only revert the bad commit pointed out yesterday i can have tbo working
10:29 Benau: in latest mesa git
11:59 karolherbst: imirkin: I've updated the pascal trello CTS status page
11:59 karolherbst: *card
13:52 imirkin: Benau: well replaying that trace caused a hang for me on kepler ... so ... well done :)
13:53 Benau: lol
13:53 Benau: sorry
13:53 imirkin: based on the black result there and the hang here, i'd say there's a resource missing
13:54 Benau: ok
13:54 imirkin: [226356.946335] nouveau 0000:02:00.0: fifo: read fault at 0018000000 engine 1b [CE2] client 18 [GR_CE] reason 02 [PTE] on channel 6 [007fada000 X[23317]]
13:54 imirkin: CE = copy engine
14:00 Benau: do u hang at around the same 82xxxx command as in the nan texture?
14:01 imirkin: dunno. last print i see is for a shader compiled in 826104
14:08 Benau: nan texture i saw was 821698 btw
14:19 imirkin: k. i can't really investigate now.
14:19 imirkin: realistically, not til the weekend
14:20 imirkin: Benau: fwiw that 821698 call works out correctly on my kepler.
14:21 Benau: ...so gt240 bugb(mostly?)
14:21 Benau: bug
14:21 karolherbst: imirkin: when you find some time, could you look over this series? https://patchwork.freedesktop.org/series/34898/
14:21 imirkin: Benau: check what GL_TEXTURE4 shows up as
14:21 imirkin: if the source texture is wrong, then it's not the draw's fault
14:22 Benau: all texture slots are the same across all drivers
14:22 Benau: only fb result differ
14:22 imirkin: ok, so for that draw, you checked that GL_TEXTURE4 contains the thing it should contain?
14:25 Benau: yes
14:26 imirkin: =/
14:26 imirkin: karolherbst: try to get hakzsam to review
14:26 imirkin: that's his code
14:27 hakzsam: ah yeah, missed that
14:30 karolherbst: imirkin: by the way, I will be able to work on that NIR stuff again for a while and currently I run it on top of the CTS to find more issues
14:31 imirkin: ok
14:31 karolherbst: hakzsam: yeah, right, I tried to get something meaningful out of the blob, but I kind of failed here. For me the changes make sense though
14:32 imirkin: personally i'd rather you have spent that effort on finishing up pmoreau's spir-v work. ooo well.
14:32 imirkin: did you add the 4-offset tg4 to nir?
14:32 karolherbst: well... I should work on NIR for OpenGL 4.6 and Vulkan support
14:32 karolherbst: not yet
14:32 karolherbst: it isn't exactly high on my priority list
14:33 imirkin: right. i'd rather you have worked on spir-v for opengl 4.6 and vulkan support :)
14:33 pmoreau: hakzsam: Don’t forget about jamme’s patches as well, about adding proper sched for exa? shaders :-)
14:33 karolherbst: imirkin: well, we have our reasons why we prefer to do it through NIR
14:34 pmoreau: I need to refresh my memory on that stuff and review them as well, as I did some reviewing for some of version of it.
14:34 imirkin: and i have mine for why i prefer to do it through SPIR-V
14:34 karolherbst: right
14:34 imirkin: (out of curiousity, we = ?)
14:34 pmoreau: If we do both, everyone’s happy? :thinking:
14:34 karolherbst: imirkin: RH
14:34 imirkin: didn't think the RH CEO much cared...
14:35 karolherbst: + somebody I can't mention
14:35 imirkin: nah, coz only one can be "the one"
14:35 pmoreau: True :-/
14:35 karolherbst: right
14:36 imirkin: anyways, perhaps i should take that as a sign
14:36 pmoreau: Anyway, /me is back to debugging his algorithm
14:36 karolherbst: and from the maintenance point of view it makes sense to go through NIR
14:36 karolherbst: at least in my analysis it is
14:36 karolherbst: *does
14:37 mupuf: yeepee, I got the answer for the fan issue!
14:37 pmoreau: s/jamme/jamm
14:37 karolherbst: vulkan alone will be time consuming enough already
14:37 karolherbst: mupuf: :)
14:37 karolherbst: mupuf: I already read it
14:37 pmoreau: mupuf: Indeed you did! Off to fix that, now! :-)
14:37 mupuf: well, I'm off to Lapland, but I'll definitely fix that next week!
14:37 karolherbst: :)
14:38 hakzsam: yes, I will try to review the sched code patches
14:38 pmoreau: That guy.... always on vacations it seems :-p
14:38 pmoreau: Thanks!
14:38 karolherbst: mupuf: I could give him a big thanks from you :p
14:38 mupuf: karolherbst: please do :)
14:38 karolherbst: :)
14:39 mupuf: well, I will answer on the mail, but yes
14:40 karolherbst: hakzsam: thanks
14:42 mupuf: oh well, that was a mouthful
14:42 mupuf: no wonder I got stuck on this
14:44 karolherbst: you mean this treat 0 as 1 or the other way around?
14:45 karolherbst: or that they use their fixed float format again?
14:45 karolherbst: or both :D
14:46 karolherbst: uhh wow "Default minimum fan level - *cannot* be overriden by VBIOS:"
14:46 karolherbst: how stupid
14:46 karolherbst: the default should be 0 of course
14:47 imirkin: pmoreau: how far is your spir-v implementation from upstreaming? (just the spirv -> nvir bit, not the CL stuff)
14:48 imirkin: is it something i could finish with a week's effort?
14:49 pmoreau: imirkin: One big unknown, is what you and others will think of the code. I think the biggest effort in getting the basics upstreamed, is cleaning up the code, especially the memory management.
14:49 imirkin: "memory management"?
14:49 imirkin: like management of GPU memory
14:50 imirkin: or management of memory backing various cpu-side objects?
14:50 pmoreau: More like keep track of variables, the equivalent of DataArray?
14:50 imirkin: gotcha
14:50 karolherbst: pmoreau: did you figure that texture thing out?
14:51 pmoreau: It’s something I have been willing to do for some time, but have prioritised SPIRV-Tools and more recently, the clover part as a prerequisite to the SPIR-V -> NVIR and useful for more people.
14:51 imirkin: i need to figure out whether i can invest the time to finish it all up and pre-empt this whole NIR thing, or if i need to cut my losses and look for other things.
14:51 pmoreau: karolherbst: Haven’t had a chance to look back at it, as I still need to get the new framework to accept those damn types & co.
14:52 karolherbst: imirkin: why is that so important?
14:53 imirkin: mmm ... well, i think the spir-v approach is definitely going to be easier to work with once it's in place
14:53 karolherbst: I seriously don't think so. I looked into both and working with NIR was easier for me personally
14:53 imirkin: it cuts down on a lot of middleman issues that happen with glsl -> ... -> ... -> ... -> ... -> ... -> nvir
14:54 karolherbst: yeah might be, but we also have to keep maintenance in mind
14:54 karolherbst: and if we work on vulkan
14:54 karolherbst: we also get our vulkan runtime on top of that
14:54 pmoreau: Is it going to reduce the number of middleman compared to NIR, when the input is GLSL rather than SPIR-V?
14:54 karolherbst: where we are basically on our own to begin with
14:55 karolherbst: I mean sure, with unlimited man power I would also probably go with spir-v to nvir directly
14:55 imirkin: by "work with" i don't mean "implement the first converter". i mean "adapt to various changes, make use of unique hw features, etc"
14:55 karolherbst: we can do that with nir as well
14:55 imirkin: pmoreau: glsl -> TGSI would stick around, i think.
14:56 pmoreau: Okay, and for that case we would keep the existing TGSI frontend.
14:56 imirkin: right. so it comes down to a matter of opinion.
14:57 karolherbst: well, we have to deal with less stuff from nir to nvir than from spir-v to nvir
14:57 imirkin: anyways, i don't have time to discuss this right now
14:57 imirkin: but if you want to put your time to *actual* good use, you'd fix all the resource management issues we have
14:57 karolherbst: to be fully open here: I just want to prevent a situation where somebody blocks the path he doesn't like, just because one was already merged
14:58 karolherbst: if that happens, we are gonna have a big problem
14:58 imirkin: only one thing can be the default.
14:58 karolherbst: so I don't see in what way it is important to "pre-empt this whole NIR thing"
14:59 pmoreau: imirkin: I’ll try to clean things up during the week, do some explanation about it, and you can have a look at the code and make up your mind on it.
14:59 imirkin: can rephrase it as "make it apparent that just using SPIR-V directly is a good idea"
14:59 karolherbst: well right, and the default one will be the one with the smaller amount of issues or whatever, but that's a technincal thing then
14:59 karolherbst: imirkin: right, I just don't want to run into silly community issues here for petty reasons
14:59 imirkin: i'm not going to block (for non-technical issues), the merging of anything_to_nvir
15:00 karolherbst: okay
15:00 imirkin: s/issues/reasons/
15:01 imirkin: that said, you're working on this stuff full-time, and i sure would *prefer* it if your work were directed in a way that i thought was useful
15:01 karolherbst: I don't expect that you would, I was just a bit confused about the way you phrased it
15:01 karolherbst: imirkin: all I can say is, that we don't have just nouveau in mind when discussing such things
15:01 imirkin: also i have no real interest in working with nir in nouveau, which means that if it does become the cool new thing, then i'm pretty much out.
15:02 karolherbst: right, but this is your personal decision
15:02 imirkin: just like what RH works on is RH's "personal" decision
15:03 karolherbst: mhh okay, let me rephrase that: I got the feeling, that it isn't just for technical reasons you made this decision
15:03 imirkin: just because you have various clever designs you can't talk about doesn't mean everyone's going to be on-board with them. doing this stuff behind closed doors is a recipe for disaster.
15:03 karolherbst: I might be wrong about this, but this is how I feel about it
15:03 karolherbst: imirkin: I know, and the reasons we can't be more open about it is petty and silly
15:03 karolherbst: and we are working on changing it
15:04 imirkin: doesn't matter what the reasons are.
15:04 karolherbst: right
15:05 imirkin: it's also unfortunate that a project as non-commercial as nouveau would all of a sudden bow to commercial interests.
15:05 imirkin: so i'm going to try to avoid that as long as practical
15:06 karolherbst: right and I agree here
15:06 imirkin: but ultimately i can't compete with the labor that a commercial entity can put forward
15:06 imirkin: esp since this a "free time" thing for me
15:08 imirkin: that was the "maybe i should cut my losses" bit of the thought process btw
15:08 karolherbst: well, I didn't base my preference on NIR on any commercial interest here
15:09 imirkin: ok.
15:13 karolherbst: In the end you can ask me any questions regarding anything, just keep in mind, that I need to be careful with my answers as long as it is in "public space". And I would like to give you more insight if that would make you feel better about the entire "commercial interests" situation.
15:17 orbea:thinks when you can't discuss a project's details in public everyone loses
15:19 karolherbst: orbea: I agree
15:19 karolherbst: I don't want to make any excuses for that
15:21 karolherbst: and it isn't the way we want it to be either. We work on fixing this.
15:22 karolherbst: anyway, gtg (I should probably setup my bouncer for freenode as well)
15:25 orbea: i obviously don't have much say here, but really doesn't seem so hard to solve... Just refuse such silly terms and proceed to ignore them
16:03 karolherbst: orbea: if that would be as easy, yes. But the core issues involves some issues on a social level, which is hard to "just solve"
16:05 orbea: i suppose there is too much missing information to understand how or why social issues have antyhing to do with publically discussing technical details...
16:06 imirkin_: definitely unfortunate that such issues would come up in a project with as few people involved as nouveau.
16:19 karolherbst: imirkin_: yes
16:48 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 whta I found in dmesg log
16:48 dziadu: https://pastebin.com/1kAjZGkv
16:48 dziadu: looks like nouveau is crashing
16:49 dziadu: at the moment I switched to nvidia since the crash happens average once per day
16:49 dziadu: I am using 4.15.1
16:49 dziadu: linux kernel, compiled by myself on gentoo
17:58 karolherbst: imirkin_: uhh, right, that would be an idea. I could try to work on those concurrency issues after I am done with the bug fixing on laptops.