Announcement

Collapse
No announcement yet.

Internal Multi-Threading Arrives For Gallium3D's Direct3D 9 "Nine"

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

  • duby229
    replied
    Originally posted by nuetzel View Post

    Did you read (overfly) the AMD paper?



    It seems... --- Nevermind, you've got it. 8-)
    Ok, so I've been doing some reading, and it seems like I am absolutely correct when talking about d3d9 or OpenGL, but when talking about dx11 I'm not correct. It seems dx11 has all the needed functions to allow game engines to multithread their loads appropriately, so what we are talking about here won't even be a problem for dx11 titles that use the deferred mode.

    In other words, command stream multithreading will not increase gpu throughput on d3d9 or Opengl, but can increase CPU throughput. Unlike DX11 the actual GPU performance won't change on d3d9 or OpenGL. So on DX11 you can implement a combination of driver level command stream multithreading with game engine level multithreading because the api was designed to allow it.
    Last edited by duby229; 08 December 2016, 04:06 PM.

    Leave a comment:


  • nuetzel
    replied
    Originally posted by duby229 View Post
    Axel Davy is a lot more prominent than I am so I'd say if he says so, then yeah, go with his experiences.
    Did you read (overfly) the AMD paper?

    On the hand, you can only extract parallelism from very specific snippets and it doesn't seem to make sense to try the same techniques from two different entry points. It seems logical that it would only cause interference patterns.
    It seems... --- Nevermind, you've got it. 8-)

    Leave a comment:


  • duby229
    replied
    Originally posted by nuetzel View Post

    'Or' --- Are you sure ?

    You can implement it in _both_.: http://developer.amd.com/wordpress/m...ATIMThread.pdf

    Post from Axel Davy (to me on Mesa-devel):
    Axel Davy is a lot more prominent than I am so I'd say if he says so, then yeah, go with his experiences. On the hand, you can only extract parallelism from very specific snippets and it doesn't seem to make sense to try the same techniques from two different entry points. It seems logical that it would only cause interference patterns.

    Leave a comment:


  • nuetzel
    replied
    Originally posted by PadreAdamo View Post
    Is there a way to donate to the Gallium Nine team/project? I use it everyday and would like to pay it forward. I'm not a developer so the only way I can provide my gratitude and appreciation is to donate, spread the word (I managed to get four of my friends to switch to GNU/Linux), and provide support for the one game I do play on WineHQ (Guild Wars 2). As always, thank you Gallium Nine team!
    Ask Axel, about?

    You can found his email on his post on Mesa-devel:
    Mesa-dev] [PATCH 00/84] Introduce gallium nine internal multithreading

    https://lists.freedesktop.org/archiv...er/137643.html

    Greetings,
    Dieter

    Leave a comment:


  • nuetzel
    replied
    Originally posted by duby229 View Post

    There are only two places you can implement multithreading, the graphics driver or the game engine.
    'Or' --- Are you sure ?

    You can implement it in _both_.: http://developer.amd.com/wordpress/m...ATIMThread.pdf

    Post from Axel Davy (to me on Mesa-devel):

    I observe a 15% improvement on hl2 lost coast when configured to be cpu bound.

    Other games benefit with various percentages (see for example http://www.gearsongallium.com/?p=3522 with an older patchset), but it seems to be around 10-20% for cpu limited scenarios.


    If the game is not cpu limited, but gpu limited, there is no gain (as expected).


    Axel

    Leave a comment:


  • haagch
    replied
    Originally posted by Passso View Post
    I love the way you write that it is as stable as Wine and then put a perfect example to prove it is not
    It's a null pointer dereference in wine's pulseaudio code. It's not obvious how this would be gallium nine's fault, but I do believe it only happens on nine master and not on mesa upstream master, so I'll look into it.
    Could be a race condition that is only exposed with nine because with wined3d csmt it runs at so high cpu load and so low fps.

    Leave a comment:


  • LinuxID10T
    replied
    Originally posted by duby229 View Post

    There are only two places you can implement multithreading, the graphics driver or the game engine. And I hate to say this, but in situations where the graphics driver is mutithreading and the game engine is unaware of it, very retarded things have to occur...... Look into it, I think you'll agree.

    It is definitely not beautiful. I'm not against this happening, it's just the ass backwards way of doing this.
    I'm aware. Look at the benchmarks when Nvidia first released this feature. It is somewhere way back in time on Phoronix. Testing was done on the latest bleeding edge GTX 9XXX series. That being said though, look at their driver situation now...

    Leave a comment:


  • PadreAdamo
    replied
    Originally posted by duby229 View Post

    Nice! Now that's a good example for non-developer enthusiasts. People don't have to be zealots about open source, instead just pick out a project and support it in any way you can.
    I'm reading some programming books, but that's a long way off!

    Leave a comment:


  • duby229
    replied
    Originally posted by PadreAdamo View Post
    Where can I donate to this project? I use it exclusively to play Guild Wars 2. Because of Gallium Nine I was able to switch four of my friends from Windows to GNU/Linux. I don't have any programming skills so the least I can do is spread the word, document continuously regarding Guild Wars 2 (which I do on WineHQ), and donate to the project.
    Nice! Now that's a good example for non-developer enthusiasts. People don't have to be zealots about open source, instead just pick out a project and support it in any way you can.

    Leave a comment:


  • geearf
    replied
    Originally posted by mannerov View Post

    I think what's blocking for csmt in wine is that the devs haven't had time so far to make the cleanups they wanted to the patchset, and instead just rebased it years over years over their wine changes. I don't think however it must have been harder to implement that it has been for nine.
    Oh I see, that would explain it, though blocking a new feature that useful not for weeks but years because of cleanup seems strange... but it's not like that would be the first strange decision there.

    Thank you for the answer, and for the major patchsets!

    Leave a comment:

Working...
X