Jan Vesely <jan.ves...@rutgers.edu> writes: > 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. >
Wouldn't it be easier for Clover to check which libclc version it's linking against and expose a subset of language versions and extensions accordingly? That should only take a tiny bit of build system support and wouldn't lock us to a single libclc release per API version (which would make things tricky if extensions get back-ported by Khronos to older API versions after the fact, or if people have reasons to delay the implementation of a subset of extensions after a release). Either way, patch looks good to me: Reviewed-by: Francisco Jerez <curroje...@riseup.net> > Jan > > [SNIP] > -- > Jan Vesely <jan.ves...@rutgers.edu> > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
