13:21vries: Hi. On wikipedia, in the mesa3d article I see a picture 'Mesa compilation stack 2016+', ( https://en.wikipedia.org/wiki/Mesa_(computer_graphics)#/media/File:Mesa_layers_of_crap_2016.svg ) and an arrow from nir to tgsi. Does anybody know where I can find this translation in the mesa sources?
13:29FLHerne: vries: That diagram is wrong :P
13:29karolherbst: tgsi to nir exists
13:29vries: karolherbst: right, that one I found
13:29karolherbst: this diagram has many other issues as well
13:30karolherbst: there is glsl Ir -> tgsi as well
13:30vries: so, is there a correct, or more up-to-date diagram somethere ?
13:31FLHerne: Igalia blog had one
13:31karolherbst: revert that wikipedia change :p
13:32karolherbst: I am too tired of pointless discussion so I don't change wikipedia stuff
13:32FLHerne: nir->tgsi did sort of exist as a tech demo, didn't it?
13:32FLHerne: Maybe not in-tree
13:32karolherbst: does it matter?
13:32karolherbst: it isn't part of mesa
13:32karolherbst: end of story
13:33FLHerne: Well, it could be relevant to the original question, depending on why vries was looking for it :P
13:35vries: I'm just trying to find the various paths into nouveau, f.i. from GLSL IR to nouveau. According to the diagram, that's GLSL IR -> NIR -> TGSI -> nouveau.
13:35vries: But if nir to tgsi doesn't exist, what is the path then?
13:35karolherbst: the diagram is wrong on so many level
13:35karolherbst: I want to forget it
13:35karolherbst: and please do so as well
13:36karolherbst: there is just the one path: glsl ir -> tgsi -> nvir
13:36karolherbst: and in the near future glsl ir -> nir -> nvir as well
13:36karolherbst: well there is always spir-v to nir as well
13:37vries: right, I've seen your submission
13:58imirkin: FLHerne: there was a nir -> tgsi converter, yes. it was very limited.
13:58imirkin: vries: nouveau is GLSL IR -> TGSI -> nv50_ir
13:59imirkin: any diagram that implies otherwise is wrong.
13:59karolherbst: imirkin: did you actually looked at it?
14:03FLHerne: Did I get this about right? http://www.flherne.uk/files/mesa_irs.png
14:03FLHerne: Probably missing some backend things
14:03karolherbst: depends on what .... means
14:03imirkin: FLHerne: no, that one is very very old
14:03karolherbst: and there is tgsi -> nir as well
14:03imirkin: or ... confused
14:03FLHerne: imirkin: it isn't, I drew it just now
14:04FLHerne: So the second one ;-)
14:04imirkin: glsl -> mesa ir i think got nixed a long time ago
14:04imirkin: (once upon a time, mesa ir was the ir to end all ir's)
14:04FLHerne: karolherbst: Isn't that only used for internal generated shaders now?
14:04karolherbst: FLHerne: tgsi -> nir?
14:04imirkin: while there is a ttn, it's also very limited
14:04imirkin: (ttn = tgsi to nir)
14:05karolherbst: FLHerne: well yeah, but yeah
14:05karolherbst: it is still there
14:05FLHerne: I thought Intel still do linking etc. in Mesa IR, before tarceri's patches
14:05FLHerne: Perhaps I misunderstood
14:05imirkin: mainly used for freedreno/vc4 before there was a direct nir passthrough
14:05imirkin: and also for various u_blitter shaders on gallium drivers that prefer nir
14:05FLHerne: And does that mean there's a straight GLSL->TGSI pass now?
14:06imirkin: mesa ir is the ir that's used to represent things like ARB_vp/ARB_fp now
14:06imirkin: and that's the extent of it
14:06karolherbst: does anything uses that?
14:06imirkin: ARB_vp/ARB_fp ;)
14:06imirkin: oh, you mean those exts? yeah, a ton ton ton ton of old games
14:06karolherbst: well right, but I mean extensions without application using those are pointless :p
14:06karolherbst: I remember
14:06imirkin: before glsl was a thing
14:07imirkin: or was a viable thing.
14:07imirkin: the GLSL stuff is complicated, since it kinda has 2 IRs too
14:07imirkin: it has the AST and then the GLSL IR
14:07imirkin: but that is not the "mesa ir"
14:09FLHerne: Ok, I think that's where I keep getting confused
14:09karolherbst: it is all confusing
14:10FLHerne: So does the new glsl->nir pass go from the AST or the not-AST GLSL IR?
14:10FLHerne: Or the existing to-TGSI pass, for that matter :P
14:10karolherbst: fun fact
14:10karolherbst: there are two of those
14:10FLHerne: Newish, then...
14:10karolherbst: or kind of two
14:11karolherbst: there is st_glsl_to_nir and this non gallium glsl to nir thing
14:11karolherbst: allthough I think they use a lot of common code
14:11karolherbst: and st_glsl_to_nir just converts all the gallium stuff back to mesa/nir stuff
14:11FLHerne: Ok.../that/ I hadn't realised
14:12karolherbst: well you don't want to convert from ASI to NIR directly I think
14:12karolherbst: so you have the glsl ir
14:17karolherbst: imirkin: but how does the nir driver consume mesa ir? is there a mesa ir to glsl ir thing? or mesa ir to nir or something?
14:18FLHerne: Closer? http://www.flherne.uk/files/mesa_irs_2.png
14:19FLHerne: (for my own understanding more than anything :P)
14:20karolherbst: FLHerne: arb_vp and arb_fp => mesa ir
14:20karolherbst: and I think there are also internal shaders for non TGSI drivers?
14:21karolherbst: no idea what they do or how they work out
14:21FLHerne: Oh, right, being not-GLSL
14:22FLHerne: I thought all of those just used the TGSI ones and tgsi->nir, except presumably i965, but that doesn't really fit on the diagram
14:23karolherbst: :) right
14:23karolherbst: I doubt i965 uses any TGSI stuff
14:23karolherbst: I am sure it doesn't
14:24karolherbst: and then we also have some more special drivers
14:24karolherbst: like that vmware thing
14:24karolherbst: but I guess it is jusing that TGSI -> whtvr path
14:33vries: flherne: thanks for the diagram.
14:36ylwghst: How shoudl I set clock speed to 0f during boot?
14:36ylwghst: should I use nouveau.pstate=4 ?
14:36ylwghst: or 3?
14:37karolherbst: ylwghst: https://nouveau.freedesktop.org/wiki/KernelModuleParameters/
14:37karolherbst: nouveau.config=NvClkMode=15 or something
14:38ylwghst: cat /sys/kernel/debug/dri/0/pstate
14:38karolherbst: the hell
14:38karolherbst: what GPU is that?
14:38karolherbst: that "memory 0 MHz" confuses me here the most
14:38ylwghst: GeForce 320M MPC89
14:43ylwghst: I wonder what will happen if I set DC
14:43imirkin_: there is no memory
14:43imirkin_: it's an IGP
14:43imirkin_: it uses stolen sysram
14:44ylwghst: I see
14:44ylwghst: You're right
14:45imirkin_: not 100% sure if core clock reclocking works on there or not
14:45imirkin_: RSpliet made it work for MCP77/79, but the 89 is very rare
14:46ylwghst: How should I test it?
14:46karolherbst: imirkin_: for weird reasons, Mac OS X reported 256MB dedicated VRAM though
14:46karolherbst: + stolen sysram
14:48karolherbst: but maybe that just means dedicated from sys ram and the other part is just added dynamically or something
14:49karolherbst: ylwghst: mind uploading your vbios.rom somewhere?
14:49karolherbst: I would like to take a look there
14:50ylwghst: How could I extract it?
14:56RSpliet: karolherbst: I don't think there's anything interesting to see in the VBIOS. This is the same behaviour we see on MCP77/79. Nouveau just doesn't know the DRAM clock speed - and is probably interpreting another clock as the DRAM clock incorrectly
14:57ylwghst: it should be here /sys/devices/pci0000:00/0000:00:17.0/0000:02:00.0/rom
14:57RSpliet: I suspect that it should work either out of the box or with minimal code changes, but only a blob trace could confirm that. Perhaps the VBIOS could show whether the same PLLs (registers) are used
14:57RSpliet: ylwghst: /sys/kernel/debug/dri/0/vbios.rom I think is the ROM you're looking for
15:02ylwghst: karolherbst: dump here https://nofile.io/f/W6xTqbD9ocn/nvidia-geforce-320m-mcp89-vbios.rom
15:02RSpliet: ylwghst: how does your GPU identify itself in dmesg?
15:03ylwghst: RSpliet: https://gist.github.com/anonymous/e41ba201a1f45977e8669a90fa947f90
15:03RSpliet: ah, AF
15:03RSpliet: RIP: 0010:gt215_clk_info.isra.2+0x49/0xc0 [nouveau]
15:04RSpliet: looks like it's using the wrong PLL code
15:06RSpliet: Which explains why it's interpreting... some clock as the memory clock
15:07RSpliet: ylwghst: It'd be very very useful if you could obtain an mmiotrace of the official driver booting the GPU and setting the clocks once or twice.
15:07ylwghst: RSpliet: i haven't one dump already
15:07ylwghst: oh i see
15:08RSpliet: ylwghst: mmiotrace intercepts comm between the official driver and the GPU and logs it. Those logs reveal a lot about how clocks are set.
15:08RSpliet: There's manuals around on how to do this... unfortunately I don't have much time to help you obtain this at the moment, sorry
15:08ylwghst: ok ill do new one while i change the clock
15:09RSpliet: tlwghst: where did you send that mmiotrace?
15:09RSpliet: Was it captured for the entirety of starting X.org?
15:09ylwghst: i'm not sure
15:09ylwghst: if entire start is captured
15:09ylwghst: but i think so
15:09RSpliet: Ok... where did you send it?
15:10ylwghst: i forgot
15:10ylwghst: forgot that email adress too
15:10RSpliet: was it our traces mail address?
15:10ylwghst: karolherbst: gave me
15:10ylwghst: that one
15:11RSpliet: Ah got it. Let me take a very quick peek
15:12RSpliet: ...oh, my PC doesn't understand the concept of "very quick"
15:12ylwghst: btw i could i blacklist nvidia-340 and run nouveau while keep the legacy installed? i was trying that by blacklisting nvidia nvidiafb and nvidia-uvm but i wasn't able to start Xorg with nouveau
15:13imirkin_: different libglx/libGL libraries too
15:13ylwghst: i see
15:14imirkin_: it's manageable under gentoo
15:14imirkin_: presumably could be done in debian-like too with update-alternatives
15:14imirkin_: dunno if rpm/yum have something like that too
15:14imirkin_: but even if the pkg manager has it, the packages have to be set up for it :)
15:17RSpliet: ylwghst: many many events were lost in your log. You might want to capture another one from boot with the log size vastly increased
15:18RSpliet: Or... that's how I usually solve this problem. /sys/kernel/debug/trace/buffer_size_kb is writeable, I can't recall whether I set it to 10 or 100MiB, but something large yet fits in DRAM ;-)
18:17karolherbst: pmoreau: is there a way to compile OpenCL kernels to vulkan SPIR-V?
18:17karolherbst: even if it is pretty crappy?
18:18karolherbst: just the google thing or is there something else? https://github.com/google/clspv
18:18karolherbst: allthough that is alos vulkan compute
18:47pmoreau: karolherbst: Besides clspv, I’m not aware of anything else.
18:48pmoreau: Why the “allthough that is alos vulkan compute”?
18:48pmoreau: Were you expecting it to generate vertex shaders from OpenCL kernels? :-p
19:20karolherbst: pmoreau: kind of :p
19:20karolherbst: pmoreau: one thing though, what of your patches are required to get the runtime bits working for OpenCL in Nouveau?
19:21karolherbst: I am sure we need that spir-v plumbing code somehow
19:21karolherbst: but what I am more interested in, what do we need to get the global memory stuff worked out, or like memory stuff in general
19:27pmoreau: karolherbst: I’m not sure I understand which runtime bits you are referring to: the clover bits to accept/generate SPIR-V binaries? the plumbing for Nouveau to work with clover?
19:29pmoreau: And same with “what do we need to get the global memory stuff worked out, or like memory stuff in general“: are you talking about how clover asks Nouveau to allocate memory? or how the SPIR-V -> NVIR translator works regarding memory accesses?
19:30karolherbst: I mean I am already aware of what have to be done regarding accepting spir-v in clover in general
19:30karolherbst: what I am not aware of are the memory related bits in the clover runtime
19:30imirkin_: can't have compute shaders without working memory
19:30karolherbst: well right
19:30karolherbst: but memory stuff is a bit different between compute shaders and opencl
19:31karolherbst: and I am interested in what additional stuff we need for handling this
19:31karolherbst: imirkin_: somebody had the idea of faking global memory access by using one big ssbo starting at 0x0 and just use this
19:32imirkin_: right, that's global memory vs buffer memory
19:32imirkin_: if you look, buffer memory accesses get lowered to global memory accesses
19:32karolherbst: I know
19:32imirkin_: no need to fake anything
19:33karolherbst: well right, it was more a discussion from the nir point of view
19:33karolherbst: adding new intrinsics vs reusing what we have
19:33imirkin_: just introduce new intrinsics
19:33imirkin_: no need to hack anythign
19:33imirkin_: these are fundamentally different things
19:33imirkin_: ssbo accesses need length checks, etc
19:34imirkin_: ssbo's can also be sized
19:34karolherbst: well yeah, to properly answer that question, I wanted to know what runtime bits are missing to support OpenCL through clover in nouveau
19:34karolherbst: but if everything is there already, then there is no problem and I would also just go with adding new intrinsics
19:36pmoreau: clover calls some function available through the pipe to allocate the buffers and resources. Not sure which ones, but it’s a standard function; I didn’t need to touch any of that.
19:38karolherbst: pmoreau: okay, so all the non nouveau changes you made was to support spir-v?
19:39karolherbst: well, more like accepting spir-v for clover
19:39imirkin_: the pipe functions are a bit messed up
19:39imirkin_: there's an old set_global_resources() or something call
19:39imirkin_: which is sorta-bindless.
19:39karolherbst: imirkin_: well right, but this isn't really a problem. We are just talking about getting the absolute minimum stuff working
19:40imirkin_: well, it's how buffers are done
19:40karolherbst: there is one additional thing though
19:40imirkin_: and no buffers means no compute.
19:40karolherbst: we need a way to let application access that memory the GPU wrote to
19:40pmoreau: karolherbst: Yep, the only changes I made (besides some convert/64 bit handling/that kind of stuff) were: letting clover accept SPIR-V binaries (or generate them), and translating SPIR-V to NVIR.
19:41pmoreau: (And changing some CAP to advertise compute on NV50)
19:41karolherbst: and we need to use this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bffc33ec539699f045a9254144de3d4eace05f07
19:42pmoreau: No need for HMM now
19:42glisse_: yeah HMM is orthogonal to all this
19:42karolherbst: pmoreau: this isn't up for debate ;)
19:42pmoreau: I don’t think OpenCL let’s you allocate both on the CPU and GPU side at the same time, like a cudaMallocManaged
19:43glisse_: opencl 2.0 allow you to malloc
19:43glisse_: and use malloc memory on gpu
19:43glisse_: fine granularity they call it iirc
19:43pmoreau: Oh, ok, didn’t know that.
19:43imirkin_: first we need nouveau to support placing a bo at a particular VM address :)
19:43imirkin_: still waiting for that before i look at vulkan
19:43karolherbst: glisse_: well we need a way to have applications and the GPU accessing the same memory synchronised but at the same time, right?
19:44karolherbst: well through HMM
19:44karolherbst: but from an abstract point of view
19:44glisse_: but that's can be done last after getting opencl running for existing 1.2 style memory
19:44glisse_: ie reguler gem object
19:44karolherbst: imirkin_: I heard this will come soonish
19:44glisse_: and regular copy through OpenCL functions
19:44karolherbst: yeah okay
19:45karolherbst: clover only supports up to 1.2, right?
19:45karolherbst: so we would need to add some 2.0 stuff there
19:45pmoreau: 1.2 support is not complete
19:45karolherbst: we will go for an incomplete 2.0 then
19:46karolherbst: but okay
19:46glisse_: no need for 2.0 addition, iirc the diff for 2.0 is mostly in the wording and couple new stuff in the OpenCL standard library
19:46pmoreau: Call it 6.6 and shipt it! :-p
19:46karolherbst: so at least for global memory access everything should be there
19:46karolherbst: even if in a kind of crappy way
19:46karolherbst: glisse_: right
19:46pmoreau: glisse_: Does that malloc thing count as wording? :-p Isn’t there device side enqueueing as well?
19:47glisse_: pmoreau: to me it does :)
19:47glisse_: it is just saying hey now you can pass your malloc ptr :)
19:47pmoreau: Good for you then :-D
19:47pmoreau: Seen like that
19:48pmoreau: Right, so there is dynamic parallelism in it
19:48karolherbst: which we ignore for now
19:48glisse_: yeah i dont care about dynamic //
19:49pmoreau: Okay, so it will be an OpenCL 2.0 à la carte
19:49glisse_: it is always better than the formule :)
19:50pmoreau: I can give you a soupçon of OpenCL 2.1 if you want to, with clCreateProgramWithIL. :-)
19:50karolherbst: so we have an incomplte 2.1 then
19:51pmoreau: Heck, if we support SPIR-V 1.2 you can even make that incomplete 2.2!
19:51glisse_: i would like a bit of a croissant with it
19:51karolherbst: pmoreau: but yeah, having that is super usefull
19:51karolherbst: pmoreau: !
19:53karolherbst: glisse_: I am actually surprised that HMM actually made it into the kernel already... somehow I totally missed that
19:54glisse_: it is a covert op
19:54pmoreau: Same, I thought it was on to its 30th version :-D
19:54glisse_: i am in sthealth mode
19:54glisse_: oh it was merge in its 25th revision iirc
19:55glisse_: i think i hold a record with that
19:55pmoreau: glisse_: Congrats on the merge!
19:55karolherbst: glisse_: sounds like the normal way of doing things these days ;)
20:04pmoreau: karolherbst: Did you see tomeu’s patches for getting OpenCL kernels accepted by NIR? I was thinking you could be interested by those.
20:05karolherbst: pmoreau: mhh somehow I missed those
20:06pmoreau: I shared those on IRC about a week ago
20:06pmoreau: karolherbst: https://gitlab.collabora.com/tomeu/mesa/commit/b460949cb89579b363cf28ed83e466ac9cf1e052
20:07karolherbst: mhh, nice
20:07pmoreau: And he has updated LLVM-SPIRV to run on top of HEAD, as an “out-of-tree?”, similar to clspv: https://gitlab.collabora.com/tomeu/llvm-spirv
20:07karolherbst: but I think I would ended up doing the same at some point, just pushing spir-v through the current spirv to nir pass and see what happens
20:08pmoreau: Well, now you don’t even need to ;-)
20:08pmoreau: You know it will (mostly) work
20:08karolherbst: sounds good enough to me
20:09karolherbst: I just know I won't find much time the next to weeks for anything besides cleaning up patches and preparing some talks :p
20:11pmoreau: Talks, are you talking somewhere? :-D
20:12glisse_: fosdem is around the corner no ?
20:14pmoreau: Yes. And I’m presenting along Karol and Martin. :-)
20:17karolherbst: devconfcz which is a week earlier
20:23aphirst: Regarding this bug https://bugs.freedesktop.org/show_bug.cgi?id=75985#c27 (HDMI/DP audio doesnt work on bootup, needs some pci magic); it seems Maik Freudenberg wrote a module which properly toggles the functionality
20:23aphirst: But I wanted to work out whether this would get upstreamed at any point, without causing unnecessary traffic on the tracker
20:32pmoreau: karolherbst: Dunno if you saw my review for patch “nvir: move common converter code in base class”. Nothing major, but at least some easy things to fix.
20:34karolherbst: pmoreau: mh weird
20:34karolherbst: pmoreau: on the v3? or v2?
20:34pmoreau: On the v2, but you did not change anything in the v3
20:34pmoreau: (for that particular patch)
20:34karolherbst: yeah... I forgot
20:35pmoreau: No worries, just wanted to check. :-)
20:38pmoreau: aphirst: No clue, sorry. Maybe karolherbst knows?
20:38karolherbst: uhm well, the idea sounds reasonable
20:39karolherbst: maybe needs a bit cleaning up
20:39karolherbst: but generally it looks okayish
20:44NanoSector: hey, does nouveau work with the 10xx series, and in particular for laptops?
20:45karolherbst: NanoSector: kind of and kind of not
20:45Lyude: What does DRM_IOCTL_NOUVEAU_GEM_PUSHBUF do? I'm assuming it submits a stream of commands to the GPU's pushbuffer?
20:45NanoSector: karolherbst, what's the catch
20:45karolherbst: NanoSector: firmware, secure boot
20:45NanoSector: nvidia still hasn't published proper firmware?
20:45pmoreau: For GP108, you want 4.15, but otherwise, should be okayish, with no reclocking.
20:45karolherbst: nonono laptop firmware
20:45imirkin_: Lyude: good guess :)
20:46karolherbst: crappy suspend stuff
20:46karolherbst: better use runpm=0
20:46karolherbst: lots of problems
20:46karolherbst: and it will get worse
20:46Lyude: is this a problem with their firmware now?
20:46karolherbst: who knows
20:47karolherbst: Lyude: they change stuff, things don't work anymore. Linux bug or nouveau bug or firmware bug or whatever
20:47karolherbst: in the end it doesn't matter
20:47karolherbst: we need to fix it
20:47karolherbst: but then the question is: who fixes it?
20:47Lyude: imirkin_: hm; so that's all there is too it?
20:47Lyude: *to it
20:48NanoSector: karolherbst, sounds like a pain to work with
20:48Lyude: asking because i'm trying to figure out the exact system calls causing us to unmap the PTE that causes kepler's gr to crash
20:48Lyude: (thank you so much strace -k)
20:49karolherbst: NanoSector: and it toally is
20:49NanoSector: by the way, recent kernels are working pretty perfectly with my gtx 950M including manual reclocking, so great job there :)
20:49imirkin_: Lyude: yes and no... are you generally familiar with ... how this stuff works?
20:49imirkin_: i'm guessing now
20:50pmoreau: Lyude: Are those the GK106/GK107 issues with the Nouveau firmware?
20:50Lyude: i'm familiar with most of it other then the actual uapi details
20:50imirkin_: do you understand how buffers and ttm interact with all of this?
20:51Lyude: i'm pretty sure, the PTE is a GPU address mapped to CPU through the gart, the fault comes from us releasing it too early and then trying to have the GPU perform an operation that references said unmapped GPU VMA
20:51imirkin_: releasing what?
20:51Lyude: releasing the mapped memory handle that's referred to in the PTE that we get
20:51imirkin_: [oh good, i'm going to do this by asking you pointed questions that help you understand this yourself instead of me having to explain it]
20:52imirkin_: and what keeps a handle on said handle
20:53Lyude: userspace i'd assume
20:57imirkin_: so what would the protocol be for deleting a buffer?
20:58imirkin_: and let's say you have allocated a ton of textures, but only have one of them being used by the shader. do all of them really need to be mapped in gpu vm?
20:58imirkin_: by 'protocol' i meant 'procedure'
20:58imirkin_: if you just call GEM_CLOSE, that will kill the buffer. but what if a draw is still using it?
20:59imirkin_: (or worse, another process you shared the buffer with... gem's are not refcounted, sadly)
21:00Lyude: then it would crash with a fault like this... i figured out that part at least;
21:00Lyude: something doesn't seem right here
21:01imirkin_: ok, well if that were the case, everything would just always be broken
21:01Lyude: i say as i see the source of my confusion, and now things look right again, gah
21:01imirkin_: i'm not asking you about this specific bug
21:01imirkin_: i'm asking more about the general case
21:01imirkin_: in the hopes of helping you understand how it all fits together
21:05Lyude: imirkin_: I actually think I'm not sure I understand this last part that you're talking about; my best guess at the general case would be that (judging off of nouveau's code in vmm.c) that we ref'd the appropriate buffers (not gem ref, the reffing that nouveau seems to use internally for mapped memory handles
21:08pmoreau: Argh, yeah, 4.15 isn’t working wonders on my NVAC card. :-/
21:08pmoreau: Time to fire up my git bisect skills
21:22pmoreau: skeggsb: Latest master from Linus makes the display engine quite unhappy (something wrong with BAR as well) on an MCP79 (+G96): https://hastebin.com/ijasaquwiv.vbs; 4.14.13 works fine. Does that give you some idea of what is going wrong? Otherwise I’ll proceed with a bisect.
21:28Lyude: imirkin_: wait, uh. drm_gem_object_get() and drm_gem_object_put()
21:31skeggsb: pmoreau: what's reg 0x100e10 say on that board?
21:32imirkin_: Lyude: i'm probably being too subtle. unfortunately i don't really have time to explain
21:32Lyude: imirkin_: no worries
21:33imirkin_: ideally you'd get skeggsb to explain it all, since he understands it all much better than i do to begin with
21:33pmoreau: skeggsb: 00100e10: 000af000
21:33Lyude: he is also te one who wrote most of this code as well it seems
21:33imirkin_: coincidence, i'm sure :p
21:33pmoreau: (with Nouveau loaded, on 4.14)
21:36skeggsb: pmoreau: https://paste.pound-python.org/show/pU1MD2rzYv1otku3Og3I/
21:37skeggsb: that would be my first guess
21:38pmoreau: Gonna try that right now
21:44pmoreau: skeggsb: Definitely some progress! I no longer have all those errors, but I am left with a segfault in nouveau_dri.so when starting sddm.
21:44pmoreau: (logs incoming)
21:50pmoreau: skeggsb: Well, there isn’t much in it besides the segfault, but still: https://hastebin.com/xoferocifu.go
21:51pmoreau: At least it confirms that your patch does help quite a bit. :-) Feel free to add a Tb on it
22:00Lyude: skeggsb: since NOUVEAU_GEM_PUSHBUF is used for submitting new jobs, am I right in assuming that nouveau is supposed to go through all of the buffers referenced by that job and ref them up until the job finishes?
22:04imirkin_: Lyude: yes.
22:05imirkin_: it sticks a fence to the end
22:05imirkin_: when the fence completes, the buffers are unreferenced
22:05imirkin_: which means that ttm is free to move them out of vram
22:05imirkin_: or whereever they live
22:05Lyude: makes sense
23:33pmoreau: skeggsb: Still in the process of bisecting, but I encountered a new issue (while bisecting): BUG_WARN in nv50_vmm_pgt_sgl, followed by ZETA errors: https://phabricator.pmoreau.org/P113
23:33pmoreau: (I am still applying your patch for '|' -> '+'.)
23:36pmoreau: Not sure whether it is related to ZETA or not, but even on “good” kernels (in the bisect way), I am seeing some white flickering when switching between sddm and a TTY, as if the display was completely white just before sddm is show, and some of those white parts are visible for a few seconds before being covered by sddm.
23:39pmoreau: And I am not seeing this behaviour with 4.14.13.