[Mesa-dev] [PATCH] HUD: Add support for block I/O, network I/O and lmsensor stats

Emil Velikov emil.l.velikov at gmail.com
Tue Sep 13 13:02:42 UTC 2016


On 13 September 2016 at 13:07, Steven Toth <stoth at kernellabs.com> wrote:
>> On 12 September 2016 at 19:33, Steven Toth <stoth at kernellabs.com> wrote:
>>> Three new features:
>>> 1. Disk/block I/O device read/write stats MB/ps.
>>> 2. Network Interface RX/TX transfer statistics as a percentage
>>>    of the overall NIC speed.
>>> 3. lmsensor power, voltage and temperature sensors.
>>>
>> I'm not sure if these should be in the driver itself. In practise
>> these do not have direct (co-)relation to the performance and/or
>> experience thus they may be better suited in separate project(s).
>
> Emil, thank you for your feedback.
>
> Here's the rationale for including these into Mesa; Please forgive me
> if you area already familiar with this platform. The Freescale IMX
> platforms (ARM Video SOC) have a common (limited) memory bus that gets
> used and shared for a mix of things, including networking, video
> pipelines, scalers, encoders, decoders, audio etc. We're doing
> significant system profiling in a number of typical use cases,
> multiple H264 decodes out to display surfaces, through scalers, also
> while stressing the network and I/O subsystems. The merit and priority
> of these subsystems (their priority on the memory bus) are managed by
> the SOC itself, but can be tuned a little.
>
> Moving and adjusting performance in one area (I/O) often has
> significant performance changes to other subsystems, resulting in poor
> decoding, poor FPS, terrible network I/O etc. We're pushing the SOC to
> its outer limits. Being able to have all of these stats in one place,
> at one time, in the UI, is a big benefit - and I suspect will be for
> many other embedded SOC architectures.
>
> Hopefully, this explanation helps support my justification for the
> additional HUD stats.
>
Thanks for the comprehensive explanation Steven. Completely forgot
about the fun one can have with embedded devices :-P

As you gave the Freescale IMX as an example, would that mean you'll be
co-working with the Etnaviv devs or you're thinking/working on older
devices/closed source driver.

>>
>> That said, if people prefer to have this in mesa let's have it as a
>> configure toggle. This way people can opt for/against
>> --enable-gallium-extra-hud, default disabled.
>>
>> By doing so (the non-unix build don't use autoconf), you'll get
>> Brian's request by default ;-).
>
> :) I'm OK with this.
>
> I have zero experience with Windows Mesa builds. I'll take your word for it.
>
If in doubt - github has a nice integration with appveyor. Just push a
branch to the former and the latter will email you a nice report.

Note: doing any of this is not a requirement.

>>
>> Feel free to improve on the configure toggle name(s).
>>
>>> @@ -871,6 +872,17 @@ AC_ARG_ENABLE([dri],
>>>      [enable_dri="$enableval"],
>>>      [enable_dri=yes])
>>>
>>> +#PKG_CHECK_MODULES([LIBSENSORS], [libsensors >= $LIBSENSORS_REQUIRED], [enable_lmsensors=yes], [enable_lmsensors=no])
>>
>> Yay libsensors/lmsensors does not have a .pc file :-) Please add a
>> comment - be that XXX/TODO/NOTE or alike.
>
> Correct. No pc. I'll add a comment.
>
>>
>> As a fall-back, set the LIBSENSORS_{CFLAGS,LIBS} here and use both of
>> those throughout.
>
> OK
>
> Thanks again.
>
You're welcome and please don't let my 'lack of interest' deter you.
There's plenty of people who are glad to see/use your work.

-Emil


More information about the mesa-dev mailing list