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-packaged/#prebuilt-binaries-or-libraries and IMHO also not "content" in the context of the: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_impermissible_content 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-packaged/#pregenerated-code 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 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
