A few clover fixes for both CTS and eventual 1.2 support

Submitted by Aaron Watry on July 31, 2017, 1:26 a.m.

Details

Reviewer None
Submitted July 31, 2017, 1:26 a.m.
Last Updated March 1, 2018, 7:39 p.m.
Revision 2

Cover Letter(s)

Revision 1
      I've dropped the first patch of the previous series for now. I'm not
withdrawing it completely, just going to see if there's anything about
the user_ptr stuff that could have been causing the issue instead, and
if I'm using too big a hammer in this patch. If I convince myself of its
correctness, it'll be back.

The rest of the patches move the device version declaration to core/device
and then use that along with the -cl-std option to determine which
OpenCL language version to enable in clang.

I've done a full piglit run (again) before/after, and there are no changes
for me on radeonsi/pitcairn if the device is left at CL 1.1.

When I bump my platform/device versions to 1.2, the clang instance has
been confirmed to enable 1.2 language features (like the static keyword
required in test/cl/program/execute/static.cl, which goes skip->pass).

Major changes since v1:
  Addressed Pierre's build-breakage comments
  Added a check for cl-std > device_clc_version
  Added a patch to pass the device object down into invocation.cpp
    instead of adding a bunch of device-based arguments.
  Use device_clc_version for cl version detection instead of device_version
  Added device_clc_version in device.cpp/hpp

Anyway, happy reviewing.

Cc: Jan Vesely <jan.vesely@rutgers.edu>
Cc: Pierre Moreau <pierre.morrow@free.fr>
    
Revision 2
      The first two patches of the previous series [1] landed upstream a while back.

When I bump my platform/device versions to 1.2, the clang instance has
been confirmed to enable 1.2 language features (like the static keyword
required in test/cl/program/execute/static.cl, which goes skip->pass), while
building a program with -cl-std=CL1.1 still leaves the 1.2 features disabled.

I've also updated my clover platform version to 2.2 and device version to
2.0 and verified that I see expected behavior when specifying a -cl-std of:
  1.0 - Invalid build options error (-cl-std=CL1.0 isn't valid).
  1.1 - Build proceeds with version 1.1
  1.2 - Build proceeds with version 1.2
  2.0 - Build proceeds with version 2.0
  2.1 - Invalid build options error
  2.2 - Invalid build options error

Changes since version 2:
  - Squashed several patches together as Pierre suggested and tried to avoid
    introducing and then changing API in later patches
  - Enable the -cl-std and __OPENCL_VERSION__ changes at the same time
  - Remove switch statements for version detection and created an array of
    struct cl_version with several attributes instead that can be matched on.
    Seems a lot cleaner that way (to me).

Major changes since v1:
  Addressed Pierre's build-breakage comments
  Added a check for cl-std > device_clc_version
  Added a patch to pass the device object down into invocation.cpp
    instead of adding a bunch of device-based arguments.
  Use device_clc_version for cl version detection instead of device_version
  Added device_clc_version in device.cpp/hpp

Anyway, happy reviewing.

Cc: Jan Vesely <jan.vesely@rutgers.edu>
Cc: Pierre Moreau <pierre.morrow@free.fr>
Cc: Francisco Jerez <currojerez@riseup.net>


1 - https://lists.freedesktop.org/archives/mesa-dev/2017-July/164699.html
    

Revisions