Am 26.10.2013 19:49, schrieb Paul Berry:
On 26 October 2013 07:26, Christian König <deathsim...@vodafone.de <mailto:deathsim...@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
        <deathsim...@vodafone.de <mailto:deathsim...@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@lists.freedesktop.org <mailto:mesa-dev@lists.freedesktop.org>
    http://lists.freedesktop.org/mailman/listinfo/mesa-dev



_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to