On Fri, 2 Jul 2021 12:49:55 -0400 Alyssa Rosenzweig alyssa@collabora.com wrote:
> #define PANFROST_BO_REF_EXCLUSIVE 0x1 > +#define PANFROST_BO_REF_NO_IMPLICIT_DEP 0x2This seems logically backwards. NO_IMPLICIT_DEP makes sense if we're trying to keep backwards compatibility, but here you're crafting a new interface totally from scratch. If anything, isn't BO_REF_IMPLICIT_DEP the flag you'd want?
AFAICT, all other drivers make the no-implicit-dep an opt-in, and I didn't want to do things differently in panfrost. But if that's really an issue, I can make it an opt-out.
I don't have strong feelings either way. I was just under the impressions other drivers did this for b/w compat reasons which don't apply here.
Okay, I think I'll keep it like that unless there's a strong reason to make no-implicit dep the default. It's safer to oversync than the skip the synchronization, so it does feel like something the user should explicitly enable.
Hmm. I'm not /opposed/ and I know kbase uses strides but it seems like somewhat unwarranted complexity, and there is a combinatoric explosion here (if jobs, bo refs, and syncobj refs use 3 different versions, as this encoding permits... as opposed to just specifying a UABI version or something like that)
Sounds like a good idea. I'll add a version field and map that to a <job_stride,bo_ref_stride,syncobj_ref_stride> tuple.
Cc Steven, does this make sense?
I have this approach working, and I must admit I prefer it to the per-object stride field passed to the submit struct.