Time for execbuf3 ?

Time for execbuf3 ?

[Lionel Landwerlin]

[-- Attachment #1.1: Type: text/plain, Size: 1493 bytes --]

Hi all,

There are couple of extensions coming up for our userspace drivers 
(anv/i965) where we need to add additional parameters to execbuf :

    - VK_KHR_timeline_semaphore : supplying u64 points together with
    syncobjs [1]
    - a non public piece of work related to performance counters [2] :
    supplying a performance configuration ID to reconfigure the
    performance HW


Recently some discussions on IRC also highlighted the need for better 
reporting of execbuf failure.
We have a number of bugs where execbuf fails after a number of hours 
running an application or some random conditions and it's almost 
impossible to figure out where the problem lies.
Having a way for i915 to report what validation the input parameters 
actually fail would more helpful than EINVAL.

Some of the virtual engine stuff could also fit in there but maybe the 
timeline is too tight for that.

We've added a i915_query mechanism that is easily extendable and after 
exposing topology, it seems to be useful for adding other types of 
queries (engine discovery, memory regions and the series in [2] also 
exposes performance query configuration data).

I would really like to see a similar mechanism for an execbuf3.
How can we help getting started in that direction?
Do people have a better idea?

Thanks,

-Lionel

[1] : 
https://github.com/djdeath/linux/commit/8f26fca6dc41d98cb01c5758be01e382a72c84aa
[2] : 
https://github.com/djdeath/linux/commit/58be37aae22f7b9b31792aa13415cb5809087c10

[-- Attachment #1.2: Type: text/html, Size: 2143 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Time for execbuf3 ?

[Chris Wilson]

Quoting Lionel Landwerlin (2019-03-19 16:39:52)
> Hi all,
> 
> There are couple of extensions coming up for our userspace drivers (anv/i965)
> where we need to add additional parameters to execbuf :
> 
>     - VK_KHR_timeline_semaphore : supplying u64 points together with syncobjs
>     [1]
>     - a non public piece of work related to performance counters [2] :
>     supplying a performance configuration ID to reconfigure the performance HW
> 
> 
> Recently some discussions on IRC also highlighted the need for better reporting
> of execbuf failure.
> We have a number of bugs where execbuf fails after a number of hours running an
> application or some random conditions and it's almost impossible to figure out
> where the problem lies.
> Having a way for i915 to report what validation the input parameters actually
> fail would more helpful than EINVAL.
> 
> Some of the virtual engine stuff could also fit in there but maybe the timeline
> is too tight for that.
> 
> We've added a i915_query mechanism that is easily extendable and after exposing
> topology, it seems to be useful for adding other types of queries (engine
> discovery, memory regions and the series in [2] also exposes performance query
> configuration data).
> 
> I would really like to see a similar mechanism for an execbuf3.
> How can we help getting started in that direction?
> Do people have a better idea?

https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=execbuf3&id=11929f5262aa24ae7a80cf797c2d088eceeb6421
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Time for execbuf3 ?

[Joonas Lahtinen]

Quoting Lionel Landwerlin (2019-03-19 18:39:52)
> Hi all,
> 
> There are couple of extensions coming up for our userspace drivers (anv/i965)
> where we need to add additional parameters to execbuf :
> 
>     - VK_KHR_timeline_semaphore : supplying u64 points together with syncobjs
>     [1]
>     - a non public piece of work related to performance counters [2] :
>     supplying a performance configuration ID to reconfigure the performance HW
> 
> 
> Recently some discussions on IRC also highlighted the need for better reporting
> of execbuf failure.
> We have a number of bugs where execbuf fails after a number of hours running an
> application or some random conditions and it's almost impossible to figure out
> where the problem lies.
> Having a way for i915 to report what validation the input parameters actually
> fail would more helpful than EINVAL.
> 
> Some of the virtual engine stuff could also fit in there but maybe the timeline
> is too tight for that.
> 
> We've added a i915_query mechanism that is easily extendable and after exposing
> topology, it seems to be useful for adding other types of queries (engine
> discovery, memory regions and the series in [2] also exposes performance query
> configuration data).
> 
> I would really like to see a similar mechanism for an execbuf3.
> How can we help getting started in that direction?

The direction has certainly been considered for a while already, it's
mostly a matter of gathering all the requirements to avoid execbuf4 next
year :)

So if you have any other potential requirements, now is a good time to
mention them.

Regards, Joonas

> Do people have a better idea?
> 
> Thanks,
> 
> -Lionel
> 
> [1] : https://github.com/djdeath/linux/commit/
> 8f26fca6dc41d98cb01c5758be01e382a72c84aa
> [2] : https://github.com/djdeath/linux/commit/
> 58be37aae22f7b9b31792aa13415cb5809087c10
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Time for execbuf3 ?

[Lionel Landwerlin]

On 21/03/2019 09:46, Joonas Lahtinen wrote:
> Quoting Lionel Landwerlin (2019-03-19 18:39:52)
>> Hi all,
>>
>> There are couple of extensions coming up for our userspace drivers (anv/i965)
>> where we need to add additional parameters to execbuf :
>>
>>      - VK_KHR_timeline_semaphore : supplying u64 points together with syncobjs
>>      [1]
>>      - a non public piece of work related to performance counters [2] :
>>      supplying a performance configuration ID to reconfigure the performance HW
>>
>>
>> Recently some discussions on IRC also highlighted the need for better reporting
>> of execbuf failure.
>> We have a number of bugs where execbuf fails after a number of hours running an
>> application or some random conditions and it's almost impossible to figure out
>> where the problem lies.
>> Having a way for i915 to report what validation the input parameters actually
>> fail would more helpful than EINVAL.
>>
>> Some of the virtual engine stuff could also fit in there but maybe the timeline
>> is too tight for that.
>>
>> We've added a i915_query mechanism that is easily extendable and after exposing
>> topology, it seems to be useful for adding other types of queries (engine
>> discovery, memory regions and the series in [2] also exposes performance query
>> configuration data).
>>
>> I would really like to see a similar mechanism for an execbuf3.
>> How can we help getting started in that direction?
> The direction has certainly been considered for a while already, it's
> mostly a matter of gathering all the requirements to avoid execbuf4 next
> year :)
>
> So if you have any other potential requirements, now is a good time to
> mention them.
>
> Regards, Joonas


