On 11/10/2019 13:31, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-11 13:16:33)
[snip]
Looks fine in principle.
I am tempted to go with some of the engine->flags from the start but I
don't have an use case apart from saying that it sounds like it makes sense.
The problem I saw with engine->flags is that are mostly internal
details; the public parts become caps.scheduler. That seemed reasonable
to add, but where? cardN/scheduler (same level as cardN/engine)? But
there's a large overlap between that and the per-engine controls. So
cardN/engine/scheduler? Then the user has to remember that not all
entries are engines.
I suppose cardN/engine/all/ would fit the pattern of some other sysfs
interfaces [cardN/engine/all/scheduler/caps?] Only problem then is you
would reasonably expect to have some global controls :)
Preemption cap may make sense in conjunction with heartbeat interval to
tell userspace something more?
Busy_stats might make sense for people interested in doing perf stat?
What worries me slightly is not being able to tell if a cap is supported
just not exported, or not supported but exported, if you are able to
follow. :) Which would happen if we decided to later add something from
flags.
Along that path we end up with bcs0/available_flags and bcs0/flags (or
bcs0/available_capabilities and bcs0/capabilities). Or
cardN/engine/version?
available_capabilities sounds good enough and future proof.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
