On 2023-04-26 04:52:43, Daniel Vetter wrote:
>
> Joonas asked me to put my thoughts here:
>
> - in general the "feature discovery by trying it out" approach is most
> robust and hence preferred, but it's also not something that's required
> when there's good reasons against it
More robust
On 4/26/2023 9:48 AM, Teres Alexis, Alan Previn wrote:
On Wed, 2023-04-26 at 13:52 +0200, Daniel Vetter wrote:
On Tue, Apr 25, 2023 at 04:41:54PM +0300, Joonas Lahtinen wrote:
(+ Faith and Daniel as they have been involved in previous discussions)
Quoting Jordan Justen (2023-04-24 20:13:00)
On Wed, 2023-04-26 at 13:52 +0200, Daniel Vetter wrote:
> On Tue, Apr 25, 2023 at 04:41:54PM +0300, Joonas Lahtinen wrote:
> > (+ Faith and Daniel as they have been involved in previous discussions)
> > Quoting Jordan Justen (2023-04-24 20:13:00)
> > > On 2023-04-24 02:08:43, Tvrtko Ursulin wrote:
On Tue, Apr 25, 2023 at 04:41:54PM +0300, Joonas Lahtinen wrote:
> (+ Faith and Daniel as they have been involved in previous discussions)
>
> Quoting Jordan Justen (2023-04-24 20:13:00)
> > On 2023-04-24 02:08:43, Tvrtko Ursulin wrote:
> > >
> > > Being able to "list" supported extensions
On 2023-04-25 06:41:54, Joonas Lahtinen wrote:
> (+ Faith and Daniel as they have been involved in previous discussions)
>
> Quoting Jordan Justen (2023-04-24 20:13:00)
> > On 2023-04-24 02:08:43, Tvrtko Ursulin wrote:
> > >
> > > Being able to "list" supported extensions sounds like a
On Tue, 2023-04-25 at 16:41 +0300, Joonas Lahtinen wrote:
> (+ Faith and Daniel as they have been involved in previous discussions)
An orthogonal (but losely related) question: Is PXP the only subsystem that has
the unique problem of: Uses a delayed worker to complete all dependencies for
init..
(+ Faith and Daniel as they have been involved in previous discussions)
Quoting Jordan Justen (2023-04-24 20:13:00)
> On 2023-04-24 02:08:43, Tvrtko Ursulin wrote:
> >
> > Being able to "list" supported extensions sounds like a reasonable
> > principle, albeit a departure from the design
On 2023-04-24 02:08:43, Tvrtko Ursulin wrote:
>
> Being able to "list" supported extensions sounds like a reasonable
> principle, albeit a departure from the design direction to date.
> Which means there are probably no quick solutions. Also, AFAIU, only
> PXP context create is the problematic
[fixed mailing lists addresses]
On 24/04/2023 09:36, Jordan Justen wrote:
On 2023-04-23 00:05:06, Yang, Fei wrote:
On 2023-04-20 09:11:18, Yang, Fei wrote:
On 20/04/2023 12:39, Andi Shyti wrote:
Hi Fei,
because this is an API change, we need some more information here.
First of all you
On 2023-04-20 09:11:18, Yang, Fei wrote:
> > On 20/04/2023 12:39, Andi Shyti wrote:
> >> Hi Fei,
> >>
> >>> To comply with the design that buffer objects shall have immutable
> >>> cache setting through out their life cycle, {set, get}_caching ioctl's
> >>> are no longer supported from MTL onward.
Hi Fei,
> >>> To comply with the design that buffer objects shall have immutable
> >>> cache setting through out their life cycle, {set, get}_caching ioctl's
> >>> are no longer supported from MTL onward. With that change caching
> >>> policy can only be set at object creation time. The current
> On 20/04/2023 12:39, Andi Shyti wrote:
>> Hi Fei,
>>
>>> To comply with the design that buffer objects shall have immutable
>>> cache setting through out their life cycle, {set, get}_caching ioctl's
>>> are no longer supported from MTL onward. With that change caching
>>> policy can only be set
On 20/04/2023 12:39, Andi Shyti wrote:
Hi Fei,
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation
Hi Fei,
> To comply with the design that buffer objects shall have immutable
> cache setting through out their life cycle, {set, get}_caching ioctl's
> are no longer supported from MTL onward. With that change caching
> policy can only be set at object creation time. The current code
> applies a
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a
Hi Fei,
On Wed, Apr 19, 2023 at 02:12:19PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> To comply with the design that buffer objects shall have immutable
> cache setting through out their life cycle, {set, get}_caching ioctl's
> are no longer supported from MTL onward. With that
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out its life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a
On Sun, Apr 16, 2023 at 11:25:03PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> To comply with the design that buffer objects shall have immutable
> cache setting through out its life cycle, {set, get}_caching ioctl's
/its/their/
> are no longer supported from MTL onward. With that
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out its life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out its life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a
21 matches
Mail list logo
