Announcement

Collapse
No announcement yet.

Wine-Staging 1.7.36 Has Threadpool, CUDA 7, NVENC

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

  • Uramekus
    replied
    Originally posted by Commander View Post
    I like that people complain that Wine is nVidia specific while the Wine devs try to implement csmt that works for all drivers instead of relying on __gl_threaded_optimizations from nVidia blob driver to do pretty much the same thing from my understanding.
    wine just rely in good opengl support, there isn't a lot of vendor specific code. that's why intel iGPUs do better than they should do in some cases.



    ps: nVidia was on old days, it's NVIDIA now.

    Leave a comment:


  • Commander
    replied
    I like that people complain that Wine is nVidia specific while the Wine devs try to implement csmt that works for all drivers instead of relying on __gl_threaded_optimizations from nVidia blob driver to do pretty much the same thing from my understanding.

    Leave a comment:


  • haplo602
    replied
    Originally posted by Thaodan View Post
    I don't get why ppl don't get the political problem with galium nine.
    DO explain !

    Leave a comment:


  • duby229
    replied
    Originally posted by Thaodan View Post
    I don't get why ppl don't get the political problem with galium nine.
    Explain it. It's not illegal. It's not immoral. It's not financial.

    Leave a comment:


  • Thaodan
    replied
    I don't get why ppl don't get the political problem with galium nine.

    Leave a comment:


  • duby229
    replied
    Originally posted by Dukenukemx View Post
    Those are some impressive benchmarks. If you have a weak CPU or a game that demands a lot of CPU, it makes sense to use Gallium-Nine.

    Even if you do get Wine developers to agree to Gallium-Nine, it's clear that anything with Wine developers is painful to get across. Wine needs a plugin system to allow this sorta thing more often. Instead of relying on the blessing of Wine developers. Imagine if Mantle was finally brought over to Linux and we wanted Mantle support implemented. It could be argued by developers that it isn't worth the 25,000 lines of code to maintain.

    If Wine had a plugin system we could avoid a lot of this mess.
    Plugins always sound so nice, but the truth is you always have to develop some kind of middleman situation in order for it to work. And then the middleman situation you find yourself in has to be robust enough to cover unknown situations.

    That is exactly what galluim is for. It is the middleman situation.

    EDIT: Maybe a wine state tracker
    Last edited by duby229; 09 February 2015, 05:37 PM.

    Leave a comment:


  • Dukenukemx
    replied
    Originally posted by Pontostroy View Post
    I fully agree with you and I think that nine would be a good start to support something different from nvidia not only in words.
    Gallium-nine is very close to the win8 catalyst performance, and even more effective than the win8 if used a slow processor(csmt lags very much without 4-8 cores 3 Ghz processor)
    My test
    CPU Core & frequency scaling: Wine(nine|csmt) vs Windows 8
    Linux gallium-nine vs Windows 8.1 catalyst
    The Talos Principle linux wine|nine vs windows
    Those are some impressive benchmarks. If you have a weak CPU or a game that demands a lot of CPU, it makes sense to use Gallium-Nine.

    Even if you do get Wine developers to agree to Gallium-Nine, it's clear that anything with Wine developers is painful to get across. Wine needs a plugin system to allow this sorta thing more often. Instead of relying on the blessing of Wine developers. Imagine if Mantle was finally brought over to Linux and we wanted Mantle support implemented. It could be argued by developers that it isn't worth the 25,000 lines of code to maintain.

    If Wine had a plugin system we could avoid a lot of this mess.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by Pontostroy View Post
    I fully agree with you and I think that nine would be a good start to support something different from nvidia not only in words.
    Gallium-nine is very close to the win8 catalyst performance, and even more effective than the win8 if used a slow processor(csmt lags very much without 4-8 cores 3 Ghz processor)
    My test
    CPU Core & frequency scaling: Wine(nine|csmt) vs Windows 8
    Linux gallium-nine vs Windows 8.1 catalyst
    The Talos Principle linux wine|nine vs windows
    very interesting results

    Leave a comment:


  • Pontostroy
    replied
    Originally posted by duby229 View Post
    I definitely think you 're looking at it from a twisted veiwpoint. Gallium Nine patchset for wine is just a wrapper for the native d3d9 implementation in nine. Where wines own d3d9 implementation is a translation from d3d9 to highly nvidia specific opengl. The only way wine will ever perform well on gallium is if nvidia decided to rewrite galliums opengl implementation, and that ain't gonna happen.

    The only people at fault for wines terrible performance is wine. If they would get off their non-nvidia phobia, and implement functions that work according to specs, the whole thing would work better. As long as they continue translating d3d9 into opengl functions that only work on nvidia hardware, then wine will continue to be broken on non-nvidia hardware. That is entirely wines fault.
    I fully agree with you and I think that nine would be a good start to support something different from nvidia not only in words.
    Gallium-nine is very close to the win8 catalyst performance, and even more effective than the win8 if used a slow processor(csmt lags very much without 4-8 cores 3 Ghz processor)
    My test
    CPU Core & frequency scaling: Wine(nine|csmt) vs Windows 8
    Linux gallium-nine vs Windows 8.1 catalyst
    The Talos Principle linux wine|nine vs windows

    Leave a comment:


  • duby229
    replied
    Originally posted by Uramekus
    Nvidia drivers exist on FreeBSD and macOSX too, do we actually have gallium nine to mac osx?, this is just a dll export and dont change much lines of code in wine actually, but the patches to make wine gallium3d compatible is kinda more abusive on LOC size
    nine can coexist with wine, but it will make a lot of duplicated code and it wont be supported on non mesa systems. (just trashing manpower for a little bit more of performance on some cases)

    for me, it's a waste of time keep 2 d3d9 implementation but it's worse to remove macOSX support (or making the code less simpler.)
    but this is a matter of opinion
    I definitely think you 're looking at it from a twisted veiwpoint. Gallium Nine patchset for wine is just a wrapper for the native d3d9 implementation in nine. Where wines own d3d9 implementation is a translation from d3d9 to highly nvidia specific opengl. The only way wine will ever perform well on gallium is if nvidia decided to rewrite galliums opengl implementation, and that ain't gonna happen.

    The only people at fault for wines terrible performance is wine. If they would get off their non-nvidia phobia, and implement functions that work according to specs, the whole thing would work better. As long as they continue translating d3d9 into opengl functions that only work on nvidia hardware, then wine will continue to be broken on non-nvidia hardware. That is entirely wines fault.

    Leave a comment:

Working...
X