Page 6 of 16 FirstFirst ... 45678 ... LastLast
Results 51 to 60 of 159

Thread: AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy

  1. #51
    Join Date
    Mar 2011
    Posts
    349

    Default

    Quote Originally Posted by pingufunkybeat View Post
    This sounds absolutely brilliant and it would be genius if they can pull it off.

    - Open drivers would profit from more people working on the kernel and the resulting optimisations, as well as early support for new hardware.
    - AMD cards would work out of the box with open drivers, and provide a great default experience for all of us who prefer
    - Those who want more woompfh for their CAD, professional workstation stuff and Workraft can download the userspace blob easily.
    - The blob would not violate all kinds of licenses and be illegal to distribute for distributions, unlike Nvidia's legal minefield.
    - The blob could happily use kernel interfaces for seamless integration with intel IGPs, unlike Nvidia.

    Everybody wins!
    I agree i guess. I just want fast stable AMD performance and if this means that a soft radeon reset is possible (like in modern Windows) that's amazing progressive. I will be buying more AMD to show my support. Thanks guys, Thanks bridgman for your helpful comments. Thanks God for making AMD see the light-ish!

  2. #52
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,635

    Default

    Quote Originally Posted by bridgman View Post
    Patents are a really expensive way of protecting IP, and don't work particularly well in a closed source environment since you have no obvious way to know if a violation occurred. You also have to make the information public as part of the patent process, and in many cases the idea is more useful than the patentable details (since patents really describe a specific implementation rather than an underlying idea).

    Patents work well when the IP is visible to the general public by virtue of how it is used in a product, but in a closed-source environment using trade secrets requires less effort, less expense, and is generally more effective... and yes that does make closed source software a bit of a self-perpetuating thing.

    Someone asked earlier about making everything open source except a few small binary modules containing the secrets. Problem is that reverse engineering small binary modules surrounded by open source is really easy. The idea has been tried a few times already (IIRC Intel used to have a binary shader compiler module, for example) but never seemed to work for anyone.
    Well that's the thing, why is patenting things and then opening the source not possible? It's more effort in the short run, but sounds like less effort in the long run.

    About reverse engineering, that doesn't sound like that strong an argument to me... I'm not really sure who would want to reverse-engineer such things. NVIDIA probably wouldn't be interested in those optimisations to begin with, and the radeon team probably has more interesting things to do with their time (or come up with even better optimisation ideas). And you can reverse-engineer such things from blobs as well, with enough determination. The benefits of such things sound like they outweigh the disadvantages... Though I haven't heard anything about the intel binary shader compiler or anything else similar.

  3. #53
    Join Date
    Oct 2008
    Posts
    3,212

    Default Huh, i did NOT see this coming

    It's an interesting idea. I think a lot of the things michael brings up are fairly easily worked around, but the 1 thing i would be concerned about would be the timing of new hardware support, and how new hardware would work with older distros.

    I know the oss driver has finally caught up with new hardware, but it still remains to be seen whether the next round of new hardware will be supported in mainstream distros by the time it is actually released rather than requiring you to go compile git kernels and so on. It would be important to at least get to the point that Intel is at right now, and even then you are at a worse place than the current fglrx support gives you if you want to go back and run a LTS distro.

    As a couple other people have mentioned, it would be amazing to be able to run the gallium drivers on your system and then dynamically switch to fglrx for those 1 or 2 apps that need the highest performance or GL version that is still missing on the oss side. Fglrx has always sucked at running the basic desktop, and they could start ignoring that completely, and their workstation customers could just start using fglrx on their workstation apps only where it is actually optimized. Same for running games on SteamOS - you could run the system with the gallium drivers and switch into fglrx as needed for games.

  4. #54
    Join Date
    Oct 2012
    Posts
    273

    Default

    What about OpenCL? Couldn't AMD have just left it closed source, as some sort of "plug-in" instead of developing it from scratch? I mean, it's great to have it open-sourced, but I'm not sure many people using it cares about it being FOSS... more likely, they just want it working fast and well. Also, isn't LLVM kind of a mess? AMD could just have distributed a static version of it, no?
    Oh, and what about HSA, as someone said before? When will devs finally be able use the GPU as another powerful device along with the other devices in their applications?
    Last edited by asdfblah; 03-22-2014 at 04:27 PM.

  5. #55
    Join Date
    Oct 2008
    Posts
    3,212

    Default

    Quote Originally Posted by GreatEmerald View Post
    About reverse engineering, that doesn't sound like that strong an argument to me... I'm not really sure who would want to reverse-engineer such things.
    AMD and NVidia both have people dedicated to reverse engineering the others product and making sure they aren't falling behind.

  6. #56
    Join Date
    Jun 2012
    Posts
    16

    Default

    Quote Originally Posted by ricequackers View Post
    Still, attitudes do vary - ARM is trying to encourage partners to open up and has been leading by example with Mali.
    This is off-topic but... could you clarify? As far as I know they haven't opened up the way intel and amd have.

  7. #57
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,541

    Default

    Quote Originally Posted by GreatEmerald View Post
    Well that's the thing, why is patenting things and then opening the source not possible? It's more effort in the short run, but sounds like less effort in the long run.
    It's not opening *your* source that lets you detect patent violations, it's opening the *other* guy's source, and we don't control that

    Quote Originally Posted by GreatEmerald View Post
    About reverse engineering, that doesn't sound like that strong an argument to me... I'm not really sure who would want to reverse-engineer such things. NVIDIA probably wouldn't be interested in those optimisations to begin with, and the radeon team probably has more interesting things to do with their time (or come up with even better optimisation ideas). And you can reverse-engineer such things from blobs as well, with enough determination. The benefits of such things sound like they outweigh the disadvantages... Though I haven't heard anything about the intel binary shader compiler or anything else similar.
    It's a *lot* easier to reverse engineer a small binary bundle of secrets in the middle of an open source stack than it is to reverse engineer 100MB of binary drivers.

    IIRC the Intel binary shader compiler module had already been abandoned by the time we re-started open source gfx driver work in 2007.
    Last edited by bridgman; 03-22-2014 at 04:28 PM.

  8. #58
    Join Date
    Jun 2010
    Posts
    250

    Default

    Quote Originally Posted by _ONH_ View Post
    No, as long as application developers don't implement the graphics features like in the spec., AMD needs to have workarounds for that programs insider der prop. driver, to not loose customer which use that programs. Given that the joke with nv dont get that many errors because they don't implement the spec that strict like amd does, but that my not apply to de oss driver.
    That may not always be a problem. Imagine what would happen if one day a really major player...say Valve...announced that they would only install the open AMD drivers after a certain date and that if game developers wanted their games to be performant, they would have to either follow the spec or provide the hacks in the game's code rather than in the driver.

    This may not be very likely, but I can dream, can't I?

  9. #59
    Join Date
    Jul 2012
    Posts
    819

    Default

    So if they pull this of catalyst might actually move back into the Arch Linux official repos. It was kicked out since it was to much of a PITA to maintain in a rolling release distro.

  10. #60

    Default Well done

    Good exclusive. Very promising news.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •