Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> writes: > Will GuC folks be reviewing this work? I don't know. If you mean the i915 devs interfacing with the GuC, I know John/Rodrigo seemed a bit resistant writing the patches to give userspace this trivial format guarantee on the blob. So, I hoped they would write the patches (3 & 4 in my series), but now I'm hoping they will at least accept the patches. > Quick sanity check maybe makes sense, given data is being "sent" to > userspace directly, I am just not sure if it is worth having in > non-debug builds of i915. Though I will agree not having it in > production then largely defeats the purpose so dunno. The check seems fairly trivial, and it seems like i915 should provide whatever guidance/guarantee is possible to userspace. (Thus, do it once per boot even on release builds.) See also, the commit message I added. > Effective difference if GuC load fails versus userspace libraries > failing to parse hwconfig? Lots of potential things to consider. Personally, I think for internal Intel builds, if this check fails, then it ought to cause the GuC to always fail to load, which today means the device will be wedged. For external builds, I think it should still load the GuC but not send the blob to userspace. This is what should happen with the patches in this series. (I really hope this never happens, which it why I think the internal builds should be so harsh.) Now ... if i915 ever regains the ability to drive the device without the closed source GuC, well... No reason to go off on unrealistic tangents. :) Also, later down the road for released products, userspace drivers may choose to bypass the hwconfig to limit the dependence on GuC. That is a related, but different topic. -Jordan
