Re: [Mesa-dev] [PATCH] clover: Return the minimum required value for CL_DEVICE_SINGLE_FP_CONFIG

2015-03-06 Thread Francisco Jerez
Tom Stellard t...@stellard.net writes:

 On Thu, Mar 05, 2015 at 08:42:25PM +0200, Francisco Jerez wrote:
 Tom Stellard thomas.stell...@amd.com writes:
 
  This means dropping CL_FP_DENORM from the current return value.
  ---
   src/gallium/state_trackers/clover/api/device.cpp | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
 
  diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
  b/src/gallium/state_trackers/clover/api/device.cpp
  index b1f556f..db3b931 100644
  --- a/src/gallium/state_trackers/clover/api/device.cpp
  +++ b/src/gallium/state_trackers/clover/api/device.cpp
  @@ -201,8 +201,10 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info 
  param,
 break;
   
  case CL_DEVICE_SINGLE_FP_CONFIG:
  +  // This is the mandated minimum single precision floating-point
  +  // capability
 
 Could you add that this is according to the OpenCL 1.1 specification?
 OpenCL 1.2 is even weaker (CL_FP_INF_NAN is not required, only one of
 CL_FP_ROUND_TO_ZERO or CL_FP_ROUND_TO_NEAREST is required, and no FP
 capabilities at all are required for custom devices as Jan pointed out).
 
 buf.as_scalarcl_device_fp_config() =
  - CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
  + CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
 
 I'm okay with this change, but I'm curious, is this motivated by your
 architecture not supporting denorms?
 

 It can, but supporting them hurts performance.

Sounds like you want to advertise denorm support and rely on the
-cl-denorms-are-zero compiler option to decide whether to flush them to
zero or not?

 -Tom

 break;
   
  case CL_DEVICE_DOUBLE_FP_CONFIG:
  -- 
  2.0.4




 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] clover: Return the minimum required value for CL_DEVICE_SINGLE_FP_CONFIG

2015-03-06 Thread Tom Stellard
On Thu, Mar 05, 2015 at 08:42:25PM +0200, Francisco Jerez wrote:
 Tom Stellard thomas.stell...@amd.com writes:
 
  This means dropping CL_FP_DENORM from the current return value.
  ---
   src/gallium/state_trackers/clover/api/device.cpp | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
 
  diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
  b/src/gallium/state_trackers/clover/api/device.cpp
  index b1f556f..db3b931 100644
  --- a/src/gallium/state_trackers/clover/api/device.cpp
  +++ b/src/gallium/state_trackers/clover/api/device.cpp
  @@ -201,8 +201,10 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info 
  param,
 break;
   
  case CL_DEVICE_SINGLE_FP_CONFIG:
  +  // This is the mandated minimum single precision floating-point
  +  // capability
 
 Could you add that this is according to the OpenCL 1.1 specification?
 OpenCL 1.2 is even weaker (CL_FP_INF_NAN is not required, only one of
 CL_FP_ROUND_TO_ZERO or CL_FP_ROUND_TO_NEAREST is required, and no FP
 capabilities at all are required for custom devices as Jan pointed out).
 
 buf.as_scalarcl_device_fp_config() =
  - CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
  + CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
 
 I'm okay with this change, but I'm curious, is this motivated by your
 architecture not supporting denorms?
 

It can, but supporting them hurts performance.

-Tom

 break;
   
  case CL_DEVICE_DOUBLE_FP_CONFIG:
  -- 
  2.0.4




 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] clover: Return the minimum required value for CL_DEVICE_SINGLE_FP_CONFIG

2015-03-06 Thread Matt Arsenault

 On Mar 6, 2015, at 8:56 AM, Francisco Jerez curroje...@riseup.net wrote:
 
 Tom Stellard t...@stellard.net mailto:t...@stellard.net writes:
 
 On Thu, Mar 05, 2015 at 08:42:25PM +0200, Francisco Jerez wrote:
 Tom Stellard thomas.stell...@amd.com writes:
 
 This means dropping CL_FP_DENORM from the current return value.
 ---
 src/gallium/state_trackers/clover/api/device.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
 b/src/gallium/state_trackers/clover/api/device.cpp
 index b1f556f..db3b931 100644
 --- a/src/gallium/state_trackers/clover/api/device.cpp
 +++ b/src/gallium/state_trackers/clover/api/device.cpp
 @@ -201,8 +201,10 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info 
 param,
   break;
 
