Optimizations and x86/amd64 SIMD for ubuf_pic_blit#1206
Open
JDarnley wants to merge 7 commits into
Open
Conversation
Take run count on the command line and repeatedly call ubuf_pic_blit for yuv422p and yuv422p10le pictures. Currently only tests threshold copy using alpha plane.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft waiting for #1205 and some comments
Moves the blit code out of the header and in to libupipe. That was done so I could add code for x86 without it sort of "polluting" everything that includes ubuf_pic.h. That means the code doesn't get inlined in places like upipe_blit. That might not be desirable.
The simd is intrinsics because I pictured it being inlined like previous work I have done for ubuf_pic_plane_set_color but gcc doesn't/can't inline functions built with different options. Different options given by function attributes are needed for the compiler (gcc) to be able to generate some instructions otherwise it causes a build error. At that point I wonder whether I should use external assembly to make that easier except the tails would still need to be scalar to avoid overwrites.
Also added a primitive benchmark for yuv422p and yuv422p10le 1920x1080 blits to see difference for the couple of cases I care about: threshold alpha copy. Speed up with avx2 is over 20 times for 8-bit and almost 10 times for 10-bit. I tried some avx512 code but it wasn't any faster on any of the cpus I had available so it is left out here.