5 Replies Latest reply on Feb 1, 2011 8:47 AM by Meteorhead

    Documentation update

    Meteorhead
      for the good of all

      Dear those in charge!

      There has been a rather heated argument about undocumentation of environmental variables used by the SDK in one of the multi-gpu topics. This was because of the unannounced introduction of the GPU_USE_SYNC_OBJECTS variable from SDK 2.1 -> 2.2 .

      Anyhow, we were told documentation was pointed out to be a little more verbose about this topic (as opposing from us having to grep strings out of the runtime library). Renaming the SDK to APP and updating all the docs:

      http://developer.amd.com/gpu/AMDAPPSDK/assets/ATI_Stream_SDK_Release_Notes_Developer.pdf

      would've been the perfect time to solve this issue. Please include a short sub-chapter with all the actual environmental variables and a short (one sentence) explanation of what that certain variable does. We are aware that these variables are mostly temporary, but they are vital to us developers.

      We would appreciate if this would be a practice in all future SDKs also.

      Best regards,

      Máté

        • Documentation update
          zeland

          +1

          knowing issue too.

            • Documentation update
              nou

              some envioment variables are documented. like image support or more memory on GPU. on other AMD don't want that we use it.

                • Documentation update
                  Meteorhead

                  There is no problem with them not wanting us not to use them. If someone with relevant "power" states they don't document it becuase they do not want us to use them, I can understand that. But that will be the very moment I cease to use APP SDK alltogether, because I will not make the same mistake again. As a developer it is not my job to uncover such explicit changes in the SDK that have nothing to do with the OpenCL standard.

                  But I do not understand why they wouuld want us to avoid using them. If I were making a commercial product, it is in MY interest to avoid using variables that will become obsolete in two months time. I only use such variables when I know a feature is test phase only, but I wish to learn to use it, or when I have short term projects or I am developing for myself. I do not see which case is counter-productive from AMD's PoV.

                    • Documentation update
                      himanshu.gautam

                      Meteorhead,

                      Thanks for reporting these issues. Discussions are going on for this but currently it is evident that AMD do not expect any user to try the environment variables that are not documented anywhere. There have been issues about these env variables and they might hang or crash your system. More importantly we cannot guarantee that these will remain same in future as they might be dropped or there meaning might be altered.

                        • Documentation update
                          Meteorhead

                          It is good to hear that there are discussions about the issue. But if the cons are only the things you mentioned (crashing system, meaning changing over time), I still do not see why it cannot be inserted into the release notes:

                          "Compiler behavior can be altered through the following environmental variables. CAUTION! USE AT YOUR OWN RISK! Modifying these variables may result in undefined behavior, even system crash."

                          This way even experimental features could get widespread feedback and potentional bug reports. SDK developers surely cannot test all aspects of a newly implemented feature. There are many people who like to tweak with such things, just for kicks. For others, they are higly useful.