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

[dungeon]

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

[duby229]

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.

[dungeon]

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

[duby229]

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.

[dungeon]

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

[duby229]

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

[dungeon]

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

[Marc Driftmeyer]

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

./Superposition
mdriftmeyer@horus:~/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

[bug77]

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.

[dungeon]

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

./Superposition
mdriftmeyer@horus:~/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/forum/phoronix/latest-phoronix-articles/945241-unigine-superposition-is-a-beautiful-way-to-stress-your-gpu-in-2017-17-way-graphics-card-comparison?p=945363#post945363