[PATCH v5 00/21] Host1x sync point UAPI should not be used for tracking DRM jobs

Mikko Perttunen cyndis at kapsi.fi
Mon Mar 1 08:19:04 UTC 2021


On 2/27/21 1:19 PM, Dmitry Osipenko wrote:
> 03.02.2021 14:18, Mikko Perttunen пишет:
> ...
>>> I'll need more time to think about it.
>>>
>>
>> How about something like this:
>>
>> Turn the syncpt_incr field back into an array of structs like
>>
>> #define DRM_TEGRA_SUBMIT_SYNCPT_INCR_REPLACE_SYNCOBJ        (1<<0)
>> #define DRM_TEGRA_SUBMIT_SYNCPT_INCR_PATCH_DYNAMIC_SYNCPT    (1<<1)
>>
>> struct drm_tegra_submit_syncpt_incr {
>>      /* can be left as zero if using dynamic syncpt */
>>      __u32 syncpt_id;
>>      __u32 flags;
>>
>>      struct {
>>          __u32 syncobj;
>>          __u32 value;
>>      } fence;
>>
>>      /* patch word as such:
>>           * *word = *word | (syncpt_id << shift)
>>           */
>>      struct {
>>          __u32 gather_offset_words;
>>          __u32 shift;
>>      } patch;
>> };
>>
>> So this will work similarly to the buffer reloc system; the kernel
>> driver will allocate a job syncpoint and patch in the syncpoint ID if
>> requested, and allows outputting syncobjs for each increment.
> 
> I haven't got any great ideas so far, but it feels that will be easier
> and cleaner if we could have separate job paths (and job IOCTLS) based
> on hardware generation since the workloads a too different. The needs of
> a newer h/w are too obscure for me and absence of userspace code,
> firmware sources and full h/w documentation do not help.
> 
> There still should be quite a lot to share, but things like
> mapping-to-channel and VM sync points are too far away from older h/w,
> IMO. This means that code path before drm-sched and path for job-timeout
> handling should be separate.
> 
> Maybe later on it will become cleaner that we actually could unify it
> all nicely, but for now it doesn't look like a good idea to me.
> 
> Mikko, do you have any objections to trying out variant with the
> separate paths?
> 

I'm on vacation for the next two weeks. I'll think about it and post a 
proposal once I'm back to work.

Mikko


More information about the dri-devel mailing list