Skip to content

Conversation

@sivileri
Copy link
Contributor

@sivileri sivileri commented Sep 29, 2022

This MR ports vainfo and the gtest suite for Windows using libva-win32

Requires: intel/libva#621

@evelikov
Copy link

As a draft this is great. For the final PR please consider:

  • keeping the getopt a separate commit with references (source and version/git commit) in the commit message
  • adding support for non-default (NULL) display
  • run through style-unify, if you haven't already
  • porting at least some of the following - decode, encode, videoprocess and tests - hopefully they should be a matter of a trivial compat_win32.h header

The final pieces don't make sense to port IMHO:

  • vendor/intel - there is no intel driver for win32 (yet at least)
  • putsurface - the API is not implemented in va-win32, rightfully so IMHO

@sivileri
Copy link
Contributor Author

sivileri commented Sep 29, 2022

@evelikov thanks for taking a look, please see inline.

As a draft this is great. For the final PR please consider:

  • keeping the getopt a separate commit with references (source and version/git commit) in the commit message

[sivileri] Will do.

  • run through style-unify, if you haven't already

[sivileri] Got it. I ran it through the files I changed, no changes needed.

  • adding support for non-default (NULL) display
  • porting at least some of the following - decode, encode, videoprocess and tests - hopefully they should be a matter of a trivial compat_win32.h header

[sivileri] I tried doing this earlier today, I could use a similar win32_compat like the one used for the libva repo for some of the it like the time.h functions and variadic macros, but in here the changes need to be a bit more invasive and will change significant parts of the existing code, the biggest reason being the explicit initialization with <fieldname> : <value> that's used for structs in the tests and doesn't build with MSVC, some tests using pthreads among others and being pure C limits the usage of some features like COM RAII for D3D code, etc.

To avoid doing such a disruptive change on existing code, and considering there are open source samples for VA on Windows here that do adapter enumeration and selection, encode, video processing, importing/exporting of surfaces and interop with D3D12 to present surfaces to screen, maybe we can add those to this repo and/or link them here to the project where those live? I'll work on porting a decode example in that sample app for completeness.

Edit: Added decode sample based on llibva-utils sample

The final pieces don't make sense to port IMHO:

  • vendor/intel - there is no intel driver for win32 (yet at least)
  • putsurface - the API is not implemented in va-win32, rightfully so IMHO

[sivileri] Sounds good.

@evelikov
Copy link

the biggest reason being the explicit initialization with : that's used for structs in the tests and doesn't build with MSVC

Off the top of my head, tests/gtest should just work with MSVC, do shout if it does not. Actual tests like test_va_api_get_create_config.cpp should really be fixed to use standard C++ by either dropping the <fieldname> : or using C++20 designated initialises (the ones we got with C99).

some tests using pthreads among others and being pure C limits the usage of some features like COM RAII for D3D code, etc.

Not familiar with the details off the top of my head. If you have references I might come-up with some half-crazy idea :-)

... maybe we can add those to this repo and/or link them here to the project where those live? I'll work on porting a decode example in that sample app for completeness.

No idea if copying these into the repo will try. Although having at least one actual example ported (apart from vainfo of course) - decode or others, would be amazing IMHO.

@evelikov
Copy link

Glancing at the in-repo tools - they have been bit-rotting since 2016 when they were split out of libva itself. In libva we've had a dozen APIs and even more enum additions, while this repo has predominantly seen static analyser fixes. There is one notable exception - porting the tests to GTest \o/

Now I see why you saw more value in writing fresh HelloWorld demos instead of digging into the graveyard 👍

Personally I would strongly recommend porting the tests and not worrying about the rest. They should be trivial to fix, plus the Mesa CI should be using them already (or is about to soon).

@sivileri sivileri changed the title Port vainfo for libva-win32 Port vainfo and tests for libva-win32 Sep 30, 2022
@sivileri
Copy link
Contributor Author

Glancing at the in-repo tools - they have been bit-rotting since 2016 when they were split out of libva itself. In libva we've had a dozen APIs and even more enum additions, while this repo has predominantly seen static analyser fixes. There is one notable exception - porting the tests to GTest \o/

Now I see why you saw more value in writing fresh HelloWorld demos instead of digging into the graveyard 👍

Personally I would strongly recommend porting the tests and not worrying about the rest. They should be trivial to fix, plus the Mesa CI should be using them already (or is about to soon).

I went ahead and ported the tests too now, I was able to build and run them.

@evelikov
Copy link

evelikov commented Oct 1, 2022

Incoming some nitpicks and a question for the mid-long run. Overall I'm in favour of the PR and don't see anything being off.

