Page 6 of 10 FirstFirst ... 45678 ... LastLast
Results 51 to 60 of 95

Thread: New AMD Catalyst Beta Supports Linux 3.8, TF2 Fixes

  1. #51
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,347

    Default

    Quote Originally Posted by Gps4l View Post
    Thank you, when I upgrade my vid card, I would prefer it to be an amd again.

    We all know how much nvidia does to improve the open source drivers....
    And although I do not use the open source drivers, for me as a Linux fan that does go a long way.

    But currently judging from the steam forums, it would be an bad idea.

    I am having fun with serious sam3, on Linux but I had to lower the resolution, on Linux.
    ( just to make clear, I am not whining over a few fps. )
    That sort of brought me to a sudden realization - what if AMD didn't focus on both the open source and Catalyst drivers? By splitting up development teams for open source and closed source, that basically means half the attention for both products. Personally, I'd rather they focus all on one and not the other. I would prefer focus on the open source drivers just so they get a chance to catch up (and because they support more hardware and OGL-unrelated software), but I also prefer focus on the Catalyst drivers because those are a much shorter distance from operating head-to-head with Windows. I personally use the Catalyst drivers - aside from having to hold back my xserver version, I don't seem to get ANY problems with it. I think much of the complaining about Catalyst is from un-knowledgeable users or people who like to linger on past errors. This is a shame, considering Linux itself is suspect to those problems, so you'd think it's own users would realize this.

    On the other hand, AMD could also just hire more devs, but we all know they can't afford that yet.

  2. #52
    Join Date
    Aug 2009
    Posts
    152

    Default

    Quote Originally Posted by schmidtbag View Post
    That sort of brought me to a sudden realization - what if AMD didn't focus on both the open source and Catalyst drivers? By splitting up development teams for open source and closed source, that basically means half the attention for both products. Personally, I'd rather they focus all on one and not the other. I would prefer focus on the open source drivers just so they get a chance to catch up (and because they support more hardware and OGL-unrelated software), but I also prefer focus on the Catalyst drivers because those are a much shorter distance from operating head-to-head with Windows. I personally use the Catalyst drivers - aside from having to hold back my xserver version, I don't seem to get ANY problems with it. I think much of the complaining about Catalyst is from un-knowledgeable users or people who like to linger on past errors. This is a shame, considering Linux itself is suspect to those problems, so you'd think it's own users would realize this.

    On the other hand, AMD could also just hire more devs, but we all know they can't afford that yet.
    The team working on the Linux side of Catalyst shares its code base with the Windows version. It is not like they spend a huge amount of resources on the Linux driver. Most things OpenGL related are shared between the supported operating systems. By spending a small amount of resources on the Linux Catalyst version they get the benefit thousands of hours spent into the Windows version.

    More devs would work

  3. #53
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    917

    Default

    Quote Originally Posted by Silverthorn View Post
    The team working on the Linux side of Catalyst shares its code base with the Windows version.
    It is not like they spend a huge amount of resources on the Linux driver. Most things OpenGL related are shared between the
    supported operating systems. By spending a small amount of resources on the Linux Catalyst version they get the benefit
    thousands of hours spent into the Windows version.
    The majority of bug reports filed under http://ati.cchtml.com are indeed platform-specific
    issues (X, VT switching, GPU switching, XVBA), not related to the shared OpenGL portion.

  4. #54
    Join Date
    Aug 2007
    Posts
    6,634

    Default

    The ss3 opengl speed issues are NOT linux specific, they are crossplattform, you can change the renderer to opengl on windows too (not via the menu however). The decreased speed affects nvidia as well, the flickering textures are ati only however. They can be fixed when you press alt+enter twice as soon as you are in the menu and NOT in a level, when you do it in a level you can forget everything, then it is unplayable slow.

  5. #55
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    917

    Default

    Quote Originally Posted by Kano View Post
    The ss3 opengl speed issues are NOT linux specific, they are crossplattform, you can change the renderer to opengl on windows too (not via the menu however). The decreased speed affects nvidia as well, the flickering textures are ati only however. They can be fixed when you press alt+enter twice as soon as you are in the menu and NOT in a level, when you do it in a level you can forget everything, then it is unplayable slow.
    Are you replying to me?
    Who said those OpenGL bugs are Linux specific?

    Edit: My point was that the "apparently" little effort of Linux-specific code provide for most of the woes.
    I don't think it's little effort. At least it doesn't look like.
    Ok, it could be that only two guys hacking that X11-related stuff...
    Last edited by entropy; 04-16-2013 at 10:56 AM.

  6. #56
    Join Date
    Oct 2010
    Location
    Amsterdam
    Posts
    295

    Default

    Quote Originally Posted by Kano View Post
    The ss3 opengl speed issues are NOT linux specific, they are crossplattform, you can change the renderer to opengl on windows too (not via the menu however). The decreased speed affects nvidia as well, the flickering textures are ati only however. They can be fixed when you press alt+enter twice as soon as you are in the menu and NOT in a level, when you do it in a level you can forget everything, then it is unplayable slow.
    From the steam Linux forums, I know this to be true.

    I have not tried it myself, but the opengl performance is on windows as bad as on Linux.
    A few steam on Linux users have tested it.

    I only compared opengl on Linux with Dx on windows.
    As soon as more enemies show up, I do not really notice a difference on windows,
    on Linux however I have a total cave in, of the fps.

    Something about Croteam, I posted problems I had with ss3, on the steam forum for serious sam3.
    I got a reply within 24 hours..... They tried to help, and I am on openSUSE.

    Some companies care about their customers.
    If amd does, then they are damn good in hiding it.

    And what really makes me sad, Valve has published a few articles, they explained why games should run faster on Linux.
    Not by much though just a few fps.

    http://blogs.valvesoftware.com/linux/
    Faster zombies

    When we started with Linux, the initial version we got up and running was at 6 FPS. This is typical of an initial successful port to a new platform.
    Performance improvements fall into several categories:

    Modifying our game to work better with the kernel
    Modifying our game to work better with OpenGL
    Optimizing the graphics driver

    OpenGL versus Direct3D on Windows 7

    This experience lead to the question: why does an OpenGL version of our game run faster than Direct3D on Windows 7? It appears that itís not related to multitasking overhead. We have been doing some fairly close analysis and it comes down to a few additional microseconds overhead per batch in Direct3D which does not affect OpenGL on Windows. Now that we know the hardware is capable of more performance, we will go back and figure out how to mitigate this effect under Direct3D.
    The last line shows the advantage of opensource software.

  7. #57
    Join Date
    Jan 2013
    Posts
    991

    Default

    Quote Originally Posted by Gps4l View Post
    The last line shows the advantage of opensource software.
    Use opensource software to find bugs and improve proprietary. Or what?
    Its Intel who is pushing whole opensource driver stack, nobody else.

  8. #58
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Quote Originally Posted by schmidtbag View Post
    On the other hand, AMD could also just hire more devs, but we all know they can't afford that yet.
    Isn't this way of thinking part of the problem? AMD now has a bad image for Linux gamers because they don't have enough driver developers to actually deliver a sufficient product. So not having enough developers furthers their money problems. They should hire developers to get a better product in the long run instead of saving money now with having to pay fewer developers, but lowering product quality.

  9. #59
    Join Date
    Aug 2007
    Posts
    6,634

    Default

    @Gps4l

    You should know that intel+nvidia have got access to source engine code, if needed they could tell the devs how to increase speed that it works best with their drivers. I don't know if amd has got access and if they are willing to do the same.

  10. #60
    Join Date
    Oct 2010
    Location
    Amsterdam
    Posts
    295

    Default

    Quote Originally Posted by brosis View Post
    Use opensource software to find bugs and improve proprietary. Or what?
    Its Intel who is pushing whole opensource driver stack, nobody else.
    They found out, because opengl is opensource, the hardware could be faster. That they also used it to improve the dx performance is right, but that's not the point I was trying to make.

    I believe intel has the best Linux drivers, too bad they don't make vid cards.

    For heavy games, the onboard graphic chips, arent fast enough.

Posting Permissions

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