[Mesa-dev] feature levels in clover (was: Re: [PATCH 2/2] clover: Query and export int64 atomics)

[Jan Vesely]

On Wed, 2017-09-20 at 19:10 -0500, Aaron Watry wrote:
> [SNIP]
> 
> Not trying to rain on your parade, but I've been thinking that we
> might need to be able to query the installed libclc version or
> possibly consider querying the libclc library for information about
> which extensions are implemented (possibly even for the specific
> device/target and the llvm version it was built against).
> 
> I've been slowly working on a printf implementation, and I'll need to
> expose that based on some dynamic state of the system as well.
> 
> For something that's adding new extension support in libclc, we might
> at least want to bump the libclc version number and ask Tom what he
> did in the past related to branching off a libclc release, and then
> make sure we've got a way to link against libclc (if we're not
> already) and get its version number.

I disagree.
Extensions need to be exposed by both clover (for host code) and clang
(for clc code), synchronizing those is tricky enough. adding two more
variables (libclc version, libclc clang build version) will make things
intractable.

It's a lot easier (and I'd say common) for applications to check for
extensions in CLC code (ifdef/ifndef) and handle all failures in
generic 'build failed' error path. That makes clang the authoritative
source of supported extensions for each target.
Ideally, clover would get the list of supported extensions from clang
(based on device target) and expose those.
clang has exposed almost all extensions since at least 3.9.
Implementing and exposing them (including int64 atomics) is thus a
bugfix, not a feature update.

I don't want to have libclc release until the library is complete (we
still miss ~12 builtins + variants). Distros now ship development
snapshot and providing a released version would make more
backward^Wconservative distros (ehm, debian) stuck on that version.
This way we have only one version; HEAD.

I have posted patches that bring back llvm-3.9 support to libclc, thus
everyone can use the latest libclcHEAD.

I agree that we need to differentiate libclc variants that follow
different version of standard. Not just because of missing features,
but because not all builtins should be exposed in all versions.
for example: atomic_* should not be available in clc1.0.
or the program can do something like this:
#ifndef extension
...custom implementation of extensions function
#else
#pragma extension: enable
#endif

I'd thus propose to add lang version suffix to libclc.
*.bc.cl100 -- follows OCL-1.0 (builtins added later are not available)
*.bc.cl110 -- follows OCL-1.1 (deprecated OCL-1.0 builtins/macros are
not available, buitlins from 1.2 are not available)
...
Current libclc would thus provide only .cl100 and .cl110 with missing
builtins/bugs.


It'd be possible for clover to check presence of such libraries and
restrict CLC (and CL) feature level accordingly.

Jan

[SNIP]
-- 
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170921/e74ae354/attachment.sig>