• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 334 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/PROCESSOR-SDK-DRA8X-TDA4X: Floating point Precision issues in PC emulation mode

Jyoti Patil2
Intellectual 310 points
Part Number: PROCESSOR-SDK-DRA8X-TDA4X


Tool/software: TI C/C++ Compiler

Hi,

We are porting some vision algorithms on TDA4x c66x core and are using PSDK_06_01_01_12.
These modules are already running on a72 core in PC emulation and on EVM.
Now we are moving these modules to c66 core using TIOVX frame work.
We are observing some validation issues in some modules which specifically uses floating point values.
Our Understadning is that , for PC emulation on both environments, the modules should functionally execute the same and output should match.

The only difference we observed is that in the a72 PC emulation, the build is done using cmake and uses gcc 7.5 version, while the ported code uses TISDK based concerto built system with gcc 5.5 version.
We also tried importing gcc 5.5 version on a72 modules, but this did not help is validation.

Can you suggest any settings or compiler flags that need to be verified so as to ensure the floating point operations give similar results in both the environments.

Regards,

Jyoti Patil

  • 0
    TI__Expert 4725 points

    Hi, 

    It is tough to exactly bitmatch floating point algorithm on different compiler. Even for some compiler with different optimization setting it is possible that output may differ. Even though those differences will be minor, but that will result in output difference. Eventually you may aim for output quantitative accuracy measure than bit matching it. If some portion of algorithm needs more precision then you may consider portion of the module to be converted in double precision as well.

    In C66x compiler there is flag for avoiding reordering of floating operations that you can try, that will reduce these floating point computation difference. But it will not completely eliminate that.

    Regards

    Deepak Poddar

  • 0 in reply to Deepak Poddar
    Intellectual 310 points

    Hi Deepak,

    1. We are not doing binary match. We are actually dumping float values and checking the difference in precision.

    2. Coming to the 2 environments in which the module is running, they both compile using gcc 5.5 but the only difference we see is the c standards. One uses c11 standard which is our reference and the other uses c99 which is our PSDK.

    3. We were looking into c flags that can be set to reduce the precision loss. We have tried using the below flags, but it din't change the outputs even a bit:

    - ffloat-store

    - fexcess-precision=fast

    - ffp-contract=off

    4. We also explored that a flag  mfpmath=387 is by default used in c11 standard and is not set in c99 standard. I tried setting this flag in the PSDK. The results varied but din't match with the reference output.

    5. Regarding the flags for reordering of floating operations, we have found the following flags for the same:

    -fassociative-math

    -ffast-math and -ffloat-store

    Are these the flags you were talking about? Are these flags not set by default for c99 or c11 standards? Could you give us specific pointers.

    Regards,

    Jyoti Patil

  • 0 in reply to Jyoti Patil2
    TI__Expert 4725 points

    Hi,

    I initially got impression that you are trying to match C66x h/w output with PC output. But now I understood that you are trying to match two environments both having gcc 5.5 built but with different standards setting C99 and C11. I guess this difference is beyond TI's support scope.

    However high level I suggest that you may try to match the output around divisions in your algorithm. Divisions are the place where precision loss are more prominent. 

    regards

    Deepak Poddar