From: IndecisiveTurtle <geoster3d@gmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v4 3/4] libavcodec/vulkan: Add modifications to common shader for VC2 vulkan encoder Date: Mon, 19 May 2025 20:02:21 +0300 Message-ID: <CAJpqCyJnsBvW3no8GoXgNE1WAzXR3WXQz3sO_7byDUXnXizakA@mail.gmail.com> (raw) In-Reply-To: <AS8P250MB0744BF4CA9798625192256768F9CA@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM> > This differs quite a lot from the software implementation: It does not > presume that the PutBitContext is flushed and instead of simply skipping > over the buffer it actually fills the buffer with n 0xFF bytes, > effectively adding the memset used in the VC2 slice writing code to > skip_put_bytes(). But this file is (if I am not mistaken) supposed to be > generic, not vc2 specific, so this feels very wrong. Would it be enough to move it to vc2_encode.comp or should I also rename the function? Στις Δευ 19 Μαΐ 2025 στις 7:46 μ.μ., ο/η Andreas Rheinhardt <andreas.rheinhardt@outlook.com> έγραψε: > > IndecisiveTurtle: > > From: IndecisiveTurtle <geoster3d@gmail.com> > > > > --- > > libavcodec/vulkan/common.comp | 54 ++++++++++++++++++++++++++++------- > > 1 file changed, 44 insertions(+), 10 deletions(-) > > > > diff --git a/libavcodec/vulkan/common.comp b/libavcodec/vulkan/common.comp > > index 10af9c0623..db216a2ac6 100644 > > --- a/libavcodec/vulkan/common.comp > > +++ b/libavcodec/vulkan/common.comp > > @@ -18,6 +18,9 @@ > > * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > > */ > > > > +#extension GL_EXT_buffer_reference : require > > +#extension GL_EXT_buffer_reference2 : require > > + > > layout(buffer_reference, buffer_reference_align = 1) buffer u8buf { > > uint8_t v; > > }; > > @@ -61,22 +64,20 @@ layout(buffer_reference, buffer_reference_align = 8) buffer u64buf { > > #define mid_pred(a, b, c) \ > > max(min((a), (b)), min(max((a), (b)), (c))) > > > > -/* TODO: optimize */ > > + > > uint align(uint src, uint a) > > { > > - uint res = src % a; > > - if (res == 0) > > - return src; > > - return src + a - res; > > + return (src + a - 1) & ~(a - 1); > > +} > > + > > +int align(int src, int a) > > +{ > > + return (src + a - 1) & ~(a - 1); > > } > > > > -/* TODO: optimize */ > > uint64_t align64(uint64_t src, uint64_t a) > > { > > - uint64_t res = src % a; > > - if (res == 0) > > - return src; > > - return src + a - res; > > + return (src + a - 1) & ~(a - 1); > > } > > > > #define reverse4(src) \ > > @@ -167,6 +168,39 @@ uint32_t flush_put_bits(inout PutBitContext pb) > > return uint32_t(pb.buf - pb.buf_start); > > } > > > > +void skip_put_bytes(inout PutBitContext pb, int n) > > +{ > > + int bytes_left = pb.bit_left >> 3; > > + if (n < bytes_left) > > + { > > + int n_bits = n << 3; > > + int mask = (1 << n_bits) - 1; > > + pb.bit_buf <<= n_bits; > > + pb.bit_buf |= mask; > > + pb.bit_left -= uint8_t(n_bits); > > + return; > > + } > > + if (pb.bit_left < BUF_BITS) > > + { > > + int mask = (1 << pb.bit_left) - 1; > > + pb.bit_buf <<= pb.bit_left; > > + pb.bit_buf |= mask; > > + u32vec2buf(pb.buf).v = BUF_REVERSE(pb.bit_buf); > > + pb.buf += BUF_BYTES; > > + n -= pb.bit_left >> 3; > > + } > > + int skip_dwords = n >> 2; > > + while (skip_dwords > 0) > > + { > > + u8vec4buf(pb.buf).v = u8vec4(0xFF); > > + pb.buf += 4; > > + skip_dwords--; > > + } > > + int skip_bits = (n & 3) << 3; > > + pb.bit_buf = (1 << skip_bits) - 1; > > + pb.bit_left = uint8_t(BUF_BITS - skip_bits); > > +} > > This differs quite a lot from the software implementation: It does not > presume that the PutBitContext is flushed and instead of simply skipping > over the buffer it actually fills the buffer with n 0xFF bytes, > effectively adding the memset used in the VC2 slice writing code to > skip_put_bytes(). But this file is (if I am not mistaken) supposed to be > generic, not vc2 specific, so this feels very wrong. > > > + > > void init_put_bits(out PutBitContext pb, u8buf data, uint64_t len) > > { > > pb.buf_start = uint64_t(data); > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2025-05-19 17:02 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-05-17 20:48 [FFmpeg-devel] [PATCH v4 1/4] libavcodec/vc2enc: Split out common functions between software and hardware encoders IndecisiveTurtle 2025-05-17 20:48 ` [FFmpeg-devel] [PATCH v4 2/4] libavcodec/vc2enc: Switch quant to int IndecisiveTurtle 2025-05-17 20:48 ` [FFmpeg-devel] [PATCH v4 3/4] libavcodec/vulkan: Add modifications to common shader for VC2 vulkan encoder IndecisiveTurtle 2025-05-19 16:46 ` Andreas Rheinhardt 2025-05-19 17:02 ` IndecisiveTurtle [this message] 2025-05-17 20:48 ` [FFmpeg-devel] [PATCH v4 4/4] lavc: implement a Vulkan-based VC-2 encoder Implements a Vulkan based dirac encoder. Supports Haar and Legall wavelets and should work with all wavelet depths IndecisiveTurtle 2025-05-17 20:50 ` IndecisiveTurtle 2025-05-19 17:09 ` Andreas Rheinhardt 2025-05-19 17:40 ` IndecisiveTurtle 2025-05-19 15:56 ` [FFmpeg-devel] [PATCH v4 1/4] libavcodec/vc2enc: Split out common functions between software and hardware encoders Andreas Rheinhardt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAJpqCyJnsBvW3no8GoXgNE1WAzXR3WXQz3sO_7byDUXnXizakA@mail.gmail.com \ --to=geoster3d@gmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git