Alyssa Rosenzweig writes:
>> Alyssa: do you see any problem if we change to submit only one atom per
>> ioctl?
>
> I don't think so; aesthetically I don't like the extra kernel traffic,
> but that's not a real concern, and it sounds like that's the correct
> approach anyway.
>
> A big reason we
Kristian Høgsberg writes:
> On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie wrote:
>>
>> On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote:
>> >
>> > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig
>> > wrote:
>> > >
>> > > > Why aren't we using regular dma-buf fences here? The submit ioctl
> Alyssa: do you see any problem if we change to submit only one atom per
> ioctl?
I don't think so; aesthetically I don't like the extra kernel traffic,
but that's not a real concern, and it sounds like that's the correct
approach anyway.
A big reason we submit together on non-DRM is so we can
On Mon, Mar 4, 2019 at 6:43 PM Alyssa Rosenzweig wrote:
>
> Wooo!!!
>
> Seeing this patch in my inbox has been some of the best news all day!
>
> Without further ado, my (solicited?) comments:
>
> > +/* Copyright 2018, Linaro, Ltd., Rob Herring */
>
> Please triple check upstream that this
On 3/5/19 3:29 AM, Dave Airlie wrote:
On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote:
On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig wrote:
Why aren't we using regular dma-buf fences here? The submit ioctl
should be able to take a number of in fences to wait on and return an
out
> You should more likely be using syncobjects, not fences.
...I still don't know what either of them actually are...?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie wrote:
>
> On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote:
> >
> > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig
> > wrote:
> > >
> > > > Why aren't we using regular dma-buf fences here? The submit ioctl
> > > > should be able to take a
On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote:
>
> On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig wrote:
> >
> > > Why aren't we using regular dma-buf fences here? The submit ioctl
> > > should be able to take a number of in fences to wait on and return an
> > > out fence if requested.
On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig wrote:
>
> > Why aren't we using regular dma-buf fences here? The submit ioctl
> > should be able to take a number of in fences to wait on and return an
> > out fence if requested.
>
> Ah-ha, that sounds like the "proper" approach for mainline.
> Why aren't we using regular dma-buf fences here? The submit ioctl
> should be able to take a number of in fences to wait on and return an
> out fence if requested.
Ah-ha, that sounds like the "proper" approach for mainline. Much of this
was (incorrectly) inherited from the Arm driver. Thank
On Mon, Mar 4, 2019 at 4:43 PM Alyssa Rosenzweig wrote:
>
> Wooo!!!
>
> Seeing this patch in my inbox has been some of the best news all day!
>
> Without further ado, my (solicited?) comments:
>
> > +/* Copyright 2018, Linaro, Ltd., Rob Herring */
>
> Please triple check upstream that this
Wooo!!!
Seeing this patch in my inbox has been some of the best news all day!
Without further ado, my (solicited?) comments:
> +/* Copyright 2018, Linaro, Ltd., Rob Herring */
Please triple check upstream that this license is okay; the other files
in include/drm-uapi are BSDish.
> +/*
On Mon, Mar 4, 2019 at 10:12 AM Tomeu Vizoso wrote:
>
> This backend interacts with the new DRM driver for Midgard GPUs which is
> currently in development.
>
> When using this backend, Panfrost has roughly on-par functionality as
> when using the non-DRM driver from Arm.
>
> Signed-off-by: Tomeu
This backend interacts with the new DRM driver for Midgard GPUs which is
currently in development.
When using this backend, Panfrost has roughly on-par functionality as
when using the non-DRM driver from Arm.
Signed-off-by: Tomeu Vizoso
---
include/drm-uapi/panfrost_drm.h| 128
14 matches
Mail list logo
