Pre-Generated Binaries for Perforance from Upstream

[Tim Flink]

I have another question about the review of miopen [1][2] but this time it's about the upstream's use of pre-generated binary files.

The miopen upstream includes many compressed binaries (pretty much one per supported GPU architecture) which, according to their documentation, are tuning values meant to give its auto-tuning feature a good place to start from [3] in order to boost initial performance. As I write this, there is not a fully documented way to generate those tuning values at build time but we could just not include those tuning values if we accept the performance hit that would entail. A ticket has been filed upstream asking for an alternative to using the pre-built binary files [4] which has explained some of the process.

My question is: do these binary files fall into the category of "If the content enhances the OS user experience, then the content is OK to be packaged in Fedora."?

At the moment, my assumption is that the binary files are not allowed if the build process is not completely documented. If the build process is documented, they could be allowed but building/optimizing from scratch at package build time would be preferred.

I would appreciate insight that folks may have.

Thanks,

Tim

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2261201
[2] https://github.com/ROCm/MIOpen
[3] https://github.com/ROCm/MIOpen/blob/develop/docs/perfdatabase.md
[4] https://github.com/ROCm/MIOpen/issues/2742

[Daniel P. Berrangé]

On Fri, Feb 16, 2024 at 03:37:37PM -0700, Tim Flink wrote:
> I have another question about the review of miopen [1][2] but this
> time it's about the upstream's use of pre-generated binary files.
>
> The miopen upstream includes many compressed binaries (pretty much
> one per supported GPU architecture) which, according to their
> documentation, are tuning values meant to give its auto-tuning
> feature a good place to start from [3] in order to boost initial
> performance. As I write this, there is not a fully documented way
> to generate those tuning values at build time but we could just
> not include those tuning values if we accept the performance hit
> that would entail. A ticket has been filed upstream asking for
> an alternative to using the pre-built binary files [4] which has
> explained some of the process.
>
> My question is: do these binary files fall into the category of
> "If the content enhances the OS user experience, then the content
> is OK to be packaged in Fedora."?
>
> At the moment, my assumption is that the binary files are not
> allowed if the build process is not completely documented. If
> the build process is documented, they could be allowed but
> building/optimizing from scratch at package build time would
> be preferred.
>
> I would appreciate insight that folks may have.

AFAICT, these binary files are compressed sqlite databases. Taking
a single database (gfx900_56.db.bz2), I see just two tables with a
tonne of tunable values.

These are not binaries in the context of

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packag...

and IMHO also not "content" in the context of the:

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packag...

To me the binary nature of these files is largely tangential, it was
just a convenient data format upstream chose. They are essentially
"just" configuration files for the software, providing a varity of
defaults for different hardware. That they chose sqlite instead of
plain text is fine and this choice has no bearing on whether it is
permissible in Fedora pacakges.

There is a question of whether these files can be 100% automatically
generated. The comment in the upstream ticket:

"If you know the convolution configs that will be used
    in your systems,.."

strongly suggests these cannot be 100% auto-generated - they require
external human domain knowledge of each hardware target to be input.

*If* upstream had kept a record of these human provided inputs in a
script/makefile/etc, convolution configs, for each platform, then
there could be an argument for that being the preferred source form,
and thus push towards re-generation. The ticket suggests such a record
does not exist, and as such  the sqlite files are effectively the
preferred source form for upstream.

In any case, per:

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packag...

Fedora merely suggests, but does not require you to re-generate "code"
during package build.

Overall I think it is acceptable to package these DB configuration files
as is.

With regards,
Daniel