Announcement

Collapse
No announcement yet.

Radeon Pro Software 17.Q1 Released For Linux Professionals

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

  • #31
    Originally posted by bridgman View Post

    Can you help me to understand how the file type and/or install mechanism affects whether or not you have full support of your graphics card ?

    What features do you feel you are missing, and how would a .run file help ?

    Thanks...
    I use Gentoo, Sabayon, and Slackware Linux. I use a vanilla Linux distros. I don't use .deb or .rpm based distros. Debian package management is a hair splitting package management nightmare. Yeah, a .run file supports vanilla Linux distros. A .rpm or .deb file with 50 packages inside is ridiculous. the single .run could generate packages or install in vanilla distros without a package manager. In Gentoo's scenario it could unpack and do compiling and install via ebuild script (not that it was necessary considering the .run worked fine until you wanted to use eselect for opengl binaries).

    So yeah, because I don't like the hair splitting tactics of, in my opinion, bad package management, I'm penalized. If an application is a single application you would compile and install, but would instead split off libraries, debugging symbols, and features to turn a single package into 5 or more, its awful. Now I must maintain and remember 5 or more packages vs the one. Where usually I could just reinstall a single package or repair a single package that I know this specific library belongs to, I now have to remember specific libraries as though they are there own item when they are not. .deb just screams broken.

    Stability and Strength of Slackware is what originally lured me to the Linux world. 64-bit support and package management moved me to Gentoo. A prebuilt Gentoo moved me to RR64 (compiling for weeks to get a new install sucked) which evolved into Sabayon with binary package management built on portage and completely backward compatible with portage/gentoo.


    Originally posted by dungeon View Post

    It is about expectations i guess, since.run file was standard of catalyst/fglrx installer for many many years. So likely people expect that there, instead of something else...

    And he probably use some unsupported distro by AMDGPU-PRO and voila... instead of getting universal .run installer like before, he get distro specific packages
    Yeah I use "unsupported distros", I use Vanilla Linux Distros. Its not about expectations, its about fake linux support. "we support ubuntu" IS NOT "we support Linux". Redhat/fedora is more supportive of Vanilla Linux than Ubuntu. Started with Slackware, moved on to Gentoo, now use Sabayon. Server still runs Slackware. Desktops and laptops run Sabayon/Gentoo. I want FULL LINUX SUPPORT, not the cherry picked crap that was delivered.

    Comment


    • #32
      Originally posted by Darksurf View Post
      Yeah I use "unsupported distros", I use Vanilla Linux Distros. Its not about expectations, its about fake linux support. "we support ubuntu" IS NOT "we support Linux". Redhat/fedora is more supportive of Vanilla Linux than Ubuntu. Started with Slackware, moved on to Gentoo, now use Sabayon. Server still runs Slackware. Desktops and laptops run Sabayon/Gentoo. I want FULL LINUX SUPPORT, not the cherry picked crap that was delivered.
      OK, that's fair - you need an install solution for Slackware/Sabayon/Gentoo. Am I correct in understanding that the all-open stack is being integrated successfully into those distros today, and that it is just the -PRO stack you are having problems with ?

      Do you expect to still need the -PRO package over time as Vulkan and OpenCL become available as part of the all-open stack, ie do you see an overlap between users of those distros and CAD/workstation market ? Asking because that's something we have not really observed yet.

      As you know the -PRO package is primarily a replacement for fglrx as the CAD/workstation driver; it has also been useful in other markets while we close gaps in the all-open stack, but most non-WS users have already moved to the all-open stack.
      Last edited by bridgman; 03-01-2017, 09:42 AM.

      Comment


      • #33
        Originally posted by bridgman View Post

        OK, that's fair - you need an install solution for Slackware/Sabayon/Gentoo. Am I correct in understanding that the all-open stack is being integrated successfully into those distros today, and that it is just the -PRO stack you are having problems with ?

        Do you expect to still need the -PRO package over time as Vulkan and OpenCL become available as part of the all-open stack, ie do you see an overlap between users of those distros and CAD/workstation market ? Asking because that's something we have not really observed yet.

        As you know the -PRO package is primarily a replacement for fglrx as the CAD/workstation driver; it has also been useful in other markets while we close gaps in the all-open stack, but most non-WS users have already moved to the all-open stack.
        You are correct that the openstack is integrated and that the PRO is the only problem.

        First off, there will always be reason to have the PRO driver available beyond "Workstations". BYOD is also common place now. I used Sabayon at my last job. I was allowed to use what I wanted as long as it didn't interfere with me getting my work done. In the future do I see myself installing the PRO driver after you opensource much of it? Yes. Considering the binary blob that will be used OpenGL will likely outperform opensource, there will always be a difference in opensource and proprietary drivers. Lets say you opensource all of the opengl stuff into mesa, are you also going to opensource Crossfire? Do you plan on Open Sourcing EVERYTHING? If yes, how long will that take. How long must I wait before I have full support of a device I invested my trust and money in? I find it odd, that I must wait until the Fury X is no longer the top and is considered obsolete before it can get full support. We currently don't even have FULL vulkan support in opensource yet. Sure it works... with artifacts etc. I've been waiting for AMDGPU for a long time. Yes it is coming along nicely, but I can't wait on it to have support for my gear now. Only way I could possibly reach the potential of my card currently is to install windows on my machine. Do you plan on opensourcing a control utility such as the control center where I can enable/disable freesync and other options?

        Currently, I do see reason the PRO driver will go beyond business. I see the Open Source driver becoming the 90-95% of the proprietary driver, but I do not currently see or hear any plans for the other 5-10% to go opensource (control center, Crossfire, Opengl+Vulkan+OpenCL binaries).
        Last edited by Darksurf; 03-01-2017, 11:00 AM.

        Comment


        • #34
          Originally posted by Darksurf View Post
          Currently, I do see reason the PRO driver will go beyond business. I see the Open Source driver becoming the 90-95% of the proprietary driver, but I do not currently see or hear any plans for the other 5-10% to go opensource (control center, Crossfire, Opengl+Vulkan+OpenCL binaries).
          The open source driver is already outperforming the PRO OpenGL driver on quite a few games; that is where most of our gaming focus is going now. We are not doing a "good, better, best" thing with open source vs closed source, except for workstation apps where compatibility profiles and ISV-specific performance tuning are still important.

          No current plans for control center or Crossfire on either open or PRO stacks, so nothing to choose there. We are working on open sourcing Vulkan and OpenCL. No plans to open source OpenGL but that is going to be primarily for workstation apps anyways.

          Comment


          • #35
            Originally posted by Darksurf View Post
            Yeah I use "unsupported distros", I use Vanilla Linux Distros. Its not about expectations, its about fake linux support. "we support ubuntu" IS NOT "we support Linux". Redhat/fedora is more supportive of Vanilla Linux than Ubuntu. Started with Slackware, moved on to Gentoo, now use Sabayon. Server still runs Slackware. Desktops and laptops run Sabayon/Gentoo. I want FULL LINUX SUPPORT, not the cherry picked crap that was delivered.
            It is again about expectations As you expect (and anybody else likely) don't want just driver for Ubuntu, not just driver for Slackware and not just driver for Gentoo, not just driver for Sabayon, etc... There is no other way of that FULL LINUX SUPPORT other than supporting release versions of kernels from kernel.org and servers versions from x.org - it was always that simple, but never for ATi/AMD

            I understand what you want - "free to choose linux distro (or something that your company might require which happen to not be among these OSes supported) where you want, need or require to install propertiary driver" and that is exactly again about supporting releases of kernel/X on their release date and not just releases of particular distros

            If AMD blob driver supports every kernel and X version on release date, everybody would be fine with that on don't complain.

            It was always that simple defined goal, but never for ATi/AMD - they likely has some different goal
            Last edited by dungeon; 03-01-2017, 06:18 PM.

            Comment


            • #36
              Originally posted by Darksurf View Post
              Debian package management is a hair splitting package management nightmare.
              He, he, it is not - it is more about options what someone want to install or not also if AMD wanna update only one package but not need to rebuild everything or so There are 52 deb packages total there, among which:

              25 are 64bit
              24 are 32bit
              3 are common

              And there are couple selection tasks someone might want to install - 64bit only, 32bit only, both 64bit and 32bit compat, PX setups only, CL setup only... and then non essential and development packages also, utilities also, vulkan also, video UMDs... or whatever further they want to put there also.

              It is about options what someone might want or need or not want/need to install, but basic install somewhat does not require more than 10 packages for some of these particular tasks On the other side someone might wanna full blown (not quite but literally) everything, so be it
              Last edited by dungeon; 03-01-2017, 07:34 PM.

              Comment

              Working...
              X