@sivileri sivileri marked this pull request as ready for review October 4, 2022 12:58
@dvrogozh
Copy link
Contributor

dvrogozh commented Oct 5, 2022

let's merge this already - hint maintainers, hint

We are waiting for @XinfengZhang to try libva and libva-utils changes. This won't happen earlier than next week due to holidays in China.

@sivileri
Copy link
Contributor Author

@dvrogozh @XinfengZhang now that intel/libva#621 is merged, could you please enable the workflows execution? I'll work on making them work with the libva-win32 dependency from libva/master

image

@sivileri sivileri requested a review from dvrogozh October 13, 2022 15:03
@sivileri sivileri force-pushed the va_win_dev branch 2 times, most recently from 0f391c8 to d46dd7e Compare October 13, 2022 15:25
@sivileri sivileri force-pushed the va_win_dev branch 6 times, most recently from d114d7e to b9d961e Compare October 13, 2022 17:54
@sivileri
Copy link
Contributor Author

@dvrogozh @XinfengZhang now that intel/libva#621 is merged, could you please enable the workflows execution? I'll work on making them work with the libva-win32 dependency from libva/master

image

There we go: https://github.com/sivileri/libva-utils/actions/runs/3244558566/jobs/5320888674 :) Please let me know if I can do anything else before we can merge this MR too.

image

@dvrogozh
Copy link
Contributor

now that intel/libva#621 is merged, could you please enable the workflows execution?

Approved. But mind that this is a manual action which needs to be done each time till you won't have at least 1 commit merged:). So, if you will push an update it will need a new approval.

@dvrogozh
Copy link
Contributor

freebsd build fails (you need to open "test" stage to see actual error):

ld: error: undefined symbol: va_display_hooks_win32

Copy link
Contributor

@dvrogozh dvrogozh left a comment

Choose a reason for hiding this comment

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

looks good

What did you do to fix freebsd build? Can you point to the change, please?

@dvrogozh dvrogozh requested a review from XinfengZhang October 15, 2022 02:33
@evelikov
Copy link

What did you do to fix freebsd build? Can you point to the change, please?

The "Compare" button shows them - aka DHAVE_VA_WIN32=1 was incorrectly set.

@sivileri
Copy link
Contributor Author

looks good

What did you do to fix freebsd build? Can you point to the change, please?

Thanks! DHAVE_VA_WIN32=1 was being always set disregarding of the dependency check. Here's the fix from the latest push:
https://github.com/intel/libva-utils/compare/b9d961ecd78b5c742aa834abbb4e3c775cb70e9d..88cd38ba4834c6da42d7084444fc6adbab9affdc
image

@dvrogozh
Copy link
Contributor

Thank you for pointing out. I am fine with the change. @XinfengZhang : can you, please, take a look and merge?

subdir('vendor/intel/sfcsample')

if not use_win32
subdir('decode')
Copy link
Contributor

Choose a reason for hiding this comment

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

is it possible to make sample codes work on windows?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For most of them we don't have driver support yet to test it (ie. mpeg2, jpeg decode, vp8/vp9 encode and most VPP effects tested). I think the ones we could port and test today are: encode H264/HEVC and VPP scaling and color conversion (only NV12, P010 and RGBX supported in driver at the moment).

From those we could port and test at the moment, cross-platform porting is needed, the most notable port needed would be pthreads for the encode samples.

As we're also in the process of writing new samples for Windows that cover those same Decode/Encode/VPP scenarios implemented by the driver today, also showing D3D12/Libva interoperability and adapter enumeration/selection, could we maybe point to those samples instead in the documentation? The goal is to upstream the open source samples to DirectX-Graphics-Samples when finished.

You can find the in-progress samples in: H264 decode sample similar to intel/sfcsample and VPP Color Conversion + H264 encode that show encode and color conversion

Signed-off-by: Sil Vilerino <sivileri@microsoft.com>
Signed-off-by: Sil Vilerino <sivileri@microsoft.com>
Signed-off-by: Sil Vilerino <sivileri@microsoft.com>
Signed-off-by: Sil Vilerino <sivileri@microsoft.com>
Signed-off-by: Sil Vilerino <sivileri@microsoft.com>
Added windows.yml and EnterDevShell.ps1
for MSVC/mingw building with ninja/meson backend.

Signed-off-by: Sil Vilerino <sivileri@microsoft.com>
@XinfengZhang XinfengZhang merged commit 6bc3ec4 into intel:master Oct 23, 2022
@sivileri sivileri deleted the va_win_dev branch February 7, 2023 13:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants