Announcement

Collapse
No announcement yet.

Wine's Big Command Stream D3D Patch-Set Updated

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

  • stefandoesinger
    replied
    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 winXP - 200-300)...
    It should work on old dual core CPUs too. It won't do any good on single core CPUs by design.

    I have some ancient dual core athlon from 2006/2007. I haven't tested my code there yet, it's just one of the issues that needs my attention.

    In case of HL2, I recommend to experiment with the game's multicore rendering option. Switching this on or off may show different results.

    Leave a comment:


  • OnioWoess
    replied
    Originally posted by xpander View Post
    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.
    Would be good to see results of Valley Benchmark Linux version on your rig. Else, on Windows (Direct3D 9.0 and OpenGL variants), if you have. For better understanding about Wine+CSMT possibilities.

    Leave a comment:


  • justmy2cents
    replied
    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

    Leave a comment:


  • xpander
    replied
    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.

    Leave a comment:


  • xpander
    replied
    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.

    Leave a comment:


  • OnioWoess
    replied
    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, 06:43 AM.

    Leave a comment:


  • xpander
    replied
    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.

    Leave a comment:


  • TemplarGR
    replied
    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...

    Leave a comment:


  • OnioWoess
    replied
    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? ))

    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.

    Leave a comment:


  • okias
    replied
    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/

    Leave a comment:

Working...
X