[Mesa-dev] [PATCH 2/2] implement NV_vdpau_interop v3

Sun Oct 27 15:25:27 CET 2013

Am 26.10.2013 19:49, schrieb Paul Berry:
> On 26 October 2013 07:26, Christian König <deathsimple at vodafone.de 
> <mailto:deathsimple at vodafone.de>> wrote:
>
>     Merged the fixes and pushed the result this morning.
>
>
> Did you by any chance run "make check"?  I'm seeing the following failure:

Nope, sorry didn't even knew that this still existed.

But it looks like Vinson and Brian already fixed that upstream, thx for 
that.

Christian.

>
> ===========================================================
>    Mesa 10.0.0-devel: src/mesa/main/tests/test-suite.log
> ===========================================================
>
> # TOTAL: 1
> # PASS:  0
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> FAIL: main-test
> ===============
>
> Running main() from gtest_main.cc
> [==========] Running 7 tests from 3 test cases.
> [----------] Global test environment set-up.
> [----------] 2 tests from EnumStrings
> [ RUN      ] EnumStrings.LookUpByNumber
> [       OK ] EnumStrings.LookUpByNumber (0 ms)
> [ RUN      ] EnumStrings.LookUpUnknownNumber
> [       OK ] EnumStrings.LookUpUnknownNumber (0 ms)
> [----------] 2 tests from EnumStrings (0 ms total)
>
> [----------] 4 tests from DispatchSanity_test
> [ RUN      ] DispatchSanity_test.GL31_CORE
> dispatch_sanity.cpp:166: Failure
> Value of: table[i]
>   Actual: 0x5e66b6
> Expected: (_glapi_proc) _mesa_generic_nop
> Which is: 0x40cb2c
> i = 1009 (VDPAUFiniNV)
> dispatch_sanity.cpp:166: Failure
> Value of: table[i]
>   Actual: 0x5e6d2d
> Expected: (_glapi_proc) _mesa_generic_nop
> Which is: 0x40cb2c
> i = 1010 (VDPAUGetSurfaceivNV)
> dispatch_sanity.cpp:166: Failure
> Value of: table[i]
>   Actual: 0x5e6541
> Expected: (_glapi_proc) _mesa_generic_nop
> Which is: 0x40cb2c
> i = 1011 (VDPAUInitNV)
> dispatch_sanity.cpp:166: Failure
> Value of: table[i]
>   Actual: 0x5e6b10
> Expected: (_glapi_proc) _mesa_generic_nop
> Which is: 0x40cb2c
> i = 1012 (VDPAUIsSurfaceNV)
> dispatch_sanity.cpp:166: Failure
> Value of: table[i]
>   Actual: 0x5e6fa0
> Expected: (_glapi_proc) _mesa_generic_nop
> Which is: 0x40cb2c
> i = 1013 (VDPAUMapSurfacesNV)
> dispatch_sanity.cpp:166: Failure
> Value of: table[i]
>   Actual: 0x5e6a9a
> Expected: (_glapi_proc) _mesa_generic_nop
> Which is: 0x40cb2c
> i = 1014 (VDPAURegisterOutputSurfaceNV)
> dispatch_sanity.cpp:166: Failure
> Value of: table[i]
>   Actual: 0x5e6a24
> Expected: (_glapi_proc) _mesa_generic_nop
> Which is: 0x40cb2c
> i = 1015 (VDPAURegisterVideoSurfaceNV)
> dispatch_sanity.cpp:166: Failure
> Value of: table[i]
>   Actual: 0x5e6e6a
> Expected: (_glapi_proc) _mesa_generic_nop
> Which is: 0x40cb2c
> i = 1016 (VDPAUSurfaceAccessNV)
> dispatch_sanity.cpp:166: Failure
> Value of: table[i]
>   Actual: 0x5e723b
> Expected: (_glapi_proc) _mesa_generic_nop
> Which is: 0x40cb2c
> i = 1017 (VDPAUUnmapSurfacesNV)
> dispatch_sanity.cpp:166: Failure
> Value of: table[i]
>   Actual: 0x5e6bce
> Expected: (_glapi_proc) _mesa_generic_nop
> Which is: 0x40cb2c
> i = 1018 (VDPAUUnregisterSurfaceNV)
> [  FAILED  ] DispatchSanity_test.GL31_CORE (3 ms)
> [ RUN      ] DispatchSanity_test.GLES11
> [       OK ] DispatchSanity_test.GLES11 (0 ms)
> [ RUN      ] DispatchSanity_test.GLES2
> [       OK ] DispatchSanity_test.GLES2 (1 ms)
> [ RUN      ] DispatchSanity_test.GLES3
> [       OK ] DispatchSanity_test.GLES3 (0 ms)
> [----------] 4 tests from DispatchSanity_test (4 ms total)
>
> [----------] 1 test from program_state_string
> [ RUN      ] program_state_string.depth_range
> [       OK ] program_state_string.depth_range (0 ms)
> [----------] 1 test from program_state_string (0 ms total)
>
> [----------] Global test environment tear-down
> [==========] 7 tests from 3 test cases ran. (4 ms total)
> [  PASSED  ] 6 tests.
> [  FAILED  ] 1 test, listed below:
> [  FAILED  ] DispatchSanity_test.GL31_CORE
>
>  1 FAILED TEST
>
>
>
>     Thanks for the help,
>     Christian.
>
>     Am 26.10.2013 01:25, schrieb Marek Olšák:
>
>         On Sun, Oct 20, 2013 at 11:57 AM, Christian König
>         <deathsimple at vodafone.de <mailto:deathsimple at vodafone.de>> wrote:
>
>             Hi Marek,
>
>             I've just send out a v6 of the patch, please take a second
>             look. Most things
>             are fixed now, but there are still a couple of open issues:
>
>
>                 3) There should also probably be some checking for
>                 GL_ARB_texture_non_power_of_two, but the spec doesn't
>                 say what we
>                 should do (probably return GL_INVALID_OPERATION).
>
>
>             Actually I thing VDPAU hold the answer to this. The
>             specification there
>             states that the different surfaces creation function
>             should round up the
>             width/height to supported values (which can then be
>             queried later by the
>             application). So we always will end up with correct values
>             independent of
>             GL_ARB_texture_non_power_of_two.
>
>
>                 6) Registered and mapped VDPAU textures are not
>                 allowed to be
>                 re-specified by TexImage, TexSubImage,
>                 TexImage*Multisample,
>                 CopyTexImage, CopyTexSubImage, TexStorage,
>                 TexStorage*Multisample, and
>                 similar functions. This should be properly handled in
>                 those functions
>                 and GL errors should be returned.
>
>
>             I would rather like to avoid touching those functions,
>             cause they are not
>             directly related to the spec and I don't want to risk
>             breaking anything
>             there.
>
>             Would it valid so set/clear the immutable flag instead
>             (honestly I don't
>             have the slightest idea how the frontend handling works in
>             this code)?
>
>         Yes, it seems to be sufficient.
>
>
>                 7) The extension spec says that all VDPAU textures
>                 should be
>                 y-inverted. Is that actually the case here?
>
>
>             Uhm, no idea? It does seems to work, but where is that
>             information stored?
>
>         It means that a VDPAU surface is upside-down when it's used as an
>         OpenGL texture. I don't remember whether we need to a blit or
>         whether
>         OpenGL textures are y-inverted by default (then we don't have
>         to do
>         anything). If we do the same thing as NVIDIA, it's probably okay.
>
>
>         Please review and squash the attached patch with your version
>         6, and
>         feel free to push it.
>
>         Marek
>
>
>     _______________________________________________
>     mesa-dev mailing list
>     mesa-dev at lists.freedesktop.org <mailto:mesa-dev at lists.freedesktop.org>
>     http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131027/d6537404/attachment-0001.html>