Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add HW assistant copy interface #243

Merged
merged 2 commits into from
Dec 3, 2020
Merged

add HW assistant copy interface #243

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fdea24a
add definition for different execution
XinfengZhang Nov 25, 2020
8b24290
add vaCopy interface to copy surface and buffer
XinfengZhang Sep 28, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions va/va.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2286,3 +2286,23 @@ vaQueryVideoProcPipelineCaps(
VA_TRACE_RET(dpy, status);
return status;
}

VAStatus
vaCopy(
VADisplay dpy,
VACopyObject *dst,
VACopyObject *src,
VACopyOption option
)
{
VAStatus va_status;
VADriverContextP ctx;
CHECK_DISPLAY(dpy);
ctx = CTX(dpy);

XinfengZhang marked this conversation as resolved.
Show resolved Hide resolved
XinfengZhang marked this conversation as resolved.
Show resolved Hide resolved
if(ctx->vtable->vaCopy == NULL)
va_status = VA_STATUS_ERROR_UNIMPLEMENTED;
else
va_status = ctx->vtable->vaCopy( ctx, dst, src, option);
return va_status;
}
52 changes: 52 additions & 0 deletions va/va.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -358,6 +358,17 @@ typedef int VAStatus; /** Return status type from functions */
#define VA_PADDING_HIGH 16
#define VA_PADDING_LARGE 32

/** operation options */
/** synchronization, block call, output should be ready after execution function return*/
#define VA_EXEC_SYNC 0x0
/** asynchronization,application should call additonal sync operation to access output */
#define VA_EXEC_ASYNC 0x1

/** operation mode */
#define VA_EXEC_MODE_DEFAULT 0x0
#define VA_EXEC_MODE_POWER_SAVING 0x1
#define VA_EXEC_MODE_PERFORMANCE 0x2

/**
* Returns a short english description of error_status
*/
Expand Down Expand Up @@ -4878,6 +4889,47 @@ typedef struct _VAPictureHEVC
*/
#define VA_PICTURE_HEVC_RPS_LT_CURR 0x00000040

typedef enum{
VACopyObjectSurface = 0,
VACopyObjectBuffer = 1,
} VACopyObjectType;

typedef struct _VACopyObject {
VACopyObjectType obj_type; // type of object.
union
{
VASurfaceID surface_id;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These ID types goes as:

typedef unsigned int VAGenericID;

which might have different size... Can we add some specific size to this union? Like:

    union
    {
        VASurfaceID surface_id;
        VABufferID  buffer_id;
        uint64_t reserved;
    } object;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to enlarge the size to 64bit? which compiler/platform will lead to different size of unsigned int?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure, but I am paranoid:)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we could consider about the "uint32_t"/"uint64_t" "unsigned long" for future, such as 3.0? , unsigned long will be changed adaptively with the compiler. uint64_t /uint32_t will be dedicate size.

VABufferID buffer_id;
} object;

uint32_t va_reserved[VA_PADDING_MEDIUM];
} VACopyObject;

typedef union _VACopyOption{
struct {
/** \brief va copy synchronization, the value should be /c VA_EXEC_SYNC or /c VA_EXEC_ASYNC */
uint32_t va_copy_sync : 2;
/** \brief va copy mode, the value should be VA_EXEC_MODE_XXX */
uint32_t va_copy_mode : 4;
uint32_t reserved :26;
}bits;
uint32_t value;
}VACopyOption;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've also planned to expose vaMapBuffer2 API w/ flags and maybe w/ copy options... See #377 for the early draft.

Can we, please, consider whether we can apply VACopyOption to the vaMapBuffer2 API as well? I worry about va_copy_sync usage... Thought it might still be useful in vase of vaUnmap when we might or might not to wait for the sync...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I worry about va_copy_sync usage... Thought it might still be useful in vase of vaUnmap when we might or might not to wait for the sync...

@dvrogozh , do you mean asynchronous writing to vaSurface?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possible usages:

vaMapBuffer2(VA_COPY_SYNC_NONBLOCK); // allocates (maybe) shadow copy, no
                              // copy from original surface due to VA_COPY_SYNC_NONBLOCK (we don't care about the contetn)
memcpy();
unmap(); // schedules copy operation form shadow copy to final surface, we don't wait due to VA_COPY_SYNC_NONBLOCK

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's async writing to vaSurface/vaBuffer. Above, you say "usages". To tell you the truth I don't see other examples.
But anyway, IMO, it indeed can be useful.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it means map is block call , but unmap is un-block call , right? the interface will be a little weird. need to re-consider it. maybe also a unmap2?


/** \brief Copies an object.
*
* Copies specified object (surface or buffer). If non-blocking copy
* is requested (VA_COPY_NONBLOCK), then need vaSyncBuffer or vaSyncSurface/vaSyncSurface2
* to sync the destination object.
*
* @param[in] dpy the VA display
* @param[in] dst Destination object to copy to
* @param[in] src Source object to copy from
* @param[in] option VA copy option
* @return VA_STATUS_SUCCESS if successful
*/
VAStatus vaCopy(VADisplay dpy, VACopyObject * dst, VACopyObject * src, VACopyOption option);

#include <va/va_dec_hevc.h>
#include <va/va_dec_jpeg.h>
#include <va/va_dec_vp8.h>
Expand Down
10 changes: 8 additions & 2 deletions va/va_backend.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -484,7 +484,6 @@ struct VADriverVTable
uint32_t flags, /* in */
void *descriptor /* out */
);

VAStatus (*vaSyncSurface2) (
VADriverContextP ctx,
VASurfaceID surface,
Expand All @@ -497,8 +496,15 @@ struct VADriverVTable
uint64_t timeout_ns
);

VAStatus
(*vaCopy)(
VADriverContextP ctx, /* in */
VACopyObject *dst, /* in */
VACopyObject *src, /* in */
VACopyOption option /* in */
);
/** \brief Reserved bytes for future use, must be zero */
unsigned long reserved[55];
unsigned long reserved[54];
};

struct VADriverContext
Expand Down