Announcement

Collapse
No announcement yet.

Catalyst 9.2 Released, Still Fails To Deliver XvBA

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

  • Originally posted by RealNC View Post
    As if a link lib->lib64 is going to bring the world down. Seriously.
    Well, if it doesn't work out of the box, people may not be able to install the driver at all.
    There are /some/ newbies using Linux after all...

    Comment


    • As if a link lib->lib64 is going to bring the world down. Seriously.
      Obviously not, but this is a regression and should be fixed.

      Besides, it's annoying as it clashes with the policy of the distribution (pure 64-bit, with 64-bit libraries in /usr/lib).

      Comment


      • Originally posted by RealNC View Post
        As if a link lib->lib64 is going to bring the world down. Seriously.
        the common linux dir hierarchy (eg, see http://en.wikipedia.org/wiki/Filesys...archy_Standard) is not intended to support multilib.
        further, xorg and its components are all installed under /lib or /usr/lib.
        so since this should be a _linux_ not a debian/ubuntu/gentoo/some-other-multilib-distro driver, this is a major regression!
        btw, it's the dumbest idea to hardcode paths in apps!
        hope they change this in upcoming versions.

        Comment


        • Originally posted by bugmenot View Post
          the common linux dir hierarchy (eg, see http://en.wikipedia.org/wiki/Filesys...archy_Standard) is not intended to support multilib.
          Did you read the standard? /lib is for the native binary format. Most (all?) rpm distros don't follow this and put the 32bit lib into /lib. They break the standard there. Gentoo does it right, putting 32bit libs to /lib32 and 64bit libs into /lib64. /lib is only a symlink to the native format.
          So, multilib is supported by linux but not right implemented by most distros.

          Comment


          • Originally posted by PuckPoltergeist View Post
            Did you read the standard? /lib is for the native binary format. Most (all?) rpm distros don't follow this and put the 32bit lib into /lib. They break the standard there. Gentoo does it right, putting 32bit libs to /lib32 and 64bit libs into /lib64. /lib is only a symlink to the native format.
            So, multilib is supported by linux but not right implemented by most distros.
            Debian does it the same way as Gentoo as there is /lib32 and /lib64. /lib links to /lib64 /lib32 is linked to /emul/ia32-linux/lib.

            Comment


            • Originally posted by bugmenot View Post
              the common linux dir hierarchy (eg, see http://en.wikipedia.org/wiki/Filesys...archy_Standard) is not intended to support multilib.
              further, xorg and its components are all installed under /lib or /usr/lib.
              so since this should be a _linux_ not a debian/ubuntu/gentoo/some-other-multilib-distro driver, this is a major regression!
              The problem is, that it *is* a debian/ubuntu/etc driver. Only certain distros are supported by the driver. It's stated in the release notes.

              Of course hardcoding paths is brain damage, but still, the driver package is only for specific distros. The rest must somehow manage to comply with its expectations.

              Comment


              • Well best it to use packageing of course. If you use the pure installer then I may fail. The Debian packageing is just too often with errors, so never rely on it.

                Comment


                • Can anyone with an ati 2x00+ or nvidia 8x00+ run the following program? It tries to create an OpenGL 3.0 context and render some colors to a small window - and, despite my best efforts, it fails unceremoniously on my 4850 with 9.2 on x86_64.

                  Code:
                  wget http://www.opentk.com/files/issues/gl3.cpp
                  g++ gl3.cpp -o gl3 -lX11 -lGL
                  ./gl3
                  Does it work for you? What hardware? What drivers? x86 or x86_64?

                  Comment


                  • Originally posted by BlackStar View Post
                    Can anyone with an ati 2x00+ or nvidia 8x00+ run the following program? It tries to create an OpenGL 3.0 context and render some colors to a small window - and, despite my best efforts, it fails unceremoniously on my 4850 with 9.2 on x86_64.

                    Code:
                    wget http://www.opentk.com/files/issues/gl3.cpp
                    g++ gl3.cpp -o gl3 -lX11 -lGL
                    ./gl3
                    Does it work for you? What hardware? What drivers? x86 or x86_64?
                    It does not work for me:

                    Code:
                    ./gl3
                    GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_import_context GLX_EXT_visual_info GLX_EXT_visual_rating GLX_MESA_swap_control GLX_OML_swap_method GLX_OML_sync_control GLX_SGI_video_sync GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_visual_select_group 
                    glXCreateContextAttribsARB entry point not found
                    GPU: Radeon HD 3850
                    Drivers: Catalyst 8.12
                    Distro: Debian "Squeeze" amd64

                    Comment


                    • @BlackStar

                      A bit short but it runs fine with nvidia 8800 gts 512.

                      Code:
                      GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_EXT_texture_from_pixmap GLX_ARB_create_context GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_fbconfig_float GLX_EXT_framebuffer_sRGB GLX_ARB_get_proc_address
                      Getting framebuffer config
                      Getting XVisualInfo
                      Creating colormap
                      Creating window
                      Mapping window
                      Creating context
                      Making context current

                      Comment

                      Working...
                      X