* [FFmpeg-devel] [PATCH] vulkan_decode: do not align the image dimensions
@ 2023-05-29 2:08 Lynne
2023-05-29 3:11 ` Philip Langdale
0 siblings, 1 reply; 3+ messages in thread
From: Lynne @ 2023-05-29 2:08 UTC (permalink / raw)
To: Ffmpeg Devel
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
According to Dave Airlie:
> <airlied> but I think ignoring it should be fine, I can't see any
> other way to get the imaeg extents correct for other usage
> <Lynne> what width/height should be used for the images?
> the final presentable dimensions, or the coded dimensions?
> <airlied> if you don't want noise I think the presentable dims
> <airlied> the driver should round up the allocations internally,
> but if you are going to sample from the images then w/h have to be
> the bounds of the image you want
> <airlied> since otherwise there's no way to stop the sampler from
> going outside the edges
[-- Attachment #2: 0001-vulkan_decode-do-not-align-the-image-dimensions.patch --]
[-- Type: text/x-diff, Size: 3824 bytes --]
From ce6aa64eacfc9f7881571450a7bf8192c776f0ec Mon Sep 17 00:00:00 2001
From: Lynne <dev@lynne.ee>
Date: Mon, 29 May 2023 03:50:25 +0200
Subject: [PATCH] vulkan_decode: do not align the image dimensions
According to Dave Airlie:
> <airlied> but I think ignoring it should be fine, I can't see any
> other way to get the imaeg extents correct for other usage
> <Lynne> what width/height should be used for the images?
> the final presentable dimensions, or the coded dimensions?
> <airlied> if you don't want noise I think the presentable dims
> <airlied> the driver should round up the allocations internally,
> but if you are going to sample from the images then w/h have to be
> the bounds of the image you want
> <airlied> since otherwise there's no way to stop the sampler from
> going outside the edges
---
libavcodec/vulkan_decode.c | 18 +++++++-----------
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/libavcodec/vulkan_decode.c b/libavcodec/vulkan_decode.c
index 6138106fef..0acfb93aa0 100644
--- a/libavcodec/vulkan_decode.c
+++ b/libavcodec/vulkan_decode.c
@@ -702,7 +702,6 @@ static VkResult vulkan_setup_profile(AVCodecContext *avctx,
}
static int vulkan_decode_get_profile(AVCodecContext *avctx, AVBufferRef *frames_ref,
- int *width_align, int *height_align,
enum AVPixelFormat *pix_fmt, VkFormat *vk_fmt,
int *dpb_dedicate)
{
@@ -841,10 +840,10 @@ static int vulkan_decode_get_profile(AVCodecContext *avctx, AVBufferRef *frames_
" separate_references" : "");
/* Check if decoding is possible with the given parameters */
- if (avctx->coded_width < caps->minCodedExtent.width ||
- avctx->coded_height < caps->minCodedExtent.height ||
- avctx->coded_width > caps->maxCodedExtent.width ||
- avctx->coded_height > caps->maxCodedExtent.height)
+ if (avctx->width < caps->minCodedExtent.width ||
+ avctx->height < caps->minCodedExtent.height ||
+ avctx->width > caps->maxCodedExtent.width ||
+ avctx->height > caps->maxCodedExtent.height)
return AVERROR(EINVAL);
if (!(avctx->hwaccel_flags & AV_HWACCEL_FLAG_IGNORE_LEVEL) &&
@@ -956,8 +955,6 @@ static int vulkan_decode_get_profile(AVCodecContext *avctx, AVBufferRef *frames_
*pix_fmt = best_format;
*vk_fmt = best_vkfmt;
- *width_align = caps->pictureAccessGranularity.width;
- *height_align = caps->pictureAccessGranularity.height;
*dpb_dedicate = dec->dedicated_dpb;
return 0;
@@ -966,7 +963,7 @@ static int vulkan_decode_get_profile(AVCodecContext *avctx, AVBufferRef *frames_
int ff_vk_frame_params(AVCodecContext *avctx, AVBufferRef *hw_frames_ctx)
{
VkFormat vkfmt;
- int err, width_align, height_align, dedicated_dpb;
+ int err, dedicated_dpb;
AVHWFramesContext *frames_ctx = (AVHWFramesContext*)hw_frames_ctx->data;
AVVulkanFramesContext *hwfc = frames_ctx->hwctx;
FFVulkanDecodeContext *dec = avctx->internal->hwaccel_priv_data;
@@ -983,14 +980,13 @@ int ff_vk_frame_params(AVCodecContext *avctx, AVBufferRef *hw_frames_ctx)
prof = &ctx->profile_data;
err = vulkan_decode_get_profile(avctx, hw_frames_ctx,
- &width_align, &height_align,
&frames_ctx->sw_format, &vkfmt,
&dedicated_dpb);
if (err < 0)
return err;
- frames_ctx->width = FFALIGN(avctx->coded_width, width_align);
- frames_ctx->height = FFALIGN(avctx->coded_height, height_align);
+ frames_ctx->width = avctx->width;
+ frames_ctx->height = avctx->height;
frames_ctx->format = AV_PIX_FMT_VULKAN;
hwfc->format[0] = vkfmt;
--
2.40.1
[-- Attachment #3: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [FFmpeg-devel] [PATCH] vulkan_decode: do not align the image dimensions
2023-05-29 2:08 [FFmpeg-devel] [PATCH] vulkan_decode: do not align the image dimensions Lynne
@ 2023-05-29 3:11 ` Philip Langdale
2023-05-29 3:13 ` Lynne
0 siblings, 1 reply; 3+ messages in thread
From: Philip Langdale @ 2023-05-29 3:11 UTC (permalink / raw)
To: ffmpeg-devel
On Mon, 29 May 2023 04:08:17 +0200 (CEST)
Lynne <dev@lynne.ee> wrote:
> According to Dave Airlie:
>
> > <airlied> but I think ignoring it should be fine, I can't see any
> > other way to get the imaeg extents correct for other usage
> > <Lynne> what width/height should be used for the images?
> > the final presentable dimensions, or the coded dimensions?
> > <airlied> if you don't want noise I think the presentable dims
> > <airlied> the driver should round up the allocations internally,
> > but if you are going to sample from the images then w/h have to be
> > the bounds of the image you want
> > <airlied> since otherwise there's no way to stop the sampler from
> > going outside the edges
>
Works fine on nvidia here. I agree with the logic - it doesn't seem
reasonable to handle it the other way.
--phil
_______________________________________________
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".
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [FFmpeg-devel] [PATCH] vulkan_decode: do not align the image dimensions
2023-05-29 3:11 ` Philip Langdale
@ 2023-05-29 3:13 ` Lynne
0 siblings, 0 replies; 3+ messages in thread
From: Lynne @ 2023-05-29 3:13 UTC (permalink / raw)
To: FFmpeg development discussions and patches
May 29, 2023, 05:11 by philipl@overt.org:
> On Mon, 29 May 2023 04:08:17 +0200 (CEST)
> Lynne <dev@lynne.ee> wrote:
>
>> According to Dave Airlie:
>>
>> > <airlied> but I think ignoring it should be fine, I can't see any
>> > other way to get the imaeg extents correct for other usage
>> > <Lynne> what width/height should be used for the images?
>> > the final presentable dimensions, or the coded dimensions?
>> > <airlied> if you don't want noise I think the presentable dims
>> > <airlied> the driver should round up the allocations internally,
>> > but if you are going to sample from the images then w/h have to be
>> > the bounds of the image you want
>> > <airlied> since otherwise there's no way to stop the sampler from
>> > going outside the edges
>>
>
> Works fine on nvidia here. I agree with the logic - it doesn't seem
> reasonable to handle it the other way.
>
Confirmed it works on 5 different systems.
Pushed with an extended description.
_______________________________________________
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".
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-05-29 3:14 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-29 2:08 [FFmpeg-devel] [PATCH] vulkan_decode: do not align the image dimensions Lynne
2023-05-29 3:11 ` Philip Langdale
2023-05-29 3:13 ` Lynne
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