00:03 imirkin: we should probably flip on PIPE_CAP_CS_DERIVED_SYSTEM_VALUES_SUPPORTED for nouveau
00:03 imirkin: iirc we have special regs for many of these, i just never took the time to plumb it all through
06:11 imirkin: skeggsb: i picked up one of these yesterday: https://hastebin.com/sigahahoti.makefile
06:11 imirkin: erm, first line was missing - https://hastebin.com/adagedomew.makefile
06:12 imirkin: gr. still cut off.
06:13 imirkin: for real this time: https://hastebin.com/ajexitiwux.makefile
06:13 imirkin: note that it's the DRM channel causing the write failure in the first place
06:13 imirkin: and then the fault after lockup.
06:13 imirkin: i believe this was with a rotated fb
06:13 imirkin: (i.e. fbcon was rotated)
06:14 imirkin: hence cw_putcs
11:53 PaulePanter: karolherbst: I just wanted to report about the crash problem several days ago.
11:53 PaulePanter: We switched the graphics card with an identical model, and the problems are now gone.
11:53 PaulePanter: So likely a hardware problem.
11:58 karolherbst: well, "model" is always difficult. Even the same model can be different
11:59 karolherbst: but yeah, can also be a hardware issue
13:34 cyberpear: karolherbst: I wanted to report some success with your latest runpm_fixes branch with my gp107. With no extra kernel parameters, the driver works fine, and I can suspend and resume fine.
13:34 cyberpear: karolherbst: I can successfully hibernate and resume once, but then further suspend or hibernate operations fail. (No user-visible crashes, the system just wakes up immediately, not really sleeping or hibernating.)
13:35 cyberpear: karolherbst: With nouveau.runpm=0, I can still suspend/resume after the first hibernate/resume operation, but after a second attempted hibernation, all attempts to suspend or hibernate fail as above
13:36 cyberpear: ^ this is on a ThinkPad P1 aka X1 Extreme for the curious
13:38 karolherbst: mhh, yeah, might be that suspend/resume kind of has it's own issues
13:38 karolherbst: but did you notice the same issues without my patches as well?
13:38 cyberpear: without your patches, nouveau doesn't work at all
13:39 cyberpear: but w/ the nvidia driver or the intel driver, suspend and hibernate work robustly
13:39 cyberpear: i.e., without your patches, but w/ nvidia blob, everything works suspend/hibernate/resume-wise
13:40 cyberpear: I haven't tested with your patches and the nvidia blob at the same time, though
13:41 cyberpear: (above I meant hibernate="suspend to disk" and suspend="suspend to RAM")
13:42 karolherbst: ahh
13:42 karolherbst: might be that there are some hibernation bugs
13:42 karolherbst: hibernation is kind of odd anyway
13:46 cyberpear: indeed, everything seems to work very smoothly except hibernate
13:48 cyberpear: (I use both suspend(-to-ram) and hibernate(-to-disk) throughout my week, depending on whether I'm going from meeting to meeting during the day; or taking a longer break, such as the weekend or overnight.)
13:48 karolherbst: yeah.. but usually with modern laptops it doesn't really make that much of a difference
13:48 karolherbst: or at least with good laptops
13:51 cyberpear: various definitions of "good" -- in this case, I chose the thin ThinkPad, which has awesome specs, but drains the battery pretty fast on suspend-to-ram (power-hungry DDR4, I guess; not LPDDR3)... Larger machines can last a week on suspend; this thin one can last a bit more than a day
13:54 karolherbst: DDR4 has the same operation voltage than LPDDR3
13:54 karolherbst: *as
13:54 karolherbst: so they should be more or less use the same power
13:55 karolherbst: and this is only for self refresh, which doesn't require all that much power.. usually
13:55 cyberpear: interesting
13:55 cyberpear: the reason was just a guess... in any case, my machine doesn't last as long as I'd like on suspend... hibernate is indefinite and takes no power at all
13:56 cyberpear: (I'm no expert on RAM-type power consumption)
14:01 karolherbst: yeah.. dunno, I think it depends on the laptop. I can suspend mine with 3% battery left and still expect it to not run out of power after half a day
14:01 karolherbst: but it's also some 15" machine with a big battery
18:39 cyberpear: would it be useful to provide dmesg output for a failed hibernate attempt?
18:52 karolherbst: cyberpear: dunno. I don't really know that much about hibernation
18:52 karolherbst: I kind of assume the error is somewhere how we resume from it though
18:52 karolherbst: maybe we cache some pointer we shouldn't or some other random mistake
18:52 karolherbst: really don't know
18:54 cyberpear: I see
19:20 pmoreau: karolherbst: Congrats on having an intern! Will they be working on Nouveau?
19:20 pmoreau: I just did a rebase of the series, and took the opportunity to remove the `check_extensions()` function, as we discussed.
19:23 karolherbst: pmoreau: dunno yet. Don't really want to force him into a direction
19:23 pmoreau: Okay
19:23 karolherbst: pmoreau: I hope you didn't overwrote my changes :p
19:24 pmoreau: I pulled first
19:24 karolherbst: I am very proud of my changes with adding the CAP for the .entry_point vs .pc situation :D
19:25 pmoreau: Given that your last change was two days ago apparently, and I pulled today, we should be safe! O:-)
19:26 karolherbst: yeah
19:26 pmoreau: I am going to look at your change with the cap, and reply on the MR. I agree that bigger changes should be made in a separate MR: this one has been around for so long already, and has quite a few changes, so there’s no point in making it even bigger.
19:27 pmoreau: Also, there are still no real users for it, so I am not too concerned in having something that isn’t perfect yet. :-)
19:34 karolherbst: what annoys me most is that most of how clover is today is because of "llvm" and using that as a reason sounds very wrong to me
19:38 pmoreau: It does
19:40 HdkR: All hail our lord and saviour llvm
19:40 karolherbst: pmoreau: anyway, next step is to get shader caching finished inside nouveau :)
19:40 karolherbst: like the real one
19:40 karolherbst: not TGSI or nir
19:40 pmoreau: That would be nice!
19:41 karolherbst: and this will also help us with the program binary stuff for CL
19:41 karolherbst: as we need a binary format
19:43 pmoreau: I’ll continue working on the OpenCL CTS, to help merge everything into a single branch, and hopefully get 1.0 and 1.1 covered, but I think I’ll try to pick a few small Nouveau tasks on the way.
19:43 karolherbst: :)
19:44 karolherbst: yeah.. I don't want to focus all that much on CL, but if something helps graphics and CL I am all for doing it. like the shader caching stuff :p
19:44 karolherbst: maybe we could even implement the GL binary stuff as well
19:44 pmoreau: ;-)
19:45 pmoreau: Any thoughts on getting OpenGL SPIR-V going on for Nouveau?
19:51 karolherbst: is there any driver enabling that yet?
19:51 karolherbst: I would assume it's more or less trivial
19:56 pmoreau: I haven’t really followed; Intel was quite close I think, but not sure if they made it or not.
19:58 karolherbst: yeah.. I kind of wait until it's ready for one driver and then implement the missing stuff
19:58 karolherbst: btw, I want like 5-10 of those jetson nanos :D
19:59 pmoreau: karolherbst: `const char *entry_point` does have its issues: it won’t work if you have overloaded or templated entry points (which isn’t allowed in OpenCL, but is in CUDA). Not sure what SYCL does in those cases.
19:59 pmoreau: Ah ah ah! I am no longer in the business, sorry. :-)
20:00 karolherbst: pmoreau: heh? in the spirv those are just entry points
20:00 karolherbst: with super mangled symbol names
20:00 pmoreau: They aren’t mangled at all.
20:00 karolherbst: but yeah...
20:00 karolherbst: no?
20:00 karolherbst: how else?
20:00 pmoreau: You use the function type
20:00 karolherbst: I mean, I don't care about what cuda does, but SYCL has to mangle the names
20:01 karolherbst: SYCL has to use CL features afterall
20:01 karolherbst: can't just use something which CL can't support
20:01 karolherbst: pmoreau: well, and how are function types encoded? name mangling :p
20:01 pmoreau: The SPIR-V linker assumes the names are mangled, but I have some patches to fix it.
20:01 karolherbst: heh
20:01 pmoreau: Using a OpTypeFunction?
20:01 karolherbst: no...
20:01 karolherbst: how would you invoke such a kernel?
20:01 karolherbst: you only have the CL API
20:02 pmoreau: Well, OpenCL does not allow overloading or templated functions, so problem sovled
20:02 pmoreau: s/functions/kernels
20:02 karolherbst: right, that's why SYCL has to mangle the names
20:02 karolherbst: it doens't really matter how as long as it's consistent
20:02 pmoreau: Right, okay