Announcement

Collapse
No announcement yet.

AMDGPU-PRO vs. RadeonSI/RADV & NVIDIA's Linux Drivers To End 2016

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

  • dungeon
    replied
    Originally posted by geearf View Post
    Well if both would optimize to the (pseudo-)max it'd be great
    He, he, it is actually opposite They should optimize for pseudo low, but maxed out you get for free on big on newer GPUs.

    When even low is slower and it is, it is bad port bound everywhere. More API bound, both more CPU and GPU bound. So they must bump system requirements as they do. That is how it is, if low is fine, system is fine, API is fine so everything is fine and on par with original. And again if low is fine drivers can fix it up too on high if needed, otherwise it will be slower forever.
    Last edited by dungeon; 31 December 2016, 02:45 AM.

    Leave a comment:


  • geearf
    replied
    Originally posted by dungeon View Post

    That is always chicken and egg question, drivers can always speed up something here and there. As either porter optimize for driver or driver optimize for the port. But should they do it or not and why should drivers do anything or not when porter can do it also, when we know that time fixes most of the issues and particulary new hardware - that is the question
    Well if both would optimize to the (pseudo-)max it'd be great

    Leave a comment:


  • dungeon
    replied
    Originally posted by geearf View Post
    Is it a port issue or a driver issue?
    That is always chicken and egg question, drivers can always speed up something here and there. As either porter optimize for driver or driver optimize for the port. But should they do it or not and why should drivers do anything or not when porter can do it also, when we know that time fixes most of the issues and particulary new hardware - that is the question
    Last edited by dungeon; 30 December 2016, 11:14 PM.

    Leave a comment:


  • geearf
    replied
    Originally posted by Night Nord View Post
    Deux Ex: MD performance on any card is some kind of a joke. I mean - it really not a problem with drivers. 4 FPS on low? What? No, someone needs to fix their port, but probably they are not going to...
    Is it a port issue or a driver issue?

    Leave a comment:


  • Night Nord
    replied
    Deux Ex: MD performance on any card is some kind of a joke. I mean - it really not a problem with drivers. 4 FPS on low? What? No, someone needs to fix their port, but probably they are not going to...

    Leave a comment:


  • boltronics
    replied
    Originally posted by orome View Post
    PRO driver supports features that FOSS driver does not. Some of those will never be supported by FOSS driver -- like compatibility profiles for OpenGL needed for some tools (mesa only gives you OpenGL 3.0 if you ask for compatibility profile).
    Never say never!

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by bridgman View Post
    I don't understand this statement - maybe half of our open source developer effort goes into the mesa drivers and the rest into the other components.
    I meant mesa as a whole, not the AMD drivers for mesa (obviously that is relevant). I was a bit vague there.

    Leave a comment:


  • bridgman
    replied
    Originally posted by schmidtbag View Post
    We're talking about software provided by AMD for AMD hardware, not the entire graphics stack. Tuxee asked why AMD has 2 different driver implementations. You're blowing the accuracy of my answer out of proportion, because mesa isn't relevant to the scope of the answer.
    I don't understand this statement - maybe half of our open source developer effort goes into the mesa drivers and the rest into the other components.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by orome View Post
    misquoting and pasting generic urls won't help you. I never said that FOSS driver includes closed components.
    Same could be said about you... you're misinterpreting something I never said and then disagreeing with it...
    I explicitly mentioned "short answer" and what you're focusing on is exactly the opposite.
    FOSS stack is Mesa + llvm + libdrm + radeon.ko/amdgpu.ko
    PRO stack is AMD-closed-GL + patched-amdgpu.ko
    We're talking about software provided by AMD for AMD hardware, not the entire graphics stack. Tuxee asked why AMD has 2 different driver implementations. You're blowing the accuracy of my answer out of proportion, because mesa isn't relevant to the scope of the answer.
    Look at it like this: if someone asks "what's the difference between a muffin and a cupcake?" the short answer is "cupcakes are desserts, muffins aren't". Meanwhile, you come along and say "wrong - muffins are sometimes desserts and they are baked at different temperatures". You're getting anal about details that don't matter to the question. Though the additional details aren't wrong, the person wasn't asking about how the pastries are made, and pointing out semantic differences is defeats the purpose of a short answer. Whenever someone says "short answer" it implies there is a lot more involved, including (but not limited to) caveats.

    Anyway.... all that being said, if you look at just the drivers, y'know, the thing Tuxee asked about, radeon/amdgpu (non-pro) is only kernel-level software. Feel free to post links proving me wrong.
    The reason to have AMD-closed-GL is to support features needed by CAD tools that will never be implemented in Mesa.
    My question was rhetorical. The amdgpu-pro driver is more than what you said and certainly not limited to CAD tools or workstations. It also involves the Vulkan drivers, it is more OpenCL ready, it involves disk shader caching, and so on.
    Last edited by schmidtbag; 29 December 2016, 10:51 AM.

    Leave a comment:


  • mannerov
    replied
    Originally posted by Screech View Post
    In Unigine Heaven in windows DX11 I get a score of 1300 and in linux opengl 900... A year has passed and the linux drivers are not close to windows performance... In windows with each major game you get new optimized drivers, in linux AMDGPU-PRO is updated once at 4 months and the drivers are still experimental/beta...
    unigine heaven uses slightly different rendering paths dx9 vs dx11 vs gl.

    For example lightning is computed differently. Looking at what it does dx9 vs gl you can notice for gl, rg32F buffers are used to store intermediate lightning computation, while dx9 uses argb32f (which is heavier to sample from on amd. If you replace by argb16f, with gallium nine you get significantly better dx9 performance than gl). The intermediate results stored in these buffers are not exactly the sames either. Very likely dx11 has yet a different lightning computation pass, and lightning is the heaviest pass on Heaven.

    Leave a comment:

Working...
X