Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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".

  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