08.07.2020 13:06, Mikko Perttunen пишет:
> On 7/7/20 2:06 PM, Dmitry Osipenko wrote:
>> 02.07.2020 15:10, Mikko Perttunen пишет:
>>> Ok, so we would have two kinds of syncpoints for the job; one
>>> for kernel job tracking; and one that userspace can
>>> manipulate as it wants to.
>>>
>>> Could we
On 7/7/20 2:06 PM, Dmitry Osipenko wrote:
02.07.2020 15:10, Mikko Perttunen пишет:
Ok, so we would have two kinds of syncpoints for the job; one
for kernel job tracking; and one that userspace can
manipulate as it wants to.
Could we handle the job tracking syncpoint completely inside the
02.07.2020 15:10, Mikko Perttunen пишет:
> Ok, so we would have two kinds of syncpoints for the job; one
> for kernel job tracking; and one that userspace can
> manipulate as it wants to.
>
> Could we handle the job tracking syncpoint completely inside the kernel,
> i.e. allocate it in kernel
On 7/1/20 3:22 AM, Dmitry Osipenko wrote:
30.06.2020 13:26, Mikko Perttunen пишет:
On 6/29/20 10:42 PM, Dmitry Osipenko wrote:
Secondly, I suppose neither GPU, nor DLA could wait on a host1x sync
point, correct? Or are they integrated with Host1x HW?
They can access syncpoints directly.
30.06.2020 13:26, Mikko Perttunen пишет:
> On 6/29/20 10:42 PM, Dmitry Osipenko wrote:
>>
>> Secondly, I suppose neither GPU, nor DLA could wait on a host1x sync
>> point, correct? Or are they integrated with Host1x HW?
>>
>
> They can access syncpoints directly. (That's what I alluded to in the
On 6/29/20 10:42 PM, Dmitry Osipenko wrote:
Secondly, I suppose neither GPU, nor DLA could wait on a host1x sync
point, correct? Or are they integrated with Host1x HW?
They can access syncpoints directly. (That's what I alluded to in the
"Introduction to the hardware" section :) all those
29.06.2020 13:27, Mikko Perttunen пишет:
...
3. Sync points should be properly refcounted. Job's sync points
shouldn't be re-used while job is alive.
4. The job's sync point can't be re-used after job's submission (UAPI
constraint!). Userspace must free sync point and
29.06.2020 13:27, Mikko Perttunen пишет:
...
4. The job's sync point can't be re-used after job's submission (UAPI
constraint!). Userspace must free sync point and allocate a new one for
the next job submission. And now we:
- Know that job's sync point is always in a
29.06.2020 13:27, Mikko Perttunen пишет:
...
>> We don't need a dedicated sync point FD for all kinds of jobs, don't we?
>> For example, I don't see why a sync point FD may be needed in a case of
>> Opentegra jobs.
>
> I think it's cleaner if we have just one way to allocate syncpoints, and
>
On 6/29/20 5:36 AM, Dmitry Osipenko wrote:
28.06.2020 12:44, Mikko Perttunen пишет:
On 6/28/20 2:27 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
### IOCTL HOST1X_ALLOCATE_SYNCPOINT (on /dev/host1x)
Allocates a free syncpoint, returning a file descriptor representing
28.06.2020 12:44, Mikko Perttunen пишет:
> On 6/28/20 2:27 AM, Dmitry Osipenko wrote:
>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>>
>>> ### IOCTL HOST1X_ALLOCATE_SYNCPOINT (on /dev/host1x)
>>>
>>> Allocates a free syncpoint, returning a file descriptor representing it.
>>> Only the owner of the
23.06.2020 15:09, Mikko Perttunen пишет:
>
> ### IOCTL HOST1X_ALLOCATE_SYNCPOINT (on /dev/host1x)
>
> Allocates a free syncpoint, returning a file descriptor representing it.
> Only the owner of the file descriptor is allowed to mutate the value of
> the syncpoint.
>
> ```
> struct
On 6/28/20 2:27 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
### IOCTL HOST1X_ALLOCATE_SYNCPOINT (on /dev/host1x)
Allocates a free syncpoint, returning a file descriptor representing it.
Only the owner of the file descriptor is allowed to mutate the value of
the
13 matches
Mail list logo
