Announcement

Collapse
No announcement yet.

Superposition Shows How Far RadeonSI Gallium3D Has Evolved vs. AMDGPU-PRO

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by bug77 View Post
    Yeah, out of everything he's posted so far in this thread that is the hard to swallow part
    I know, he is Gentoo user and bored when something does not compile... well, since it is blob already that automatically hurts some feelings

    Comment


    • #32
      Originally posted by dungeon View Post

      I know, he is Gentoo user and bored when something does not compile... well, since it is blob already that automatically hurts some feelings
      Idiot. This conversatrion doesn't have anything at all to do with Gentoo. It has to do with Proprietary graphics drivers allowing compatibility profiles in situations where they are non-standard. Those same proprietary drivers allow that non-standard behaviour regardless of distro or kernel used. Whether it's Gentoo, Debian, Redhat, Ubuntu, Or even Windows or OSX, It's still the wrong non-standard behaviour.
      Last edited by duby229; 04-12-2017, 03:21 PM.

      Comment


      • #33
        Originally posted by duby229 View Post

        Idiot.
        I am sorry, but how differently to understand continous yielding on AMD to opensource something whatever next is... They are not charity organization to opensource something every other day... at first, they are actually nearly majorly Windows-centric same as Intel and nVidia... i for example never push that opensource me this or that

        World outhere is full of blobs and non standards, GSync, DX12, Metal... everybody made not common but their own standards, but you complain on AMD instead who already do most on that so called "common" standard you seems to like here
        Last edited by dungeon; 04-12-2017, 03:23 PM.

        Comment


        • #34
          Originally posted by dungeon View Post

          I am sorry, but how differently to understand continous yielding on AMD to opensource something whatever next is... They are not charity organization to opensource something every other day... at first, they are actually nearly majorly Windows-centric same as Intel and nVidia... i for example never push that opensource me this or that

          World outhere is full of blobs and non standards, GSync, DX12, Metal... everybody made not common but their own standards, but you complain on AMD instead who already do most on that so called "common" standard you seems to like here
          That's fine then. Don't call their (proprietary) OpenGL driver OpenGL then. Call it something else.

          Comment


          • #35
            Originally posted by duby229 View Post
            That's fine then. Don't call their (proprietary) OpenGL driver OpenGL then. Call it something else.
            So those who have right to wear OpenGL per you now does not have that right, interesting

            Mesa is a 3-D graphics library with an API which is very similar to that of OpenGL.* To the extent that Mesa utilizes the OpenGL command syntax or state machine, it is being used with authorization from Silicon Graphics, Inc.(SGI). However, the author does not possess an OpenGL license from SGI, and makes no claim that Mesa is in any way a compatible replacement for OpenGL or associated with SGI. Those who want a licensed implementation of OpenGL should contact a licensed vendor.

            Please do not refer to the library as MesaGL (for legal reasons). It's just Mesa or The Mesa 3-D graphics library.
            https://www.mesa3d.org/license.html

            Comment


            • #36
              Originally posted by dungeon View Post

              So those who have right to wear OpenGL per you now does not have that right, interesting



              https://www.mesa3d.org/license.html
              bullshit legaleze and nothing more.

              EDIT: It's actually kind of funny because you are right in a way. Mesa doesn't have the legal right to call itself OpenGL, but Mesa is far closer to the actual OpenGL specs than AMD's proprietary driver is, which itself is far closer to the actual specs than nVidia's proprietary driver
              Last edited by duby229; 04-12-2017, 03:54 PM.

              Comment


              • #37
                Originally posted by duby229 View Post
                bullshit legaleze and nothing more.
                That is why you don't understand amount of time needed something to be opensourced... because legality is highest priority for any company who wants to survive of course

                But i agree legality could be annoying sometimes for an user... some even make most popular distro according to distrowatch just by playing on the card that legality is bullshit... thinking of Mint and their codecs which Debian/Ubuntu couldn't legaly ship at the time
                Last edited by dungeon; 04-12-2017, 04:06 PM.

                Comment


                • #38
                  This is what Debian gives me, and digging around it appears due to symbols Debian has stripped from their Qt stack.

                  ./Superposition
                  [email protected]:~/Downloads/Unigine_Superposition-1.0$ qt.network.ssl: QSslSocket: cannot resolve CRYPTO_num_locks
                  qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_id_callback
                  qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_locking_callback
                  qt.network.ssl: QSslSocket: cannot resolve ERR_free_strings
                  qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_cleanup
                  qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_init
                  qt.network.ssl: QSslSocket: cannot resolve sk_new_null
                  qt.network.ssl: QSslSocket: cannot resolve sk_push
                  qt.network.ssl: QSslSocket: cannot resolve sk_free
                  qt.network.ssl: QSslSocket: cannot resolve sk_num
                  qt.network.ssl: QSslSocket: cannot resolve sk_pop_free
                  qt.network.ssl: QSslSocket: cannot resolve sk_value
                  qt.network.ssl: QSslSocket: cannot resolve SSL_library_init
                  qt.network.ssl: QSslSocket: cannot resolve SSL_load_error_strings
                  qt.network.ssl: QSslSocket: cannot resolve SSL_get_ex_new_index
                  qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method
                  qt.network.ssl: QSslSocket: cannot resolve SSLv3_client_method
                  qt.network.ssl: QSslSocket: cannot resolve SSLv23_client_method
                  qt.network.ssl: QSslSocket: cannot resolve SSLv2_server_method
                  qt.network.ssl: QSslSocket: cannot resolve SSLv3_server_method
                  qt.network.ssl: QSslSocket: cannot resolve SSLv23_server_method
                  qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get_chain
                  qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf
                  qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf
                  qt.network.ssl: QSslSocket: cannot resolve SSLeay
                  qt.network.ssl: QSslSocket: cannot resolve SSLeay_version
                  qt.network.ssl: QSslSocket: cannot call unresolved function CRYPTO_num_locks
                  qt.network.ssl: QSslSocket: cannot call unresolved function CRYPTO_set_id_callback
                  qt.network.ssl: QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback
                  qt.network.ssl: QSslSocket: cannot call unresolved function SSL_library_init
                  qt.network.ssl: QSslSocket: cannot call unresolved function SSLv23_client_method
                  qt.network.ssl: QSslSocket: cannot call unresolved function sk_num

                  Comment


                  • #39
                    Originally posted by duby229 View Post

                    Idiot. This conversatrion doesn't have anything at all to do with Gentoo. It has to do with Proprietary graphics drivers allowing compatibility profiles in situations where they are non-standard. Those same proprietary drivers allow that non-standard behaviour regardless of distro or kernel used. Whether it's Gentoo, Debian, Redhat, Ubuntu, Or even Windows or OSX, It's still the wrong non-standard behaviour.
                    Wth does an application profile have to do with non-standard behaviour? App profiles are about knowing what an application does and letting the driver take a specific code path instead of a generic one. You know, the power devs have been asking in lower level APIs?

                    It's basically the same as applying quick sort by default, but using bubble sort when you know some specific app uses mostly sorted collections.

                    Comment


                    • #40
                      Originally posted by Marc Driftmeyer View Post
                      This is what Debian gives me, and digging around it appears due to symbols Debian has stripped from their Qt stack.

                      ./Superposition
                      mdriftmeye[email protected]:~/Downloads/Unigine_Superposition-1.0$ qt.network.ssl: QSslSocket: cannot resolve CRYPTO_num_locks
                      qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_id_callback
                      qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_locking_callback
                      qt.network.ssl: QSslSocket: cannot resolve ERR_free_strings
                      qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_cleanup
                      qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_init
                      qt.network.ssl: QSslSocket: cannot resolve sk_new_null
                      qt.network.ssl: QSslSocket: cannot resolve sk_push
                      qt.network.ssl: QSslSocket: cannot resolve sk_free
                      qt.network.ssl: QSslSocket: cannot resolve sk_num
                      qt.network.ssl: QSslSocket: cannot resolve sk_pop_free
                      qt.network.ssl: QSslSocket: cannot resolve sk_value
                      qt.network.ssl: QSslSocket: cannot resolve SSL_library_init
                      qt.network.ssl: QSslSocket: cannot resolve SSL_load_error_strings
                      qt.network.ssl: QSslSocket: cannot resolve SSL_get_ex_new_index
                      qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method
                      qt.network.ssl: QSslSocket: cannot resolve SSLv3_client_method
                      qt.network.ssl: QSslSocket: cannot resolve SSLv23_client_method
                      qt.network.ssl: QSslSocket: cannot resolve SSLv2_server_method
                      qt.network.ssl: QSslSocket: cannot resolve SSLv3_server_method
                      qt.network.ssl: QSslSocket: cannot resolve SSLv23_server_method
                      qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get_chain
                      qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf
                      qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf
                      qt.network.ssl: QSslSocket: cannot resolve SSLeay
                      qt.network.ssl: QSslSocket: cannot resolve SSLeay_version
                      qt.network.ssl: QSslSocket: cannot call unresolved function CRYPTO_num_locks
                      qt.network.ssl: QSslSocket: cannot call unresolved function CRYPTO_set_id_callback
                      qt.network.ssl: QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback
                      qt.network.ssl: QSslSocket: cannot call unresolved function SSL_library_init
                      qt.network.ssl: QSslSocket: cannot call unresolved function SSLv23_client_method
                      qt.network.ssl: QSslSocket: cannot call unresolved function sk_num
                      From another thread, ssl is in transit in Debian testing/sid... and this one wanna older

                      https://www.phoronix.com/forums/foru...363#post945363

                      Comment

                      Working...
                      X