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 kernel
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 duri
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. (Th
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
>
30.06.2020 13:55, Mikko Perttunen пишет:
>
>
> On 6/29/20 1:59 AM, Dmitry Osipenko wrote:
>> 28.06.2020 14:16, Mikko Perttunen пишет:
>>> On 6/26/20 7:35 PM, Dmitry Osipenko wrote:
26.06.2020 10:34, Thierry Reding пишет:
> On Fri, Jun 26, 2020 at 01:47:46AM +0300, Dmitry Osipenko wrote:
On 6/29/20 1:59 AM, Dmitry Osipenko wrote:
28.06.2020 14:16, Mikko Perttunen пишет:
On 6/26/20 7:35 PM, Dmitry Osipenko wrote:
26.06.2020 10:34, Thierry Reding пишет:
On Fri, Jun 26, 2020 at 01:47:46AM +0300, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
### DRM_TEGRA_CHA
On 6/29/20 3:00 AM, Dmitry Osipenko wrote:
28.06.2020 13:28, Mikko Perttunen пишет:
On 6/28/20 1:32 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
/* Command is an opcode gather from a GEM handle */
#define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
/* Command is an opc
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 th
On Fri, Jun 26, 2020 at 04:59:45PM +0300, Dmitry Osipenko wrote:
> 26.06.2020 16:38, Daniel Vetter пишет:
> > On Fri, Jun 26, 2020 at 01:40:40PM +0200, Thierry Reding wrote:
> >> On Fri, Jun 26, 2020 at 01:06:58PM +0200, Karol Herbst wrote:
> >>> On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen wro
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 alloc
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 he
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
> then
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 it
28.06.2020 14:16, Mikko Perttunen пишет:
> On 6/26/20 7:35 PM, Dmitry Osipenko wrote:
>> 26.06.2020 10:34, Thierry Reding пишет:
>>> On Fri, Jun 26, 2020 at 01:47:46AM +0300, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
> ### DRM_TEGRA_CHANNEL_MAP
>
> Make memory
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 f
28.06.2020 13:28, Mikko Perttunen пишет:
> On 6/28/20 1:32 AM, Dmitry Osipenko wrote:
>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>> /* Command is an opcode gather from a GEM handle */
>>> #define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
>>> /* Command is an opcode gather from a user pointer
23.06.2020 15:09, Mikko Perttunen пишет:
> struct drm_tegra_submit_syncpt_incr {
> /*
> * [in] Syncpoint FD of the syncpoint that the job will
> * increment.
> */
> __s32 syncpt_fd;
>
> /*
> * [in] Number of increments that the job will
23.06.2020 15:09, Mikko Perttunen пишет:
> /* Command is an opcode gather from a GEM handle */
> #define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
> /* Command is an opcode gather from a user pointer */
> #define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR 1
> /* Command is a wait for syncpt fe
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 host1x_ctrl_a
On 6/26/20 7:35 PM, Dmitry Osipenko wrote:
26.06.2020 10:34, Thierry Reding пишет:
On Fri, Jun 26, 2020 at 01:47:46AM +0300, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
### DRM_TEGRA_CHANNEL_MAP
Make memory accessible by the engine while executing work on the channel.
```
On 6/28/20 12:47 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
struct drm_tegra_submit_syncpt_incr {
/*
* [in] Syncpoint FD of the syncpoint that the job will
* increment.
*/
__s32 syncpt_fd;
/*
* [in] Nu
On 6/28/20 1:32 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
/* Command is an opcode gather from a GEM handle */
#define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
/* Command is an opcode gather from a user pointer */
#define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR
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 syncpoin
26.06.2020 10:34, Thierry Reding пишет:
> On Fri, Jun 26, 2020 at 01:47:46AM +0300, Dmitry Osipenko wrote:
>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>> ### DRM_TEGRA_CHANNEL_MAP
>>>
>>> Make memory accessible by the engine while executing work on the channel.
>>>
>>> ```
>>> #define DRM_TEGRA_CH
26.06.2020 16:38, Daniel Vetter пишет:
> On Fri, Jun 26, 2020 at 01:40:40PM +0200, Thierry Reding wrote:
>> On Fri, Jun 26, 2020 at 01:06:58PM +0200, Karol Herbst wrote:
>>> On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen wrote:
# Host1x/TegraDRM UAPI proposal
This is a proposa
On Fri, Jun 26, 2020 at 01:40:40PM +0200, Thierry Reding wrote:
> On Fri, Jun 26, 2020 at 01:06:58PM +0200, Karol Herbst wrote:
> > On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen wrote:
> > >
> > > # Host1x/TegraDRM UAPI proposal
> > >
> > > This is a proposal for a stable UAPI for Host1x and Teg
On Fri, Jun 26, 2020 at 01:06:58PM +0200, Karol Herbst wrote:
> On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen wrote:
> >
> > # Host1x/TegraDRM UAPI proposal
> >
> > This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace
> > the current TegraDRM UAPI that is behind `STAGING` and
On Fri, Jun 26, 2020 at 1:13 PM Mikko Perttunen wrote:
>
> On 6/26/20 2:06 PM, Karol Herbst wrote:
> > On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen wrote:
> >>
> >> # Host1x/TegraDRM UAPI proposal
> >>
> >> This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace
> >> the curre
On 6/26/20 2:06 PM, Karol Herbst wrote:
On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen wrote:
# Host1x/TegraDRM UAPI proposal
This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace
the current TegraDRM UAPI that is behind `STAGING` and quite obsolete in
many ways.
I haven'
On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen wrote:
>
> # Host1x/TegraDRM UAPI proposal
>
> This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace
> the current TegraDRM UAPI that is behind `STAGING` and quite obsolete in
> many ways.
>
> I haven't written any implementation y
On 6/26/20 2:24 AM, Dmitry Osipenko wrote:
25.06.2020 12:16, Mikko Perttunen пишет:
On 6/25/20 2:11 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
/* Command is an opcode gather from a GEM handle */
#define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
/* Command is an opc
On 6/26/20 1:50 AM, Dmitry Osipenko wrote:
25.06.2020 12:27, Mikko Perttunen пишет:
On 6/25/20 1:33 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
struct drm_tegra_submit_relocation {
/* [in] Index of GATHER or GATHER_UPTR command in commands. */
__u32
23.06.2020 15:09, Mikko Perttunen пишет:
> ### DRM_TEGRA_CHANNEL_MAP
>
> Make memory accessible by the engine while executing work on the channel.
>
> ```
> #define DRM_TEGRA_CHANNEL_MAP_READWRITE (1<<0)
>
> struct drm_tegra_channel_map {
> /*
> * [in] ID of the channel f
25.06.2020 12:27, Mikko Perttunen пишет:
> On 6/25/20 1:33 AM, Dmitry Osipenko wrote:
>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>> struct drm_tegra_submit_relocation {
>>> /* [in] Index of GATHER or GATHER_UPTR command in commands. */
>>> __u32 gather_command_index;
>>>
>>>
25.06.2020 12:16, Mikko Perttunen пишет:
> On 6/25/20 2:11 AM, Dmitry Osipenko wrote:
>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>> /* Command is an opcode gather from a GEM handle */
>>> #define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
>>> /* Command is an opcode gather from a user pointer
On Fri, Jun 26, 2020 at 01:47:46AM +0300, Dmitry Osipenko wrote:
> 23.06.2020 15:09, Mikko Perttunen пишет:
> > ### DRM_TEGRA_CHANNEL_MAP
> >
> > Make memory accessible by the engine while executing work on the channel.
> >
> > ```
> > #define DRM_TEGRA_CHANNEL_MAP_READWRITE (1<<0)
> >
>
On 6/25/20 1:33 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
struct drm_tegra_submit_relocation {
/* [in] Index of GATHER or GATHER_UPTR command in commands. */
__u32 gather_command_index;
/*
* [in] Mapping handle (obtained through CHA
On 6/25/20 3:47 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
#define DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE (1<<0)
#define DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ (1<<1)
The sync object shouldn't be created by the kernel driver and we
shouldn't need the sync-fil
On 6/25/20 2:23 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
struct drm_tegra_channel_submit {
__u32 channel_id;
__u32 flags;
/**
* [in] Timeout in microseconds after which the kernel may
* consider the job to have hung an
On 6/24/20 11:55 PM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
...
* Previously present GEM IOCTLs (GEM_CREATE, GEM_MMAP) are not present.
Not sure if they are still needed.
Hello Mikko!
A quick comment for the starter. Switching away from the Tegra-specific
GEM IOCTLs t
On 6/25/20 2:11 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
/* Command is an opcode gather from a GEM handle */
#define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
/* Command is an opcode gather from a user pointer */
#define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR
23.06.2020 15:09, Mikko Perttunen пишет:
> struct drm_tegra_channel_submit {
> __u32 channel_id;
> __u32 flags;
>
> /**
> * [in] Timeout in microseconds after which the kernel may
> * consider the job to have hung and may reap it and
> * fast-
23.06.2020 15:09, Mikko Perttunen пишет:
> #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE (1<<0)
> #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ (1<<1)
The sync object shouldn't be created by the kernel driver and we
shouldn't need the sync-file FD.
Please consider this example of how
23.06.2020 15:09, Mikko Perttunen пишет:
> /* Command is an opcode gather from a GEM handle */
> #define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
> /* Command is an opcode gather from a user pointer */
> #define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR 1
I'm a bit dubious about whether we
23.06.2020 15:09, Mikko Perttunen пишет:
>
> struct drm_tegra_channel_submit {
> __u32 channel_id;
> __u32 flags;
>
> /**
> * [in] Timeout in microseconds after which the kernel may
> * consider the job to have hung and may reap it and
> * fa
25.06.2020 02:18, Dmitry Osipenko пишет:
> 23.06.2020 15:09, Mikko Perttunen пишет:
>> struct drm_tegra_channel_submit {
>> __u32 channel_id;
>> __u32 flags;
>>
>> /**
>> * [in] Timeout in microseconds after which the kernel may
>> * consider the job to h
23.06.2020 15:09, Mikko Perttunen пишет:
> struct drm_tegra_submit_relocation {
> /* [in] Index of GATHER or GATHER_UPTR command in commands. */
> __u32 gather_command_index;
>
> /*
> * [in] Mapping handle (obtained through CHANNEL_MAP) of the memory
> *
23.06.2020 15:09, Mikko Perttunen пишет:
...
> * Previously present GEM IOCTLs (GEM_CREATE, GEM_MMAP) are not present.
> Not sure if they are still needed.
Hello Mikko!
A quick comment for the starter. Switching away from the Tegra-specific
GEM IOCTLs to the dma-buf heaps is a such radical change
# Host1x/TegraDRM UAPI proposal
This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace
the current TegraDRM UAPI that is behind `STAGING` and quite obsolete in
many ways.
I haven't written any implementation yet -- I'll do that once there is
some agreement on the high-level
50 matches
Mail list logo