Mostly it's just about having the ability to extend it.
I can't really tell you up front what we're going to need until we do :)

Do you know when that work would start?

Thanks

-Lionel

>
>> Do people have a better idea?
>>
>> Thanks,
>>
>> -Lionel
>>
>> [1] : https://github.com/djdeath/linux/commit/
>> 8f26fca6dc41d98cb01c5758be01e382a72c84aa
>> [2] : https://github.com/djdeath/linux/commit/
>> 58be37aae22f7b9b31792aa13415cb5809087c10


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Time for execbuf3 ?

[Maarten Lankhorst]

Op 19-03-2019 om 18:20 schreef Chris Wilson:
> Quoting Lionel Landwerlin (2019-03-19 16:39:52)
>> Hi all,
>>
>> There are couple of extensions coming up for our userspace drivers (anv/i965)
>> where we need to add additional parameters to execbuf :
>>
>>     - VK_KHR_timeline_semaphore : supplying u64 points together with syncobjs
>>     [1]
>>     - a non public piece of work related to performance counters [2] :
>>     supplying a performance configuration ID to reconfigure the performance HW
>>
>>
>> Recently some discussions on IRC also highlighted the need for better reporting
>> of execbuf failure.
>> We have a number of bugs where execbuf fails after a number of hours running an
>> application or some random conditions and it's almost impossible to figure out
>> where the problem lies.
>> Having a way for i915 to report what validation the input parameters actually
>> fail would more helpful than EINVAL.
>>
>> Some of the virtual engine stuff could also fit in there but maybe the timeline
>> is too tight for that.
>>
>> We've added a i915_query mechanism that is easily extendable and after exposing
>> topology, it seems to be useful for adding other types of queries (engine
>> discovery, memory regions and the series in [2] also exposes performance query
>> configuration data).
>>
>> I would really like to see a similar mechanism for an execbuf3.
>> How can we help getting started in that direction?
>> Do people have a better idea?
> https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=execbuf3&id=11929f5262aa24ae7a80cf797c2d088eceeb6421
> -Chris
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Hey,

dma_fence_set_error() didn't accept 0 for a reason. This way if multiple places call
dma_fence_set_error we won't accidentally swallow an error if 1 sets it to 0 and
other to an error.

So just put it in an if (err) guard before calling. :)

~Maarten

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Time for execbuf3 ?

[Chris Wilson]

Quoting Lionel Landwerlin (2019-03-21 14:08:39)
> Mostly it's just about having the ability to extend it.
> I can't really tell you up front what we're going to need until we do :)

Yup. My takeaway is that the uAPI debugability is something that has
never been taken seriously (-EINVAL!). And that if we are going to design
an asynchronous interface with variable command packets, then we need a
better means for userspace to see which command went wrong and why. For
that, I think attaching a tracek ringbuf to the interface would be ideal.

Unless I can sell you on a validation layer in userspace :)

> Do you know when that work would start?

Optimistically, soon.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Time for execbuf3 ?

[Lionel Landwerlin]

On 21/03/2019 14:15, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-03-21 14:08:39)
>> Mostly it's just about having the ability to extend it.
>> I can't really tell you up front what we're going to need until we do :)
> Yup. My takeaway is that the uAPI debugability is something that has
> never been taken seriously (-EINVAL!). And that if we are going to design
> an asynchronous interface with variable command packets, then we need a
> better means for userspace to see which command went wrong and why. For
> that, I think attaching a tracek ringbuf to the interface would be ideal.
>
> Unless I can sell you on a validation layer in userspace :)


On the debugability side, I could be happy with being able to compile 
the submission part of i915 with Eric's new project : 
https://gitlab.freedesktop.org/anholt/drm-shim

Having another repository/codebase just for validation seems like more 
work, easily going out of sync with what's in i915.


>
>> Do you know when that work would start?
> Optimistically, soon.
> -Chris
>
Cool!


-Lionel

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Time for execbuf3 ?

[Chris Wilson]

Quoting Lionel Landwerlin (2019-03-22 11:36:35)
> On 21/03/2019 14:15, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-03-21 14:08:39)
> >> Mostly it's just about having the ability to extend it.
> >> I can't really tell you up front what we're going to need until we do :)
> > Yup. My takeaway is that the uAPI debugability is something that has
> > never been taken seriously (-EINVAL!). And that if we are going to design
> > an asynchronous interface with variable command packets, then we need a
> > better means for userspace to see which command went wrong and why. For
> > that, I think attaching a tracek ringbuf to the interface would be ideal.
> >
> > Unless I can sell you on a validation layer in userspace :)
> 
> 
> On the debugability side, I could be happy with being able to compile 
> the submission part of i915 with Eric's new project : 
> https://gitlab.freedesktop.org/anholt/drm-shim

Cool, I was thinking of something like "if we could recompile the kernel
validation logic in userspace that would avoid having to add a lot of
debug messages to the kernel". But I didn't realise that drm-shim could
help, ta.
 
> Having another repository/codebase just for validation seems like more 
> work, easily going out of sync with what's in i915.

Agreed.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx