Page 4 of 7 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 61

Thread: Wine's Big Command Stream D3D Patch-Set Updated

  1. #31
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    239

    Default

    Quote Originally Posted by justmy2cents View Post
    did more testing and i'm yet to see any of my games to crash. although, once i saw the GPU bottleneck comment, i went and disabled double buffering in TR2013

    wine-1.7.10 => min 30.9 fps, with double buffering min 25.9
    command stream version => min 48.9/max 72.3, with double buffering 30.1/60

    looking at reported fps when running on windows with same GPU as me, it's about 80-90% there. that's freaking awesome change.

    now, question from complete n00b on directx department. is this able to be reused in DX10/11 and how much different those 2 are?
    I don't know about the architecture of dx3d but of wines, some parts of wine_direct_3d is version independent and as saw this changes where done in its core and not in the specific dxd39 parts: so yes.

  2. #32

    Default

    Quote Originally Posted by TemplarGR View Post
    You state the obvious here. Of course the problem with Wine is CPU performance, it is an emulation layer that translates d3d to opengl, it will introduce severe cpu overhead... You didn't need tests to figure that out...
    Always test your assumptions. Never make decisions based on gut feelings and hearsay you cannot verify. At very least a benchmark will serve as a backup if you get into discussions with a jerk like me who wants to make sure you know what you're doing.

    Quote Originally Posted by TemplarGR View Post
    The problem with modern cpus, is that they cannot improve per core performance fast enough to keep up with gpu performance. So anything that reduces cpu strain will be vastly important from now on.
    This is not true as a general statement. Believe me, I've run plenty of benchmarks, and even the current single-threaded wined3d manages to exhaust some GPUs. It really depends on the application, the strength of the GPU and CPU, the application settings, here especially the resolution and antialiasing. An example here are the fairly weak Geforce 9600 and GTX 650M GPUs in my Macbooks. At HD resolutions with MSAA disabled the GPUs can't keep up, even with current Wine. Some game examples: StarCraft 2 lowest settings, all source engine games, not even ancient 3DMark2001.

    But overall I agree, and it's why I have written the command stream patches. Our problems are more on the CPU than GPU side. On the GPU we reach pretty much native speed on Nvidia cards with the proprietary driver. r600g doesn't get anywhere close, and neither do fglrx or OSX. See my FOSDEM presentation from last year.

    Quote Originally Posted by TemplarGR View Post
    That is why AMD introduced MANTLE afterall.
    I don't know. All I've heard so far about MANTLE is hype. I have not seen any API documentation and have not been able to run any benchmarks myself. All I can think of it right now is that AMD is trying to establish its own proprietary API to get some vendor lock-in. As a game developer, I would be very careful before using it.

    Quote Originally Posted by TemplarGR View Post
    So, Wine could use anything that can improve its performance. A D3D state tracker can eliminate this overhead altogether if properly coded. Although it is not multiplatform, it could provide a big boost for gallium users. Especially with modern games. Imagine games like Rome 2 total war. I am willing to bet a huge sum of money that Wine will face a tremendous challenge in trying to match its Windows performance...
    You'll have to specify your bet in more detail. There are dozens of factors that affect performance. E.g. my command stream work beats Windows in 3dmark2001 on nvidia. On other OSes / drivers there are driver problems. In other games, Wine has problems outside the d3d code. In some cases (e.g. good old Empire Earth 1) there are still problems in our d3d code that won't go away anytime soon.

    A statement like "Wine can match Windows performance" will have to be evaluated on a game by game, OS by OS, driver by driver basis for a LONG time to come. Maybe forever.

    My main point wrt a d3d9 mesa state tracker is not that it won't improve performance, but that it is, at the moment, an inefficient use of our time. The command stream which works everywhere has a much bigger impact. And no, we won't just put a random piece of code into our codebase. If we do that, we have to support and maintain it. Again, inefficient use of our time.

  3. #33

    Default

    Quote Originally Posted by justmy2cents View Post
    now, question from complete n00b on directx department. is this able to be reused in DX10/11 and how much different those 2 are?
    Yes, it can be reused. In fact, a big consideration in my work to merge this upstream is how this will interact with wined3d changes needed to support d3d10/11.

  4. #34
    Join Date
    Oct 2013
    Posts
    366

    Default

    Quote Originally Posted by stefandoesinger View Post
    Yes, it can be reused. In fact, a big consideration in my work to merge this upstream is how this will interact with wined3d changes needed to support d3d10/11.
    that's nice to hear. keep on the good work

  5. #35
    Join Date
    Jan 2014
    Posts
    6

    Default

    excuse me for stupid questions, is this patch-set have effect only for open-source drivers? & this github wine version and crossover 13 from codeveawers are identical?

  6. #36
    Join Date
    Oct 2013
    Posts
    366

    Default

    Quote Originally Posted by OnioWoess View Post
    excuse me for stupid questions, is this patch-set have effect only for open-source drivers? & this github wine version and crossover 13 from codeveawers are identical?
    i'd guess it is not working only for open source drivers. i'm using tarball from this github on NVidia blob and 2nd version i used was 1.7.10 tarball from wine site. if you noticed, performance was quite different for me. only patch that i applied on both was to get TR2013 working where you remove optimization for CreateEventExW

    no clue about 2nd question

  7. #37
    Join Date
    Jan 2014
    Posts
    6

    Unhappy

    Well, I dunno what I'm doing wrong but I see almost no difference yet between standard wine (1.6) and this one (1.7.10 patched), clean install both on Linux Mint XFCE Petra Also, on example of these games running under wine and under winXP: Xonotic, Killing Floor and Half Life 2, I still have huge difference in their performance and loss approx half of FPS under wine + freezes. Added HKCU/Software/Wine/Direct3D/SCMT/="enabled" key - it changes nothing. Tested on my old PC with nVidia GTS450 1Gb on 319 drivers, AMD X2 4400+ 1750 Mhz
    Last edited by OnioWoess; 01-12-2014 at 03:27 PM.

  8. #38
    Join Date
    Sep 2012
    Posts
    23

    Default D3D9 mesa + wine

    I working on porting D3D9 state tracker to Mesa 10.0. Then I'll proviede some patchset for mesa, wine and create Gentoo ebuilds. Anyway, it need some developer, because without it'll be unusable soon.

  9. #39

    Default

    Quote Originally Posted by OnioWoess View Post
    Added HKCU/Software/Wine/Direct3D/SCMT/="enabled" key - it changes nothing.
    Probably because you misspelled it. It should be CSMT, not SCMT.

  10. #40
    Join Date
    Jun 2010
    Posts
    84

    Default

    Got a freeze on EVE-online. Was running only one client.

    Two core was stuck at 100% use for exefile.exe (with is the EVE client).
    Might be a rglrx related bug or something else as I'm mining with the same computer.

Posting Permissions

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