2 Replies Latest reply on Nov 19, 2009 12:39 AM by hazeman

    Partial support for OpenCL on RV6xx

    hazeman
      Is it really impossible ?

      For some time now we are told that RV6xx is missing hardware capabilities to support OpenCL. But is it really true ?

      If you want full OpenCL unfortunatelly it's true. But not every program needs full OpenCL. Usually only small subset of the language is required ( like for matrix multiplication, vector addition , etc ).

      So lets consider if RV6xx can support some part of OpenCL.

      RV6xx doesn't have compute shaders. It means that we can't give any NDRange ( work items index space ). Our NDRange is defined by output buffer size.

      1. So we have first restriction here - NDRange == dimension & size of output buffer. This is usually the case when we do classical stream computing ( convert one stream into another - as in brook ).

      2. Second limitation is that we can't request any local work group size - the driver makes decision here.

      3. Reads from memory must use texture unit. We can't write to read buffers ( it implies that kernel must have const pointers to read buffers ).

      4. Writes to output buffer must follow pattern

      out[gloval_id(0)] = value; ( for 1D )

      out[global_id(1)*out_width + global_id(0)] = value; ( for 2D )

      5. We can't use local memory ( missing on RV6xx ).

      So on device side we have kernels which are restricted to the form:

      void kernel( const global floatx* input1 [, const global floatx* inputx], global floatx* output1 [, global floatx* outputx], floatx,intx variables ( not pointers ) )

      {

          // can't use local_id, local_size

          // only global_id, global size available

         ... computations and memory read buffer access here ...

         output1[ global_id(1)*output_width + global_id(0)] = value; // 2D case

         // up to 8 outputs

      }

      such a kernel can be compilled into pixel shader. Kernels not matching this pattern should give compilation error on RV6xx.

      On the host side we have limitation that NDRange given to kernel invocation must be as the same as output buffer size. ( there is some technical problem of opencl buffer not having 2D size, but it can be easilly solved by small extension to cal ).

       

      So as we see some part of OpenCL can be supported on RV6xx. Now you can decide for yourself whether this model is sufficient for your work or not.

      Personally i think that AMD/ATI should implement this. It is logical extension of Brook framework ( connecting old with new ). Also it would be nice gesture from AMD/ATI towards people with older cards.

       

        • Partial support for OpenCL on RV6xx
          MicahVillmow
          hazeman,
          I don't want to go into all of the details of why this is not possible, but base OpenCL support is an all or nothing proposition. It is not possible to have a partial OpenCL implementation and still be able to call it OpenCL. More information can be found here: http://www.khronos.org/opencl/adopters/ There is no reasonable way that RV6XX series of cards can pass conformance and thus AMD cannot support OpenCL on them. The important point i'll repost here, "the OpenCL API must be tested for conformance in the Khronos OpenCL Adopters program before the OpenCL name or logo may be used in association with an implementation of the API."
            • Partial support for OpenCL on RV6xx
              hazeman

               

              Originally posted by: MicahVillmow hazeman, I don't want to go into all of the details of why this is not possible, ...


              This "reduced opencl" is almost conversion of Brook to new syntax. If Brook is possible then this is also possible. If you have any valid argument why this is not so please don't hesitate to post it here.

               

               

              ... but base OpenCL support is an all or nothing proposition. It is not possible to have a partial OpenCL implementation and still be able to call it OpenCL.


              So don't call it OpenCL. Name it OpenRCL ( reduced CL ), or brook_converted_to_opencl, or Bob. I think for most people here functionality is more important than name.

              To tell you the truth I really don't like bad quality PR talk, specially if it's not on the thread subject. I really understand that without OpenCL name and logo you can't use it to advertise your products. But don't give this as a reason to why it can't be done - it only means you don't want to do it.