Closed mborgerson closed 2 years ago
Looks like the new encoder is swapping B & R channels.
E.g., with this encoder:
But the correct output is
Looks like the new encoder is swapping B & R channels.
E.g., with this encoder:
But the correct output is
Oops
Looks like the new encoder is swapping B & R channels.
Fixed
Looks like the new encoder is swapping B & R channels.
Fixed
Thanks!
Can you double check that the new encoder is still faster with the swizzling? I just did a non-scientific comparison between this commit and the current main
branch and it seems about 50% slower to me when switching between tests (using the same xemu build, I haven't tested timing on HW yet).
Looks like the new encoder is swapping B & R channels.
Fixed
Thanks!
Can you double check that the new encoder is still faster with the swizzling? I just did a non-scientific comparison between this commit and the current
main
branch and it seems about 50% slower to me when switching between tests (using the same xemu build, I haven't tested timing on HW yet).
I must've had a dirty build; just did a clean build with this PR and it's noticeably faster, as expected.
Brings total runtime down considerably. Including all but your depth format tests, this brings runtime down to about a minute in xemu. With the depth format tests at around 3.5 min. The new image encoder basically cuts test time in half after optimizations are enabled. I'm sure there are several more improvement opportunities, but this gets the lowest hanging fruit. Another low fruit would be syncing with upstream nxdk and enabling LTO for possible improvements.
I have not tested on hardware.