01:35 rhyskidd: coderobe: there's a patchset series karolherbst wrote, is undergoing testing and on the mailing list
11:19 rhyskidd: karolherbst: https://github.com/karolherbst/nouveau/commits/secboot_fixes
11:19 rhyskidd: works for me on gp107
11:19 karolherbst: cool
11:19 rhyskidd: even d3cold and restore
11:19 rhyskidd: i will keep running this kernel for a while in case it catches anything, but the immediate improvement is stark
11:20 rhyskidd: (i did backport the patches to a mainline 5.0 kernel, works there too)
11:20 karolherbst: rhyskidd: tired running glxinfo as well?
11:20 rhyskidd: yes
11:20 karolherbst: :)
11:20 karolherbst: what laptop is it?
11:22 rhyskidd: https://paste.fedoraproject.org/paste/GzYqtna7uU2aA-L7q-2o7Q
11:22 rhyskidd: xps9560
11:22 karolherbst: :/
11:22 karolherbst: same as I have
11:23 rhyskidd: thanks for these patches.
11:23 rhyskidd: i can see still establishing if this should be fixed in the pci core, but the end experience is so much better already!
11:23 karolherbst: oh well, thanks for testing though :)
11:23 karolherbst: yeah... I was talking with bjorn on the mailing list
11:24 rhyskidd: oh, and the bios that i'm running is the latest one LVFS has available (and i believe is also the latest from dell)
11:24 rhyskidd: if that matters
11:24 rhyskidd: i get one acpi error in dmesg
11:24 karolherbst: I don't think it matters though
11:24 rhyskidd: but that's been there forever
11:24 karolherbst: this API mismatch thing?
11:24 rhyskidd: not new with these patches
11:27 karolherbst: the API stuff is something silly everybody is doing wrong
11:27 rhyskidd: this acpi error: https://paste.fedoraproject.org/paste/1~Qrh0kao5FlhkrjUoEoxQ
11:27 karolherbst: so it doesn't matter
11:27 karolherbst: ohh
11:27 karolherbst: interesting
11:27 karolherbst: I don't get that one
11:28 rhyskidd: i do get a separate acpi warning: https://paste.fedoraproject.org/paste/EncqbL427-EubkXlu-wHEw
11:30 rhyskidd: anyway, nouveau runpm works :)
11:35 karolherbst: pmoreau: there is another issue with your clover nir patches. It bails on unknown spirv extensions inside clover although we really don't care about any of those
11:36 karolherbst: or... we need a better way of handling them
11:36 karolherbst: spirv_to_nir will already fail if there is something unknown
11:36 karolherbst: or unhandled
11:37 karolherbst: it's the if (device_extensions.find(extension) stuff inside src/gallium/state_trackers/clover/spirv/invocation.cpp
12:45 karolherbst: pmoreau: anyway, I pushed the branch with a small fix (int64 lowering)
13:54 pmoreau: karolherbst: Okay, thanks.
13:54 pmoreau: Are there SPIR-V extensions that don’t need a CL extension to be activated as well?
13:54 pmoreau: For which extension(s) did you get an error?
14:23 karolherbst: pmoreau: that unwrap/wrap thing
14:23 karolherbst: SPV_KHR_no_integer_wrap_decoration
14:23 karolherbst: no idea if we want to whitelist them all though
14:24 karolherbst: but not supporting SPV_KHR_no_integer_wrap_decoration doesn't cause any issues
14:24 karolherbst: we just miss out compiler optimizations
14:24 karolherbst: anyway, I would spirv_to_nir handle all those spirv extensions
15:50 karolherbst: pmoreau: ohh btw, do you know if OpenCL will also move into this validation layer direction?
15:50 karolherbst: aka making CL vaidation optional at runtime?
15:51 karolherbst: I am kind of thinking how a "clover 2.0" could look like and wheather we want to move clover into this direction or just write a completly new state tracker from scratch
15:51 karolherbst: I already have some ideas which are inherently incompatible with clover sadly
17:00 pmoreau: karolherbst: We might want to distinguish between SPIR-V extensions that are purely SPIR-V, and the ones that match an OpenCL extension.
17:00 pmoreau: For the former, we should let spirv_to_nir handle them whereas we still want clover to check for the latter.
17:01 karolherbst: sure, but how can we decide from looking at the spirv alone?
17:01 pmoreau: No idea about a validation layer system for OpenCL, but that would be nice! (Note that I no longer am a Khronos member, whereas you are. ;-))
17:01 karolherbst: I don't think the spirv will list any non spirv extensions
17:01 karolherbst: pmoreau: ahh...
17:02 karolherbst: I was kind of thinking of doing something similiar to what we have for GL
17:02 karolherbst: like this split for validation and implementation
17:02 pmoreau: There are OpenCL extensions that add new features which require SPIR-V changes.
17:02 karolherbst: and have a env var to select if we validate or not
17:02 karolherbst: pmoreau: sure... but the spirv itself might not need one
17:03 karolherbst: anyway, there should always be a spirv extension for it
17:03 pmoreau: Let me see if I can find an example
17:04 pmoreau: Regarding the validation, the current spec mentions that validation is being performed by the driver AFAIR. Dunno if they plan on changing the formulation.
17:04 karolherbst: we could write a cl extension for it
17:04 karolherbst: we've done the same for gl
17:04 karolherbst: anyway
17:04 karolherbst: I would also go ICD only
17:05 karolherbst: so we would just select a different dispatch table
17:06 karolherbst: pmoreau: the painful part with clover is, that a lot of the validation stuff is just missing :/ and I kind of like the seperation we have for the graphic APIs, even if we don't really need it for GL
17:07 karolherbst: anyway... I was thinking about how I'd like clover to actually look like
17:07 pmoreau: “If the OpenCL environment supports the extension cl_khr_spirv_no_integer_wrap_decoration, then the environment must accept modules that declare use of the extension SPV_KHR_no_integer_wrap_decoration via OpExtension.” So there is an associated OpenCL extension associated to it.
17:07 karolherbst: and a lot of clovers current design is disliked by a bunch of others as well
17:07 karolherbst: pmoreau: yeah... that's usually the case
17:08 karolherbst: pmoreau: but spirv-llvm-translator just uses that extension
17:08 karolherbst: even though the openclc doesn't require it
17:08 pmoreau: Ah
17:11 karolherbst: pmoreau: well, we could just expose this extension anyway... :D
17:13 karolherbst: pmoreau: the thing about spirv extension is that on their own they don't do anything and we just consume the spirv
17:13 pmoreau: If we have nothing to do in clover and spirv_to_nir can support it, sure. :-)
17:13 karolherbst: well "support"
17:13 karolherbst: if we run into unsupported capabilities, we have a problem
17:13 karolherbst: but then compilation just fails
17:14 karolherbst: or new instructions or something
17:14 karolherbst: which wouldn't change anything anyway
17:21 pmoreau: I need to run, sorry. I’ll have a look at your changes tomorrow evening, and we can discuss further.