02:01Lynne: zzoon: btw, seeking on 8-bit hevc (and I'm guessing 10bit) is broken on anv
02:02Lynne: seems to crash the GPU, I get a device lost
02:36zzoon[m]: Lynne: you mean decoding?
04:05Lynne: yup, decoding, on skylake
04:05Lynne: but I think it'll do the same on more modern systems
08:39DemiMarie: Lynne: Crash the whole GPU or just the logical device?
08:40Lynne: with intel, doesn't really matter
08:41DemiMarie: Because the system recovers and the fault is contained?
08:42zzoon: Lynne: I looked into it but it seems that it tries to GetQueryPoolResults without Begin/End query.
08:42zzoon: that leads to timeout on gpu side.
08:42dj-death: GetQueryPoolResults is a cpu thing
08:42dj-death: I doubt it can make the device go wrong
08:42ccr:thinks about a Anakin/Padme Star Wars prequel meme for some reason ..
08:43dj-death: but who knows, HW is interesting
08:43zzoon: then that means it doesn't do the relevant Begin/End query at all.
08:43dj-death: zzoon: unless there is a CmdCopyQueryResult on a never written query
08:43dj-death: that would hang indeed
08:44dj-death: or rather wait indefinitely until the kernel decides it had enough
08:44Lynne: we don't copy query results
08:44zzoon: ffmpeg doesn't do copy query
08:46dj-death: okay
08:46dj-death: so the only way GetQueryPoolResults is going wrong is that the query was never ended
08:46dj-death: and you have VK_QUERY_RESULT_WAIT_BIT
08:47zzoon: or didn't even query, which I suspect.
08:47dj-death: yeah
08:47dj-death: I remember trying to submit a change to the spec to add a VU for this
08:47dj-death: I don't remember if it made it
08:48dj-death: actually :
08:48dj-death: VUID-vkGetQueryPoolResults-None-09401
08:48dj-death: All queries used by the command must not be uninitialized
08:48dj-death: so I guess you should get some validation errors on this
08:48dj-death: assuming support for this VU was added
08:49dj-death: there might be a spec gap given that validation implementation
08:49dj-death: it only checks if you never reset the query
08:50dj-death: but then if you don't do anything with this and try to read it with VK_QUERY_RESULT_WAIT_BIT
08:50dj-death: you'll wait forever
09:06dj-death: Lynne: did you have any luck at trying to reduce the shader issue?
09:07Lynne: no, I went down the rabbit hole of trying to figure out why it sort of works on alder lake and doesn't work at all on skylake
09:08Lynne: on skylake, the very first write is bad, and on alder lake, the header gets written correctly but the rest has a bitstream desync
09:09Lynne: the entropy coder state is good, which means the arithmetic is good, but what gets written to the output buffer is bad
09:10Lynne: just regular uint8_t writes at 1-byte alignment
09:10dj-death: if the header write is small enough maybe that extract into some kind of shader_runner or something else
09:32Lynne: yup, I can do it in 20 minutes, but I've got something to do, so I'll be back in 2h or so
20:40colinmarc: can I import a timeline syncobj directly as a timeline semaphore in vulkan? or do I have to export a syncfile and then import that as a binary semaphore?
20:45colinmarc: It seems like that should be possible, but it also seems like I have to use `VK_SEMAPHORE_IMPORT_TEMPORARY_BIT`, and also other compositors I've seen seem to do the syncfile -> binary semaphore dance
21:46colinmarc: ah, I missed that I can use OPAQUE_FD for that
23:21emersion: colinmarc: OPAQUE_FD may give you something which isn't a drm_syncobj
23:21emersion: would be really nice to have a vulkan ext for drm_syncobj