On Tue, 07 Mar 2023 12:16:10 -0800, Umesh Nerlige Ramappa wrote: > Hi Umesh, > One or more engines map to a specific OA unit. All reports from these > engines are captured in the OA buffer managed by this OA unit. > > Current i915 OA implementation supports only the OAG unit. OAG primarily > caters to render engine, so i915 OA uses render as the default engine > in the OA implementation. Since there are more OA units on newer > hardware that map to other engines, allow user to pass engine class and > instance to select and program specific OA units. I believe there is another uapi issue to be resolved here: how the engines are associated with OA units, since from the point of view of the uapi there are multiple engines and multiple OA units (even if in the actual implementation at present there is only one OA unit per gt). In the internal tree we had added oa_unit_id to engine_info for this. So if multiple engines had the same oa_unit_id, user could pass class:instance of any of those engines to get oa data from that OA unit (and generally know how engines are hooked up to OA units (the OA unit topology)). So the question is even if we don't implement it as part of this series (or do we have to?) do we at least need to agree to that uapi which will be used to associate OA units with engines? Thanks. -- Ashutosh