case CL_DEVICE_SINGLE_FP_CONFIG:
 +  // This is the mandated minimum single precision floating-point
 +  // capability
 
 Could you add that this is according to the OpenCL 1.1 specification?
 OpenCL 1.2 is even weaker (CL_FP_INF_NAN is not required, only one of
 CL_FP_ROUND_TO_ZERO or CL_FP_ROUND_TO_NEAREST is required, and no FP
 capabilities at all are required for custom devices as Jan pointed out).
 
   buf.as_scalarcl_device_fp_config() =
 - CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
 + CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
 
 I'm okay with this change, but I'm curious, is this motivated by your
 architecture not supporting denorms?
 
 
 It can, but supporting them hurts performance.
 
 Sounds like you want to advertise denorm support and rely on the
 -cl-denorms-are-zero compiler option to decide whether to flush them to
 zero or not?

This is true for newer devices which have more instructions as fast with 
denormal support. For the currently supported devices, the performance 
difference is quite extreme and the denormal support is not that useful.





 
 -Tom
 
   break;
 
case CL_DEVICE_DOUBLE_FP_CONFIG:
 -- 
 2.0.4
 
 
 
 
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] clover: Return the minimum required value for CL_DEVICE_SINGLE_FP_CONFIG

2015-03-05 Thread Matt Arsenault

 On Mar 5, 2015, at 10:42 AM, Francisco Jerez curroje...@riseup.net wrote:
 
 Could you add that this is according to the OpenCL 1.1 specification?
 OpenCL 1.2 is even weaker (CL_FP_INF_NAN is not required, only one of
 CL_FP_ROUND_TO_ZERO or CL_FP_ROUND_TO_NEAREST is required, and no FP
 capabilities at all are required for custom devices as Jan pointed out).

This should come from a device check then. The weakest is a reasonable default, 
but it shouldn’t be removed from devices which do support CL_FP_INF_NAN


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] clover: Return the minimum required value for CL_DEVICE_SINGLE_FP_CONFIG

2015-03-05 Thread Tom Stellard
This means dropping CL_FP_DENORM from the current return value.
---
 src/gallium/state_trackers/clover/api/device.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index b1f556f..db3b931 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -201,8 +201,10 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_SINGLE_FP_CONFIG:
+  // This is the mandated minimum single precision floating-point
+  // capability
   buf.as_scalarcl_device_fp_config() =
- CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
+ CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
   break;
 
case CL_DEVICE_DOUBLE_FP_CONFIG:
-- 
2.0.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] clover: Return the minimum required value for CL_DEVICE_SINGLE_FP_CONFIG

2015-03-05 Thread Jan Vesely
On Thu, 2015-03-05 at 14:34 +, Tom Stellard wrote:
 This means dropping CL_FP_DENORM from the current return value.
 ---
  src/gallium/state_trackers/clover/api/device.cpp | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
 b/src/gallium/state_trackers/clover/api/device.cpp
 index b1f556f..db3b931 100644
 --- a/src/gallium/state_trackers/clover/api/device.cpp
 +++ b/src/gallium/state_trackers/clover/api/device.cpp
 @@ -201,8 +201,10 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
break;
  
 case CL_DEVICE_SINGLE_FP_CONFIG:
 +  // This is the mandated minimum single precision floating-point
 +  // capability

OCL 1.2 adds: for devices that are not of type CL_DEVICE_TYPE_CUSTOM

Reviewed-by: Jan Vesely jan.ves...@rutgers.edu

buf.as_scalarcl_device_fp_config() =
 - CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
 + CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
break;
  
 case CL_DEVICE_DOUBLE_FP_CONFIG:


-- 
Jan Vesely jan.ves...@rutgers.edu


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] clover: Return the minimum required value for CL_DEVICE_SINGLE_FP_CONFIG

2015-03-05 Thread Francisco Jerez
Tom Stellard thomas.stell...@amd.com writes:

 This means dropping CL_FP_DENORM from the current return value.
 ---
  src/gallium/state_trackers/clover/api/device.cpp | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
 b/src/gallium/state_trackers/clover/api/device.cpp
 index b1f556f..db3b931 100644
 --- a/src/gallium/state_trackers/clover/api/device.cpp
 +++ b/src/gallium/state_trackers/clover/api/device.cpp
 @@ -201,8 +201,10 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
break;
  
 case CL_DEVICE_SINGLE_FP_CONFIG:
 +  // This is the mandated minimum single precision floating-point
 +  // capability

Could you add that this is according to the OpenCL 1.1 specification?
OpenCL 1.2 is even weaker (CL_FP_INF_NAN is not required, only one of
CL_FP_ROUND_TO_ZERO or CL_FP_ROUND_TO_NEAREST is required, and no FP
capabilities at all are required for custom devices as Jan pointed out).

buf.as_scalarcl_device_fp_config() =
 - CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
 + CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;

I'm okay with this change, but I'm curious, is this motivated by your
architecture not supporting denorms?

break;
  
 case CL_DEVICE_DOUBLE_FP_CONFIG:
 -- 
 2.0.4


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev