Announcement

Collapse
No announcement yet.

AMD Creates Radeon Technologies Group To Focus On Graphics

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

  • duby229
    replied
    Originally posted by bridgman View Post

    The only obligation to Microsoft and other OS vendors is not including their NDA driver development kit IP or derivatives in our open source drivers, but that pretty much requires that we have a separate code base for OSS drivers. We can ship code-shared drivers in binary form, which is why you see "Hybrid Pro" as well as "All-Open" in our driver roadmaps.



    Yeah, drivers are code shared across multiple OSes so unfortunately when decision to drop support for the OS with ~90% of market share happens (which is relatively easy because that OS has a stable driver ABI) the other OSes (which may not have stable driver ABIs) have to go along for the ride whether they like it or not.

    Things would be easier if Linux had 90% of the market or at least had equivalent ABI stability to Windows, but unfortunately neither are true. On the other hand I think it is fair to say that the OSS drivers caught up fairly quickly after Catalyst Linux support was dropped.
    Yeah, I have to agree about the stable driver interface. I don't think it should never change, but I do thin it should be version controlled at major revisions.

    Leave a comment:


  • bridgman
    replied
    Originally posted by Slartifartblast View Post
    1) There are probably NDA agreements with Microsoft and other parties regarding drivers so that's why FOSS get saddled with a firmware + some opensource code drivers which are always miles behind feature wise and always will be because it still requires the whim of the manufacturer to supply that firmware and documents.
    The only obligation to Microsoft and other OS vendors is not including their NDA driver development kit IP or derivatives in our open source drivers, but that pretty much requires that we have a separate code base for OSS drivers. We can ship code-shared drivers in binary form, which is why you see "Hybrid Pro" as well as "All-Open" in our driver roadmaps.

    Originally posted by Slartifartblast View Post
    2) AMD dropped Xorg support like a stone for HD4000 only a couple of years or so from releasing the HD4000 and the FOSS drivers were a sorry sack of sh1te at the time.
    Yeah, drivers are code shared across multiple OSes so unfortunately when decision to drop support for the OS with ~90% of market share happens (which is relatively easy because that OS has a stable driver ABI) the other OSes (which may not have stable driver ABIs) have to go along for the ride whether they like it or not.

    Things would be easier if Linux had 90% of the market or at least had equivalent ABI stability to Windows, but unfortunately neither are true. On the other hand I think it is fair to say that the OSS drivers caught up fairly quickly after Catalyst Linux support was dropped.

    Leave a comment:


  • Slartifartblast
    replied
    Originally posted by wdb974 View Post
    Anyhow, I see no reason to focus either on Windows or proprietary drivers here. This is a Linux website, after all. We should focus on open source software and participate as much as we can if we're unhappy with the current state of things.
    Let's deal with a couple of those points:

    1) There are probably NDA agreements with Microsoft and other parties regarding drivers so that's why FOSS get saddled with a firmware + some opensource code drivers which are always miles behind feature wise and always will be because it still requires the whim of the manufacturer to supply that firmware and documents.

    2) AMD dropped Xorg support like a stone for HD4000 only a couple of years or so from releasing the HD4000 and the FOSS drivers were a sorry sack of sh1te at the time.

    3) The Linux graphics stack is a fragmented nightmare to support.

    Leave a comment:


  • bug77
    replied
    Originally posted by Kano View Post
    Maybe it helps to focus AMD on the GFX part. GF seems to have problems with 14 nm - Zen will take longer. Would be interesting to see if the 2nd generation of HBM from AMD will beat Nvidia's first try..
    Yup, I'm pretty sure AMD knows best what works for them. We're just commenting here based on bits and pieces we know from the press, but they do have the whole picture.

    Leave a comment:


  • Kano
    replied
    Maybe it helps to focus AMD on the GFX part. GF seems to have problems with 14 nm - Zen will take longer. Would be interesting to see if the 2nd generation of HBM from AMD will beat Nvidia's first try..

    Leave a comment:


  • bridgman
    replied
    Yep, my bad -- I included one more sentence (at the start) in the quote than I intended.

    I was just talking about your comments re: ATI and open source drivers.
    Last edited by bridgman; 09-10-2015, 11:32 AM.

    Leave a comment:


  • bug77
    replied
    Originally posted by bridgman View Post

    Sounds great but totally wrong. ATI supported development of open source drivers from Mach64 days through R200 and early R300. At that point we bought FireGL, picked up a closed source workstation driver as part of the deal, and started using that driver (which turned into Linux Catalyst) across the board for workstation and client.
    Well, it's not totally wrong, because ATI/AMD's OpenGL performance has always lagged behind Nvidia's. And Catalyst releases have always trailed behind X releases.
    While OpenGL performance issues I can understand, not having a plan to support X releases on the same day is just carelessness, imho.

    Leave a comment:


  • Ancurio
    replied
    Originally posted by gigaplex View Post
    Are you sure about that? I thought they were unified shader cores.
    Edit: Sorry, did you mean unified as in "unified graphics compute cores"? Because there's already the term "Unified Shader Architecture" which refers to running both vertex and fragment shaders on the same hardware units. But in any case, I do believe AMD cards have cores that specifically only have access to compute, not graphics.

    But looking over this article again it seems I might have been slightly confused about the cores, since not each one of them represents a queue by themselves. Instead, queues themselves are represented in hardware as "engines" or "command processors". Crucially, earlier NVidia cards did not have separate graphics and compute engines, so the work had to be interleaved (which wasn't a problem because of the guarantees of OpenGL/D3D11 I talked about), but Vulkan/D3D12 exposes the engines directly as Queues, so AMD GCN cards can schedule both types of tasks in parallel.

    However looks like starting with Maxwell 2 (900 series), Nvidia does have separate graphics and compute engines, so async compute shouldn't give AMD such a big edge when compared against that hardware.
    Last edited by Ancurio; 09-10-2015, 11:02 AM.

    Leave a comment:


  • AJSB
    replied
    OOOHH YES, Nvidia is "so" "good"...

    Some might know this...BATTLEFIELD 2...Black holes on the ground
    Doesn't matter if you play in XP, W7, W8 or Linux via WINE....Nvidia NEVER fixed it AFAIK...

    OTOH, playing BF2 under AMD iGPUs...ZERO black holes EVER, no matter playing in XP, W7, W8 or Linux via WINE.

    Funny fact ? It's a Nvidia game

    Leave a comment:


  • bridgman
    replied
    Originally posted by BSDude View Post
    Either your memory is short or you're just too young but Catalyst was shit from the very begining. During the ATI days it wasn't any better. For one, being part of AMD has put ATI on the path towards open-source. A slow, painful path but nonetheless the right one. No way ATI would have created OSS drivers as an independent company.
    Sounds great but totally wrong. ATI supported development of open source drivers from Mach64 days through R200 and early R300. At that point we bought FireGL, picked up a closed source workstation driver as part of the deal, and started using that driver (which turned into Linux Catalyst) across the board for workstation and client.

    Leave a comment:

Working...
X