Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 42

Thread: AMD vs NVIDIA drivers, that big difference?

  1. #31
    Join Date
    Sep 2007
    Posts
    1,001

    Default

    Quote Originally Posted by bridgman View Post
    Hardware Acceleration on Evergreen/HD5xxx is almost at the same level as 6xx/7xx, with the caveat that acceleration is only supported when running with KMS. As of yesterday there were known issues related to mipmap support and stencil buffer handling.

    Andre just committed a fix related to lodbias (lodbias affects which level of the mipmap is selected when texturing), not sure how much of the mipmap issue that addreses. Looks like the fix should get rid of some unpredictable behaviour, so at worst it will probably make the remaining issues easier to diagnose and fix.
    KMS is work in progress? There's a lot of discussion and topics of disabling KMS for various reasons including getting a black screen on bootup. If there's major revisions of the kernel, is KMS particularly effected?

    I read this:
    http://www.h-online.com/open/feature...s-1065375.html

    I guess that's more open source driver related but for me, I'm wondering about the options of using the binary v.s. open driver. Not a question just stating what I'm mulling over.

  2. #32
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,570

    Default

    KMS is work in progress?
    I don't really understand the question about KMS being a work in progress. What I said was that the acceleration code only includes code paths for KMS.

    There's a lot of discussion and topics of disabling KMS for various reasons including getting a black screen on bootup.
    Having the ability to disable KMS and fall back to UMS is handy if a problem with KMS is discovered on a specific system, but the developers would much rather spend their time dealing with KMS issues than duplicating effort to maintain UMS code paths with DRI1 and memory management in the userspace code rather than kernel. When KMS was first launched it only worked on a small set of systems (like all new things) but a year later it is the default for most new distro releases and problems are becoming relatively rare.

    If there's major revisions of the kernel, is KMS particularly effected?
    KMS should be almost completely independent of kernel changes AFAIK -- it's really the memory management and the code that was already in the kernel which is most sensitive to kernel updates.

    The article was a bit off near the end... it talked about the Evergreen code being "still located in various development branches", but there is only one branch (evergreen accel branch of xf86-video-ati, created only because there was a release in progress out of master at the time) and all of the other code is in master for the 3D and kernel drivers. I guess maybe it was saying "the code is scattered across all these projects" but that's just how the open source driver code is managed.

    I guess that's more open source driver related but for me, I'm wondering about ...
    We were talking about the open drivers, so that's fine -- at least I assumed you were talking about the open drivers because of the reference to hardware acceleration. The fglrx driver had hardware acceleration for Evergreen when the family was launched.

  3. #33
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by LinuxID10T View Post
    When I originally tested the first Unigine for linux, tesselation did work on my 4650 or 4350, however, it was BEYOND SLOW. Now, tesselation on those older cards is broken.
    no its just removed because complette incompatible codepath

    and the hd2000-hd4000 code path is totally broken. many graphic effects can't be shown because of this oldscool trueform tesselation unist the unit is just in the wrong place of the chip
    one of the biggest bug is a speed bug you never get any playable fps tesselation speed out of a hd2000-4000

    in my point of view its just microsoft and directX11 they force to get complette incompatible 'NEW' hardware for dx11.

    this 'NEW' makes the old hd2000-4000 tesselation units complette unusable

  4. #34
    Join Date
    Sep 2007
    Posts
    1,001

    Default

    Quote Originally Posted by bridgman View Post
    I don't really understand the question about KMS being a work in progress. What I said was that the acceleration code only includes code paths for KMS.

    Having the ability to disable KMS and fall back to UMS is handy if a problem with KMS is discovered on a specific system, but the developers would much rather spend their time dealing with KMS issues than duplicating effort to maintain UMS code paths with DRI1 and memory management in the userspace code rather than kernel. When KMS was first launched it only worked on a small set of systems (like all new things) but a year later it is the default for most new distro releases and problems are becoming relatively rare.
    You answered the question, thanks. I was just speculating whether work on KMS was particularly complicated. I have read here and there of discussion about disabling KMS and I was wondering why it seems to be a task done somewhat often. I was wondering if changes to KMS might result in problems that influence a user into disabling KMS. Glad to hear the current state is one in which problems are rare.

    Quote Originally Posted by bridgman View Post
    KMS should be almost completely independent of kernel changes AFAIK -- it's really the memory management and the code that was already in the kernel which is most sensitive to kernel updates.
    Okay, good to know.

    Quote Originally Posted by bridgman View Post
    I guess maybe it was saying "the code is scattered across all these projects" but that's just how the open source driver code is managed.
    I was interested in getting an analysis of the article so thanks.

    Quote Originally Posted by bridgman View Post
    We were talking about the open drivers, so that's fine -- at least I assumed you were talking about the open drivers because of the reference to hardware acceleration. The fglrx driver had hardware acceleration for Evergreen when the family was launched.
    I think it's safe to say I was aware of that. Yes, we were talking about the open drivers but I thought it was time to include closed drivers in the discussion since we're in the binary section of the forum. I read a post of yours relating to the complexity of having both types of drivers 'installed' at the same time or should I say 'able to co-exist?' I hope this can be accomplished; it would be very convenient for users, right? I'm just mentioning it because there are owners of the card who want certain features and they might have to switch back and forth just because they want a certain feature. Even if the plan is to have the FOSS drivers implement "most" (?) of the features, they might have to wait. I believe I would include myself in that group. It depends on what's working and what I wish to do, of course.

    Thanks for the replies. I hope those are questions that weren't answered before. I also want to assure anyone who's tired of my questions that I'd do my best to contribute if I ultimately buy an ATI card.

  5. #35
    Join Date
    Mar 2009
    Posts
    214

    Default

    Quote Originally Posted by Glaucous View Post
    I've been using AMD/ATI HD4870 on Kubuntu x64 for a while now, and then I decided to try out (borrowed) NVIDIA GTX 260 - which is a slightly worse card (on Windows). I also tried NVIDIA 8600 GT which is a quite crappy card.

    The results were quite sad, and I'm considering that I failed (Multiple times? Seems odd.) with the AMD/ATI drivers. Please note that glxgears isn't much of a benchmark, but it does show me something.

    fgl_glxgears
    5500 FPS NVIDIA GTX 260
    2100 FPS NVIDIA 8600 GT
    2200 FPS ATI HD4870

    glxgears
    110k frames / 5 seconds - GTX 260
    40k frames / 5 seconds - HD4870 and 8600 GT


    Here sure is a big difference.

    I also tried Wine World of Warcraft, which resulted in about 2-3 times more FPS on GTX 260. And the FPS on 8600 GT was as good or better than HD4870.
    I did try a small particle OpenGL program I wrote, which resulted in about two times more particles at higher FPS - on both NVIDIA cards (CPU bound) compared to HD4870.

    Do anyone else have any experience using ATI and NVIDIA? It feels like the performance on ATI should be better than this - or is this a common problem?
    I'm right now considering buying a NVIDIA Fermi card (as soon as Coolbits is working, and ETA yet?).

    NVIDIA Drivers:
    256.53
    ATI Drivers:
    10.8, 10.7, 10.5.
    Easy:
    nVidia knows how to write decent drivers, while ATI fails miserably at driver implementations. ATI's linux/X drivers are particularly bad, while their Windows drivers are mostly acceptable.

    fglrx has been one long trip to bugginess for me with linux, which means this is my first ATI GPU in almost 10y and the experience has been less than pleasing.
    Sager NP8250-S Core i7-4800MQ/780m/32GB/128GB SSD/750GB Scorpio Black/1TB WD Blue(7mm) (win7 x64 pro)
    Acer Chromebook C720(i3-4005U/4GB) 128GB SSD(stable/crouton xfce)
    DIY ASUS P9X79/i7-3930k/64GB/multiple multiple terabyte HDDs(mostly WD 10k)/780 Ti SC (win7 x64 pro/Ubuntu 14.10)
    DIY ASROCK 990FX Extreme9/FX-9590/32GB/multiple multi-TB hdds/R9 280X

  6. #36
    Join Date
    Oct 2007
    Posts
    912

    Default

    Quote Originally Posted by cutterjohn View Post
    Easy:
    nVidia knows how to write decent drivers, while ATI fails miserably at driver implementations. ATI's linux/X drivers are particularly bad, while their Windows drivers are mostly acceptable.

    fglrx has been one long trip to bugginess for me with linux, which means this is my first ATI GPU in almost 10y and the experience has been less than pleasing.
    I think you'll find both companies to be as bad or decent as each other.

  7. #37
    Join Date
    Sep 2007
    Posts
    1,001

    Default

    Quote Originally Posted by mirv View Post
    I think you'll find both companies to be as bad or decent as each other.
    The guy tested and compared three cards, two Nvidia and one ATI card.

    After the glxgears test, how do you figure the differences are negligible?

    Both companies may be bad or decent but the tests show a considerable difference due to drivers. In Windows, the HD 4870 would smoke the Nvidia 8600 card. It just shows a lack of attention by ATI to Linux drivers. This is shown again and again but no change. Just a lot of talk that things are being 'worked on.'

  8. #38
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,153

    Default

    Quote Originally Posted by Panix View Post
    After the glxgears test, how do you figure the differences are negligible?
    The difference between 40000fps and 100000fps is negligible. It's an improvement of 0.000015 seconds per frame or a reduction of 0.1% in frame time. Do you understand now why glxgears is not a benchmark? Those huge differences (60000fps OMGOMG!) translate into absolutely nothing.

    Why? Because fps are non-linear (15 vs 30fps is much more significant than 150 vs 300fps). You need to invert them before you can compare them directly.

  9. #39
    Join Date
    Jun 2009
    Posts
    2,937

    Default

    Quote Originally Posted by Panix View Post
    After the glxgears test, how do you figure the differences are negligible?
    Because GLXGEARS IS NOT A TEST. It is meaningless.

    Repeat this 100000 times before you post again. This is obvious trolling now.

  10. #40
    Join Date
    Sep 2007
    Posts
    1,001

    Default

    Quote Originally Posted by BlackStar View Post
    The difference between 40000fps and 100000fps is negligible. It's an improvement of 0.000015 seconds per frame or a reduction of 0.1% in frame time. Do you understand now why glxgears is not a benchmark? Those huge differences (60000fps OMGOMG!) translate into absolutely nothing.

    Why? Because fps are non-linear (15 vs 30fps is much more significant than 150 vs 300fps). You need to invert them before you can compare them directly.
    What test is useful then?

    I just thought it was noteworthy that the result is basically the same as an older inferior Nvidia card.

    Also, even if Wine is tailored to Nvidia cards, is it still insignificant that the ATI card performs no better than the 8600GT card?

    Maybe the poster should test with Nexuiz and Unigine? Maybe try Doom 3 and use the Test Suite???

Tags for this Thread

Posting Permissions

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