Differential D16317
Color Management: Parallelize ImBuf conversion to float Authored by Lukas Stockner (lukasstockner97) on Oct 22 2022, 4:55 AM.
Details Motivated by long loading times in T101969, reduces render preparation time from 14sec to 6sec. Another possible improvement would be to use C++ and template based on OCIO vs. sRGB,
Diff Detail
Event TimelineComment Actions Calling ocio once per pixel the just calling overhead will eat you alive ocio surely must have some buffered variants we could call? Comment Actions Surprisingly, OCIO_cpuProcessorApply is slower than the current version, even when applying it in 32-scanline blocks. I'm getting 5.92sec with P3271, compared to 5.43sec with the current version here. Comment Actions This is strictly better than what we were doing before so I think this can be committed. Would be good to understand why it's slower for bigger blocks though, if it's something in our C wrapper or in OpenColorIO. It's not obvious to me from checking the code. Comment Actions My best guess would be caching - this version does all processing steps on one pixel, while the other version loops over the entire image multiple times and therefore has to load/store each pixel to memory every time. Comment Actions Maybe doing it in smaller blocks would be faster then, but may need to avoid the memory allocation from OCIO_createOCIO_PackedImageDesc somehow then. Whatever the cause, not a blocker for this commit to land. |