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