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@xxxxxxxxx>
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
