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

[Tom Stellard]

On Thu, Mar 05, 2015 at 08:42:25PM +0200, Francisco Jerez wrote:
> Tom Stellard <thomas.stellard at 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_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
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev