On 06/07/2021 13:48, Alyssa Rosenzweig wrote:
>> My concern is if we ever find a security bug which requires new
>> information/behaviour in the submit ABI to properly fix. In this case it
>> would be appropriate to backport a 'feature' (bug fix) which provides a
>> new ABI but it would need to be
> My concern is if we ever find a security bug which requires new
> information/behaviour in the submit ABI to properly fix. In this case it
> would be appropriate to backport a 'feature' (bug fix) which provides a
> new ABI but it would need to be a small change. A flags field where we
> can set a
On 05/07/2021 09:43, Boris Brezillon wrote:
> Hi Steven,
>
> On Mon, 5 Jul 2021 09:22:39 +0100
> Steven Price wrote:
>
>> On 02/07/2021 19:11, Boris Brezillon wrote:
>>> On Fri, 2 Jul 2021 12:49:55 -0400
>>> Alyssa Rosenzweig wrote:
>>>
>> ```
>>> #define PANFROST_BO_REF_EXCLUSI
Hi Steven,
On Mon, 5 Jul 2021 09:22:39 +0100
Steven Price wrote:
> On 02/07/2021 19:11, Boris Brezillon wrote:
> > On Fri, 2 Jul 2021 12:49:55 -0400
> > Alyssa Rosenzweig wrote:
> >
> ```
> > #define PANFROST_BO_REF_EXCLUSIVE 0x1
> > +#define PANFROST_BO_REF_NO_IMPLICI
On 02/07/2021 19:11, Boris Brezillon wrote:
> On Fri, 2 Jul 2021 12:49:55 -0400
> Alyssa Rosenzweig wrote:
>
```
> #define PANFROST_BO_REF_EXCLUSIVE0x1
> +#define PANFROST_BO_REF_NO_IMPLICIT_DEP 0x2
```
This seems logically backwards. NO_IMPLICIT_DEP ma
On Fri, 2 Jul 2021 12:49:55 -0400
Alyssa Rosenzweig wrote:
> > > ```
> > > > #define PANFROST_BO_REF_EXCLUSIVE 0x1
> > > > +#define PANFROST_BO_REF_NO_IMPLICIT_DEP0x2
> > > ```
> > >
> > > This seems logically backwards. NO_IMPLICIT_DEP makes sense if we're
> > > trying to ke
On Fri, 2 Jul 2021 12:49:55 -0400
Alyssa Rosenzweig wrote:
> > > Why is there padding instead of putting point first?
> >
> > We can move the point field first, but we need to keep the explicit
> > padding: the struct has to be 64bit aligned because of the __u64 field
> > (which the compiler t
> > What is handle? What is point?
>
> Handle is a syncobj handle, point is the point in a syncobj timeline.
> I'll document those fields.
OK.
> > Why is there padding instead of putting point first?
>
> We can move the point field first, but we need to keep the explicit
> padding: the struct h
On Fri, 2 Jul 2021 11:13:16 -0400
Alyssa Rosenzweig wrote:
> ```
> > +/* Syncobj reference passed at job submission time to encode explicit
> > + * input/output fences.
> > + */
> > +struct drm_panfrost_syncobj_ref {
> > + __u32 handle;
> > + __u32 pad;
> > + __u64 point;
> > +};
> ```
>
> Better, but I was hoping we can mostly delete panfrost_ioctl_submit(),
> leaving something along the lines of:
>
> static int panfrost_ioctl_submit(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> struct panfrost_submitqueue *queue;
> struct drm_panfro
On 02/07/2021 15:32, Boris Brezillon wrote:
> This should help limit the number of ioctls when submitting multiple
> jobs. The new ioctl also supports syncobj timelines and BO access flags.
>
> v3:
> * Re-use panfrost_get_job_bos() and panfrost_get_job_in_syncs() in the
> old submit path
>
> Si
```
> +/* Syncobj reference passed at job submission time to encode explicit
> + * input/output fences.
> + */
> +struct drm_panfrost_syncobj_ref {
> + __u32 handle;
> + __u32 pad;
> + __u64 point;
> +};
```
What is handle? What is point? Why is there padding instead of putting
point f
This should help limit the number of ioctls when submitting multiple
jobs. The new ioctl also supports syncobj timelines and BO access flags.
v3:
* Re-use panfrost_get_job_bos() and panfrost_get_job_in_syncs() in the
old submit path
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/
13 matches
Mail list logo
