Page 5 of 7 FirstFirst ... 34567 LastLast
Results 41 to 50 of 61

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

  1. #41
    Join Date
    Apr 2011
    Posts
    318

    Default

    Quote Originally Posted by stefandoesinger View Post
    Well, our (the Wine developers') and the Mesa developers' time is limited. With regards to running d3d9 applications on Mesa we have the following options:

    1. Make Wine work better on all OpenGL implementations.
    2. Make Mesa run all OpenGL applications better.
    3. Write and maintain lots of special code to make Wine run better on Mesa.


    Considering finite resources, we believe 1 is the way to go, and we're helping the Mesa devs with 2. You may disagree and submit code to either project to implement 3. But don't think it's a conspiracy when we disagree with you about what to do with our time.


    I have MESA and Wine compiled by me with the D3D9 state tracker. I just don't know why all the rest they don't. And they need to do the same as me. I didn't ask you why you don't work to improve the state tracker. We have seen what a single person can do if he is technologically and ethically right (a state tracker). So i don't really want to ask anything about your time. There are distros and individuals responsible to have those packages in their repository.

  2. #42
    Join Date
    Apr 2011
    Posts
    318

    Default

    Quote Originally Posted by stefandoesinger View Post
    The easy work is done. The hard part that separates a proof of concept from code that is stable and maintainable in the long term is remaining. In other words, following the 80/20 rule, 80% of the work still needs to be done.

    A good start would be to quantify the performance difference between wined3d and gallium-nine with reproducible benchmarks and then isolate where the performance difference is coming from. And that means not just "it reduces overhead, so it's faster", but something like "There's CPU-side overhead in module X, and GPU-side overhead because shader instructions A, B and C are inefficiently handled by module Y".

    If it turns out that there's a fundamental advantage to a gallium state tracker, and that it's not just working around some bugs in Mesa and Wine that could be fixed with e.g. a better GLSL compiler or adding one or two focused GL extensions to support some d3d-isms better the next task is finding a stable API exposed by gallium-nine and used by Wine.

    Matteo has done some testing with gallium-nine on r600g. If I remember correctly, he saw a moderate performance gain (~15% or something), but attributed most of that to insufficient optimization in the driver's GLSL compiler. I'll ask him to make sure my memory serves me right.

    Thats weird, i have mostly a 2x gain with i5 and 3x+ with Core2. This thing offloads the Cpu dramatically, and some advanced shaders that are not even run with Wine, are now work. Its like a GLSL=disabled plus Threaded-Optimisations plus+++ all together.

  3. #43
    Join Date
    Sep 2012
    Posts
    18

    Lightbulb Gallium nine still ALIVE!

    I wrote small article about it, it work with mesa 10.0 and lastest wine. DEVELOPERS NEEDED So, if you want help with some small patch, some improvment, fix, everything is welcomed!

    I'll try keep it alive, any help appriciated!

    https://ixit.cz/faster-wine-games-wi...-gallium-nine/

  4. #44
    Join Date
    Jan 2014
    Posts
    6

    Default

    Quote Originally Posted by stefandoesinger View Post
    Probably because you misspelled it. It should be CSMT, not SCMT.
    Yup, CSMT, certainly, misspelled only here in my post. Maybe I should have that <enabled> in quotes? ))

    Quote Originally Posted by artivision View Post
    Thats weird, i have mostly a 2x gain with i5 and 3x+ with Core2. This thing offloads the Cpu dramatically, and some advanced shaders that are not even run with Wine, are now work. Its like a GLSL=disabled plus Threaded-Optimisations plus+++ all together.
    Please, please, may you tell me how? I cannot do that.

  5. #45
    Join Date
    Dec 2009
    Location
    Greece
    Posts
    351

    Default

    Quote Originally Posted by artivision View Post
    Thats weird, i have mostly a 2x gain with i5 and 3x+ with Core2. This thing offloads the Cpu dramatically, and some advanced shaders that are not even run with Wine, are now work. Its like a GLSL=disabled plus Threaded-Optimisations plus+++ all together.
    This is my opinion as well, and i don't need tests to be convinced...

    A d3d state tracker can make wine extremely efficient for games. Granted, it is only for gallium and there may be patent fears etc. But i don't believe it requires much work.

    The way i see things, Wine and Crossover developers have certain target groups and Linux users don't rank highly on that list... How many times has it happened? A project that could be used to improve Wine for Linux not getting accepted?

    Wine prefers the Mac platform, it is obvious. I am willing to bet that if Apple had gone the gallium3d way, Wine would support d3d trackers ASAP.

    I didn't want to say this earlier, because i wanted to read Stefan's opinion first. And he just provided us with excuses that have no technical merit at all.

    No one asked them to develop or maintain a d3d9 state tracker. We just asked the option to use it to be included officially... It is not much work and it could be a compile time option.

    I am pretty sure MESA devs wouldn't mind to include it, if there was a use for it. And the only use for it would be if WINE supported it. So this is a chicken and egg problem, WINE devs won't support it because it is not for Apple systems with excuses like "it needs maintainance", while MESA devs can't mainline it if there is no software using it...

  6. #46
    Join Date
    Jun 2009
    Location
    Estonia
    Posts
    141

    Default

    Quote Originally Posted by OnioWoess View Post
    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

    you wont gain much (if at all) because of your weak old CPU.. dual core and low frequency.

  7. #47
    Join Date
    Jan 2014
    Posts
    6

    Default

    Quote Originally Posted by xpander View Post
    you wont gain much (if at all) because of your weak old CPU.. dual core and low frequency.
    Ahh. You wanna say that this tricks with wine works only for modern hardware and could give a boost only comparable to the previous poor results on it .
    Therefore, no chance to get same framerate even in HL2 then, which I have in Windows (wine - 40-160 winXP - 200-300)...

    I could test it with my another PC, though, but I hoped it'll give a second chance to my old one. Sigh )
    Last edited by OnioWoess; 01-13-2014 at 05:43 AM.

  8. #48
    Join Date
    Jun 2009
    Location
    Estonia
    Posts
    141

    Default

    Quote Originally Posted by OnioWoess View Post
    Ahh. You wanna say that this tricks with wine works only for modern hardware and could give a boost only comparable to the previous poor results on it .
    Therefore, no chance to get same framerate even in HL2 then, which I have in Windows (wine - 40-160 winP - 200-300)...
    well according to my tests you need a good dualcore cpu at least to see some improvements
    quadcore is even better

    probably you can get some improvements if you kill all other tasks on your OS... so nothing else access 1 of your cores.

    but seriously that old athlon x2 is super old.

  9. #49
    Join Date
    Jun 2009
    Location
    Estonia
    Posts
    141

    Default

    Valley Benchmark in Wine

    https://www.youtube.com/watch?v=8r_dSJ6uwms

    Simple Screen Recorder kills some performance also though, but the point is still valid.. 2x perf boost with CSMT enabled.

  10. #50
    Join Date
    Oct 2013
    Posts
    340

    Default

    Quote Originally Posted by TemplarGR View Post
    The way i see things, Wine and Crossover developers have certain target groups and Linux users don't rank highly on that list... How many times has it happened? A project that could be used to improve Wine for Linux not getting accepted?

    Wine prefers the Mac platform, it is obvious. I am willing to bet that if Apple had gone the gallium3d way, Wine would support d3d trackers ASAP.

    I didn't want to say this earlier, because i wanted to read Stefan's opinion first. And he just provided us with excuses that have no technical merit at all.

    No one asked them to develop or maintain a d3d9 state tracker. We just asked the option to use it to be included officially... It is not much work and it could be a compile time option.

    I am pretty sure MESA devs wouldn't mind to include it, if there was a use for it. And the only use for it would be if WINE supported it. So this is a chicken and egg problem, WINE devs won't support it because it is not for Apple systems with excuses like "it needs maintainance", while MESA devs can't mainline it if there is no software using it...
    easy to speak like that when you're not the developer. each developer has its own plans for his baby. if you need to go trough hoops and loops for whims,... not fun.

    (i'm not wine developer, so i might be completely out of base. if so i apologize. this is bystanders viewpoint)
    fail nr.1) state tracker d3d9 only works with OSS drivers, not with blobs. you need 2 codebases for same thing in order to achieve the goal of wine. and the result is even worse, each time you get bug report you need to check the 2 codepaths, which would lead to lots of false positives and noise for wine developers since you can bet both legs that error reports will fly in their Issues.
    fail nr.2) most projects like that are temporary where maintainers get lost and whole bugs and problems fall on developers who never made anything other than just approve code to be part of their project
    fail nr.3) let's say this thing works well and developers start using this for games just to spare them selves porting troubles... that is one shitload of excuses for MS to suddenly throw some punches in order to discredit linux gaming. if there is no directx option, developers that write for linux must use established and safe OpenGL engine. this is not the question if MS has any legal basis, sometimes simply starting long term losing battle can prove as victory since other party can't afford battle long enough to win.

    then again nothing would prevent anyone to simply host patched wine where they simply abstract interface for function calls like for example fuse does and enable option "UseStateTracker=true". by default you simply initialize by setting wine methods as abstraction, but if option is set, then you simply set state tracker methods. if this wine version proves successful you can bet mesa/galium developers will see incentive to include tracker by default

Posting Permissions

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