Announcement

Collapse
No announcement yet.

More Radeon Driver Changes Queued For Linux 3.19

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

  • smitty3268
    replied
    Originally posted by smitty3268 View Post
    It's fairly safe to say that the older Valve games are not particularly well optimized for GL, but it's not accurate to say that they are using some kind of runtime shim like WINE. It's all compiled down to native OpenGL in the game ahead of time.
    In other words, you can think of it a lot like a console port to the PC. It was done quickly in order to get things working, and is "native", but underneath the code is still designed to be running on a console and so it's not a particularly good port.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Jabberwocky View Post
    Thanks for correcting me, although it would be nice to have some references. I don't know how ToGL works at all . I based my assumption on https://github.com/ValveSoftware/Dota-2/issues/774 and personal experience of extremely bad performance (10man battles kills my pc) and long loading time on the Dota 2 native client. While other native games ran close/better than to windows performance I have not tested Dota 2 in the past 8 months.

    Although I would like to know what the cause is and not just blame things randomly, the message I'm trying to get out is that games are not optimized for linux in fact it's the other way around. That just makes me sad. That said, I love how well steam works on Linux , lets hope my complete gaming experience changes in the future!
    DOTA has a ton of shaders compared to most games - which are actually native GLSL, though machine generated which means they can sometimes do silly things - and the Mesa GLSL compiler in particular is not very fast at compiling. That's what is leading to the slow startup times. There is work underway to improve Mesa's compile times, and many of the GL4 features being added should also help porters.

    I'm not sure if Dota uses SSO, which commonly means that things which were fast in DX become slow in GL without large changes made to how the code works. Or if Mesa had support for it at the time that testing was done. (It's a GL4.2 feature, i think added in 10.2?)

    It's fairly safe to say that the older Valve games are not particularly well optimized for GL, but it's not accurate to say that they are using some kind of runtime shim like WINE. It's all compiled down to native OpenGL in the game ahead of time.
    Last edited by smitty3268; 26 November 2014, 03:51 AM.

    Leave a comment:


  • Jabberwocky
    replied
    Originally posted by smitty3268 View Post
    I don't think that's a very accurate description of ToGL.

    If anything, it converts the calls at compile time.
    Thanks for correcting me, although it would be nice to have some references. I don't know how ToGL works at all . I based my assumption on https://github.com/ValveSoftware/Dota-2/issues/774 and personal experience of extremely bad performance (10man battles kills my pc) and long loading time on the Dota 2 native client. While other native games ran close/better than to windows performance I have not tested Dota 2 in the past 8 months.

    Although I would like to know what the cause is and not just blame things randomly, the message I'm trying to get out is that games are not optimized for linux in fact it's the other way around. That just makes me sad. That said, I love how well steam works on Linux , lets hope my complete gaming experience changes in the future!

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Jabberwocky View Post
    This is true for games like Dota, not optimised for non-Windows platforms. It uses d3d to opengl "converter" which converts the calls at runtime.
    I don't think that's a very accurate description of ToGL.

    If anything, it converts the calls at compile time.

    Leave a comment:


  • Jabberwocky
    replied
    Originally posted by edoantonioco View Post
    I guess it's technically possible to get the windows performance on the open source driver, but that would mean to invest a lot of more time on it, and to put code than its not easy to maintain across the future (I have read this in this same forum time ago). Or maybe the fault is because the games are not optimized enough.
    This is true for games like Dota, not optimised for non-Windows platforms. It uses d3d to opengl "converter" which converts the calls at runtime.

    Leave a comment:


  • curaga
    replied
    You don't mention what you consider real use. What is it, how bad, and are bugs open?

    Leave a comment:


  • dungeon
    replied
    Originally posted by eydee View Post
    I have a 6850 which is ancient enough so that the driver stack shouldn't matter, it's no longer optimized.
    Older chips might have driver regressions, if no one tested them from time to time... it would be broken sooner or later .

    The difference is probably due to Michael using ultra high end CPUs in the benchmark, and one of the main culprits of the open source driver is CPU and GPU usage.
    I don't think here CPU used is problem, whatever CPU he use performance will not go down to 30% as you said well just look nouveu benchmarks now with same CPU... for nouveu it clearly shows problematic chips so lowest average there is at 7%:

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


    It doesn't reflect real life situations, at least not what I consider real life...
    Well he can't test all CPUs and GPUs people use at the same time
    Last edited by dungeon; 21 November 2014, 04:59 PM.

    Leave a comment:


  • eydee
    replied
    Originally posted by dungeon View Post
    Recent phoronix benchmarks for two source engine based games shows lowest average comparation case is @60%

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


    Is your graphics driver stack recent enough? Which chip you use? Did you fill bug about that performance issue? etc.
    I have a 6850 which is ancient enough so that the driver stack shouldn't matter, it's no longer optimized. The difference is probably due to Michael using ultra high end CPUs in the benchmark, and one of the main culprits of the open source driver is CPU and GPU usage. It doesn't reflect real life situations, at least not what I consider real life...

    Leave a comment:


  • V10lator
    replied
    Originally posted by gutigen View Post
    And on-disk shader cache to at least lower loading times which are quite huge in comparison to Catalyst and Nvidia.
    Don't put all your hopes on that. A cache helps a bit but it doesn't seem to be the main bottleneck. I know that cause I'm one of the guys who tested the last round of patches and these where my results (loading time of Left 4 Dead 2) :

    Empty cache: 54 secs
    Cache on HDD: 52 secs
    Cache on SSD: 48 secs
    Cache on ramdisk: 48 secs

    The tested system:
    GPU: Sapphire Radeon HD 6950 (Dirt II Edition) with unlocked shaders
    CPU: AMD Athlon(tm) II X3 455 overclocked to 3,5 GHz
    HDD: WDC WD2002FAEX-007BA0
    SSD: Corsair CSSD-R120GB2

    See also: http://lists.freedesktop.org/archive...ne/061299.html

    Leave a comment:


  • geearf
    replied
    Originally posted by smitty3268 View Post
    That guy submitted some initial patches, and basically was told to completely rewrite how everything worked by the Mesa devs.

    No one heard anything more for about 9 months, and then he came back with another big patchset.

    Although it was a lot closer, the Mesa devs again gave him a lot of comments about changes they wanted.

    And now no one has heard anything more for about 6 months, or whenever that came up.

    So, presumably the guy is sort of working on it in his free time whenever he gets a week free, but that doesn't happen very often. Or maybe he's just given up. No one knows.
    Thanks for the information!
    Though, I suppose it doesn't really give us a timeline in the end

    Leave a comment:

Working...
X