[Intel-gfx] [Mesa-dev] [RFC 1/2] drm/i915: Engine discovery uAPI

[Tvrtko Ursulin]

On 19/04/2017 06:22, Kenneth Graunke wrote:
> On Tuesday, April 18, 2017 9:56:14 AM PDT Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>
>> Engine discovery uAPI allows userspace to probe for engine
>> configuration and features without needing to maintain the
>> internal PCI id based database.
>
> I don't understand why I would want to query the existence of engines
> from the kernel.  As a userspace driver developer, I have to know how to
> program the specific generation of hardware I'm on.  I better know what
> engines that GPU has, or else there's no way I can competently program it.
>
> In Mesa, we recently imported libdrm and deleted all the engine checks
> (a460e1eb51406e5ca54abda42112bfb8523ff046).  All generations have an
> RCS, Gen6+ has a separate BLT, and we don't need to use the others.
> It's completely statically determinable with a simple check.  Runtime
> checks make sense for optional things...but not "is there a 3D engine?".
>
> Plus, even if you add this to the kernel, we still support back to 3.6
> (and ChromeOS needs us to continue supporting 3.8), so we won't be able
> to magically use the new uABI - we'd need to support both.  Which, if
> the point is to delete code...we'd actually have /more/ code for a few
> years.  Or, we could not use it...but then nobody would be testing it,
> and if a bug creeps in...that pushes it back more years still.

Okay the argument of more code for a while is I suppose always true with 
these types of work. But in general, the idea is to consolidate the 
queries and avoid (may be only partially) duplicate PCI databases across 
components.

Because I suspect today you do some device discovery via libpciaccess 
(or something) and some via i915 GET_PARAMs and so. So the idea is to 
consolidate all that and do it via i915. Since another argument you 
raise, is that you have to know how does the GPU looks like to be able 
to competently program it, in which case who knows better than the 
kernel driver?

But I think the main part of the argument is that why collect and derive 
this information from various sources when perhaps it could only be one.

Maybe the exact idea is not so interesting for Mesa, which I wouldn't be 
surprised at all since the idea was born from libva and the BSD engine 
usage there. In which case perhaps Mesa could become more interested if 
the proposal was exporting some other data to userspace?

I don't think it is critical to find something like that in Mesa, but it 
may be interesting. I think Ben mentioned at one point he had some ideas 
in this area, or something was discussed in the past which may be 
similar. I forgot the exact details now.

So I think for now, if there is nothing which would be interesting in 
Mesa along the lines described so far, please just keep an eye on this. 
Just to make sure if some other component will be interested, and we end 
up starting to implement something, it is at least not hindering you, if 
we cannot find anything useful for you in here.

Regards,

Tvrtko