4 Replies Latest reply on Nov 10, 2009 5:07 PM by bubu

    cl.hpp improvements

    bubu

      Could be possible to add two things to the cl.hpp, pls?

       

      1) Detect the OpenCL.dll. Delay Load DLL is not enough. We need a method to detect if the OpenCL.dll is present on the system because, if not, any cl:evice or cl:latform will cause an ugly "Sorry, this program cannot find the module OpenCL.dll".

      For windows, detect the Windows\system32\OpenCL.dll presency...

      For linux/macos/solaris, I don't know

       

      2) We need a way to see if the GPU is actually the primary display... so we can skip that card due to the 5 seconds watchdog or whatever. Just add a new CL_GPU_IS_PRIMARY_DISPLAY to the cl:evice.

       

      thx

        • cl.hpp improvements
          nou

          1.this will solve ICD from khronos. nvidia it support. i hope next beta from AMD it will support too.

          2. that is request for khronos add this to specification. for now make choose device manualy.

            • cl.hpp improvements
              bubu

               

              Originally posted by: nou 1.this will solve ICD from khronos. nvidia it support. i hope next beta from AMD it will support too.

              Not really. In fact, I'm getting that error from the NVIDIA SDK

              Some OSs have no native OpenCL support ( just Leopard has it atm ). The point is that even with an ICD the user could use a old driver, much older than the OpenCL specification... so any call to the OpenCL API will cause a missing module DLL message.

              I simply cannot suppose there gonna exist an OpenCL.dll in the system folder.... The cl.hpp should include a function for this.

               

              2. that is request for khronos add this to specification. for now make choose device manualy.

               

              I hope ATI could tell Khronos about the CL_IS_PRIMARY_DEVI CE cap... because I cannot and the watchdog is really a pain.

               

              Other thing they should add is a CL_OPTIMAL_WORKGROUP_SIZE so we can get a range of optimal working sizes... because I could asume a good group size is 256x256 threads now but perhaps it's 2048x2048 in two years... or 16x16... We need a way to know thins since each OpenCL device can be a completely different world!

                • cl.hpp improvements
                  Sternenprinz

                  What is the problem with delayed-loading?

                  1) Your App will run, with or without any OpenCL.dll present

                  2) If loading fails, your App can do whatever it wants to (crashing, presenting a dialog, exiting graceful, doing something else...)

                  An ICD wont help you much if there is simply no OpenCL.dll

                    • cl.hpp improvements
                      bubu

                       

                      1) Your App will run, with or without any OpenCL.dll present

                      Tell that to Visual Studio, which closes the program automatically if a DLL is not found.

                       

                       

                      2) If loading fails, your App can do whatever it wants to (crashing, presenting a dialog, exiting graceful, doing something else...)

                      Nope. It just closes after showing an horrible message dialog.