On Thu, Mar 05, 2015 at 08:42:25PM +0200, Francisco Jerez wrote: > Tom Stellard <[email protected]> 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_scalar<cl_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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
