Announcement

Collapse
No announcement yet.

X.Org vs. Wayland Linux Gaming Performance For NVIDIA GeForce + AMD Radeon In Early 2023

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

  • qarium
    replied
    Originally posted by oiaohm View Post
    I don't have a steam account and effected GPU to open a ticket as effected user with valve.. I still have stacks of open source games I have not got as far as I would like to in as yet. You may have the bits to open a issue with Valve that could get the problem in front of manager.
    My knowledge has me known what is possible. wined3d vulkan will take over from dxvk old at some point. Wine core developers that do wined3d with opengl and vulkan going forwards they are not going to be breaking legacy hardware support. wined3d will take a performance hit to keep legacy support. Yes steam being so hard to enable wined3d then not able to enable wined3d vulkan back end simply another issue.
    Galluim nine is for the prevulkan cards with open source drivers to get decent performance. This cards are also not vendor supported so it now manage to collect up third party developers to pick up the slack somehow with galluim nine.
    The cards that don't have vulkan support lot of those are starting to run into expired thermal paste/pads no longer being as terminal conductive as they should be and this is another fairly skilled thing to fix.
    https://lutris.net/games/steam/ There are reasons why Lutris exists and people install Windows version of Steam in wine on some systems. Can be less painful doing this than using Linux version of steam with older hardware configurations.
    Big problem here is users think this behavior is Linux limitation. When this is more how proton or wine is configured and how it requires manual configuration on older hardware at times.
    I appreciate your knowledge and your skills.​ thank you.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by qarium View Post
    but i am not a manager at valve to tell some developer to fix their steam store gui...
    I don't have a steam account and effected GPU to open a ticket as effected user with valve.. I still have stacks of open source games I have not got as far as I would like to in as yet. You may have the bits to open a issue with Valve that could get the problem in front of manager.

    Originally posted by qarium View Post
    and i am honest to you i can not recommend your hacker way of thinking to people because most people i know who need help are not able to do as you recommend. thats all above what they can do with their skills.
    My knowledge has me known what is possible. wined3d vulkan will take over from dxvk old at some point. Wine core developers that do wined3d with opengl and vulkan going forwards they are not going to be breaking legacy hardware support. wined3d will take a performance hit to keep legacy support. Yes steam being so hard to enable wined3d then not able to enable wined3d vulkan back end simply another issue.

    Galluim nine is for the prevulkan cards with open source drivers to get decent performance. This cards are also not vendor supported so it now manage to collect up third party developers to pick up the slack somehow with galluim nine.

    The cards that don't have vulkan support lot of those are starting to run into expired thermal paste/pads no longer being as terminal conductive as they should be and this is another fairly skilled thing to fix.

    Originally posted by qarium View Post
    i can only hope this problem goes away over time by either valve fix their store or else by people buy new hardware.
    but it is bad taste to anyone who tests linux and then goes back to windows because they do not have this problems in windows.
    https://lutris.net/games/steam/ There are reasons why Lutris exists and people install Windows version of Steam in wine on some systems. Can be less painful doing this than using Linux version of steam with older hardware configurations.

    Big problem here is users think this behavior is Linux limitation. When this is more how proton or wine is configured and how it requires manual configuration on older hardware at times.

    Leave a comment:


  • qarium
    replied
    Originally posted by oiaohm View Post
    https://www.supergoodcode.com/the-fi...er-a-zink-blog
    The performance cost does not need to be that high. amd HD6860 using galluim nine you are do get performance in the DXVK cost range. Steam with proton does not provide option to straight up use galluim nine. Yes PROTON_USE_WINED3D=1​ has to be set then work out how to customize proton to have a galluim nine version.
    Yes you are right only a minority do what I said. The minority who do what I said know where the problem is.
    There are 5 backend with wine for direct X. WINED3D opengl, WINED3D Vulkan, DXVK new, DXVK old and galluim Nine. Proton by current design only gives you one without major hoop jumping.
    Part of the reason why Valve has no real reason to fix it is most are like you and think it a Linux problem. Not being aware that it really a Valve Steam Interface problem and proton lack of options problem.
    Yes the layers to port back new Vulkan extentions to old cards would be nice. But fall back option to galluim nine that has less overhead doing direct x than direct x to opengl would also be nice for older cards with open source drivers.
    qarium lot more should work than does when using steam these days. 50-60% performance lose with opengl backend is still better than not run at all. Think about if game runs and performs badly person might do some searches how to improve performance and find galluim nine. Remember you were thinking your self the games do not work so got a new card not the games work but perform badly. Perform badly higher chance you will look for the performance fix. Level of GUI being broken. Steam resulting in game not running at all is way worse on the broken scale than poor performing. So in my eyes dxvk cannot work should at least fail though to wined3d opengl. Then there is a chance user finds way out.
    i fully agree.

    but i am not a manager at valve to tell some developer to fix their steam store gui...

    and i am honest to you i can not recommend your hacker way of thinking to people because most people i know who need help are not able to do as you recommend. thats all above what they can do with their skills.

    i can only hope this problem goes away over time by either valve fix their store or else by people buy new hardware.

    but it is bad taste to anyone who tests linux and then goes back to windows because they do not have this problems in windows.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by qarium View Post
    my friend i used wine directX 9-11 to OpenGL conversion many years before proton/DXVK popped up and the performance drop by doing so is very high .... Proton/DXVK you lose maybe 6-7% performance but on DX to OpenGL vonversion you lose 50-60% performance
    this is to high for these old hardware.
    just remember it was just an example this card i will give it away for people who use windows. for this old hardware windows performs much better.

    I just made an example about how linux is not competive in this GPU space.

    https://www.supergoodcode.com/the-fi...er-a-zink-blog

    The performance cost does not need to be that high. amd HD6860 using galluim nine you are do get performance in the DXVK cost range. Steam with proton does not provide option to straight up use galluim nine. Yes PROTON_USE_WINED3D=1​ has to be set then work out how to customize proton to have a galluim nine version.

    Originally posted by qarium View Post
    again directX to OpenGL is not an option because you lose 50-60% performance and on vulkan/DXVK you only lose 6-7% performance.
    and yes it is all a Usability hell and who cause this does not matter at all a steam client userfriendly problem or whatever the result is that linux is a usability nightmare and not competive compared to windows.
    and use old DXVK for older hardware even if possible is still a Usability hell and really not the way to go for the people.

    if you want any kind of usability you end up buy new gpu card... thats the status we have right now.

    and the people who do all the stuff you say are the absolut minority...
    Yes you are right only a minority do what I said. The minority who do what I said know where the problem is.

    There are 5 backend with wine for direct X. WINED3D opengl, WINED3D Vulkan, DXVK new, DXVK old and galluim Nine. Proton by current design only gives you one without major hoop jumping.

    Originally posted by qarium View Post
    ​you are absolutly right its a steam/gui problem valve should make these options visible in the guy to choose dx to openGL or older DXVK for older hardware or write a autodetect mechanism.

    and i am in the sam boot as you for "verval assault cursing them" i want linux to win the battle agaist microsoft but with this status we will not win this.

    is very easy to detect why valve dont do this: "Or valve could decide to fund vulkan layer developers." because the steam deck is RDNA2 and don't have this problem. right now they only care about RDNA2 or newer... and even vega or RDNA1 users are out of the luck right now.

    problem is valve has no big reason to fix the "Valve horrible steam interface" problem outside of the steam deck ...
    Part of the reason why Valve has no real reason to fix it is most are like you and think it a Linux problem. Not being aware that it really a Valve Steam Interface problem and proton lack of options problem.

    Yes the layers to port back new Vulkan extentions to old cards would be nice. But fall back option to galluim nine that has less overhead doing direct x than direct x to opengl would also be nice for older cards with open source drivers.

    qarium lot more should work than does when using steam these days. 50-60% performance lose with opengl backend is still better than not run at all. Think about if game runs and performs badly person might do some searches how to improve performance and find galluim nine. Remember you were thinking your self the games do not work so got a new card not the games work but perform badly. Perform badly higher chance you will look for the performance fix. Level of GUI being broken. Steam resulting in game not running at all is way worse on the broken scale than poor performing. So in my eyes dxvk cannot work should at least fail though to wined3d opengl. Then there is a chance user finds way out.

    Leave a comment:


  • qarium
    replied
    Originally posted by oiaohm View Post
    That exactly how it looks.
    Wine dx to opengl conversion is not pain free. I guess you tried with steam. Yes having to set PROTON_USE_WINED3D=1​ in "Set Launch Options​" in every game you want to run by the Linux steam client so it works with a card this old is really not user-friendly.
    So yes dx9-11 applications should have been to made work at least as good as they do in wine. But its absolutely not userfriendly and not high performing. Do know a lot that end up using windows version steam in wine with galluim-nine on hardware that old. Linux steam client does not support using galluim-nine natively at all and the opengl back in for proton is a pure pain to use.
    Of course wine and proton support is not perfect.​

    my friend i used wine directX 9-11 to OpenGL conversion many years before proton/DXVK popped up and the performance drop by doing so is very high .... Proton/DXVK you lose maybe 6-7% performance but on DX to OpenGL vonversion you lose 50-60% performance
    this is to high for these old hardware.
    just remember it was just an example this card i will give it away for people who use windows. for this old hardware windows performs much better.

    i just made an example about how linux is not competive in this GPU space.

    Originally posted by oiaohm View Post
    This is kind of valve again. Why is vulkan extensions missing total failure with dx9 and dx11 games. There is the WINED3D fall back that use opengl Steam does not make this option easy.
    proton works with dxvk(vulkan) or wined3d(opengl) for dx8-11. So the fact you were not finding this option this is a steam client userfriendly problem.
    Vulkan extensions missing causing dxvk to fail completely that does fall on dxvk also still falls on valve with steam.
    Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux / Wine - doitsujin/dxvk

    Notice dxvk developer keeps a old version recommended for Vulkan 1.1 Ok not going to perform as well as the new version but if you don't have the hardware feature to get the better performance.
    People using wine older hardware end up using older dxvk. Yes of course steam default proton is not your only option either.​

    again directX to OpenGL is not an option because you lose 50-60% performance and on vulkan/DXVK you only lose 6-7% performance.
    and yes it is all a Usability hell and who cause this does not matter at all a steam client userfriendly problem or whatever the result is that linux is a usability nightmare and not competive compared to windows.
    and use old DXVK for older hardware even if possible is still a Usability hell and really not the way to go for the people.

    if you want any kind of usability you end up buy new gpu card... thats the status we have right now.

    and the people who do all the stuff you say are the absolut minority...


    Originally posted by oiaohm View Post
    To be correct you don't know. The vulkan issue with proton is a 3 way tango. DXVK, hardware vendors and missing third parties.
    Lot of people are not aware that you can force games to use opengl backend under steam. Lot of people are not aware that you can force steam to use older versions of proton or third party generated versions of proton with things changed like locked to old dxvk version so works with old cards.
    Of course there is still lack of developers for vulkan compatibility layers. As in vulkan layers to allow newer vulkan extensions to work on older cards.
    Its more where are the resources and cases of poor user friendliness by steam. Yes game does not run vulkan error no clue that opengl backend is option or that different version of proton is option.
    Yes steam could detect if they wanted to what GPU you have and set default proton version to match. Or valve could decide to fund vulkan layer developers.
    Lot of what you wrote sounds to me case of hitting Valve horrible steam interface and getting a very false appearance of what the problem is. Yes many a day its good thing that the developers of the Linux steam client are not close to me or I might be done for verbal assault cursing them over some of these interface problems..
    you are absolutly right its a steam/gui problem valve should make these options visible in the guy to choose dx to openGL or older DXVK for older hardware or write a autodetect mechanism.

    and i am in the sam boot as you for "verval assault cursing them" i want linux to win the battle agaist microsoft but with this status we will not win this.

    is very easy to detect why valve dont do this: "Or valve could decide to fund vulkan layer developers." because the steam deck is RDNA2 and don't have this problem. right now they only care about RDNA2 or newer... and even vega or RDNA1 users are out of the luck right now.

    problem is valve has no big reason to fix the "Valve horrible steam interface" problem outside of the steam deck ...

    Leave a comment:


  • ssokolow
    replied
    Originally posted by qarium View Post
    because of this lag of leadershipment from people like linus torvalds this stupid rule to not break userspace will end up in more any more legacy cruft.

    [...]

    we maybe don't like it but windows profits from the fact that they drop legacy cruft like win16 or implicit sync... and other stuff.

    [...]to be honest on the graphic/gpu side linux does not feel competive to windows we amd gpu users have no driver GUi like the people on windows
    and also we have big legacy problem with vulkan extensions for example polaris cards and soon vega cards will have the same problem that amd does no longer develop new vulkan extensions for the old cards the result is that these old cards can not run the vulkan DKVK/Proton layers at the same time on windows in DirectX 9/11/12 everything works well and the people have no legacy problem... on the linux side people with polaris cards are forced to buy new cards or else they can no longer play their games. sad story but true. proton of valve does in fact expect an RDNA2 GPU like the steam deck and they push new vulkan extensions. old cards does not get the extenions and planet obsolecense push these people in front of a running bus.

    linux on the gpu side does not feel competive to windows and with more Linus Torvalds rules this situation will become even worst over time.
    Microsoft lives by the "Don't break userspace" rule even more than Linux does and it's a big part of why they maintain a 95%+ market share. Windows 3.1 bent over backwards to be compatible with MS-DOS, Windows 95 bent over backwards to be compatible with both of them, and Windows XP bent over backwards to be compatible with Win9x-lineage stuff. That's why they have a massive testing team and Windows comes with gigabytes of DLLs in WinSxS (Their analogue to Flatpak runtimes) and a ton of built-in "If application X, pretend to still have old bug Y" (eg. Win9x famously had an "If SimCity for DOS, allow application to keep using memory after free()-ing it") rules.

    In fact, that's one of people's biggest complaints about Linux. That userspace doesn't follow the "don't break userspace" rule to provide a reliable base platform beyond the raw kernel syscalls that applications rarely interact with directly.​

    Microsoft didn't drop Win16 support until Win64, at which point they still left 32-bit installs of Windows remain compatible for users with such needs. They only dropped 32-bit Windows this year for Windows 11, and there are still older version of Windows with 32-bit releases that haven't gone out of support yet... and, if they had decided to port the Win16 thunking layer to 64-bit kernels, they'd probably still be supporting it now with no plans to actively drop it.

    The fact that AMD doesn't write a driver GUI and doesn't backport Vulkan extensions has nothing to do with "Don't break userspace". Heck, windows is more aggressive about dropping hardware support, what with how many models of printer and scanner work on modern Linux but not modern Windows.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by qarium View Post
    this honestly really sounds like Nvidia does sapotage Linux and also Nvidia does sapotage OpenGL
    That exactly how it looks.

    Originally posted by qarium View Post
    ​for example i pulled a amd HD6860 out of my mothers computer and replaced it with an intel arc a380 ok do not talk about the intel card talk about the amd hd6870 just to make an example on windows people who play older games Dx9 and dx11 games are just fine with this card and there are windows 10 drivers ok there are no windows 11 drivers but most people i know are happy with windows 10 ok now compare this to linux the same card AMD hd6870 is a hell of a nightmare on linux the dx9 games do not work the dx11 games do not work maybe the openGL games work but very slow.
    Wine dx to opengl conversion is not pain free. I guess you tried with steam. Yes having to set PROTON_USE_WINED3D=1​ in "Set Launch Options​" in every game you want to run by the Linux steam client so it works with a card this old is really not user-friendly.

    So yes dx9-11 applications should have been to made work at least as good as they do in wine. But its absolutely not userfriendly and not high performing. Do know a lot that end up using windows version steam in wine with galluim-nine on hardware that old. Linux steam client does not support using galluim-nine natively at all and the opengl back in for proton is a pure pain to use.

    Of course wine and proton support is not perfect.

    Originally posted by qarium View Post
    ​the same amd hd7000 card on linux is a nightmare come true because of the lag of vulkan extensions of this old driver to run dx9/dx11/dx12 in proton is a nightmare even if you switch from RadeonSI kernel part manually to AMDGPU kernel part to get the vulkan support but one vulkan extensions not supported and you are out of luck,.,​
    This is kind of valve again. Why is vulkan extensions missing total failure with dx9 and dx11 games. There is the WINED3D fall back that use opengl Steam does not make this option easy.

    proton works with dxvk(vulkan) or wined3d(opengl) for dx8-11. So the fact you were not finding this option this is a steam client userfriendly problem.

    Vulkan extensions missing causing dxvk to fail completely that does fall on dxvk also still falls on valve with steam.

    Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux / Wine - doitsujin/dxvk

    Notice dxvk developer keeps a old version recommended for Vulkan 1.1 Ok not going to perform as well as the new version but if you don't have the hardware feature to get the better performance.

    People using wine older hardware end up using older dxvk. Yes of course steam default proton is not your only option either.

    Originally posted by qarium View Post
    i have a vega64 and i know 2023 will be the last year of support for vega and then i am in the vulkan extension hell as well.
    To be correct you don't know. The vulkan issue with proton is a 3 way tango. DXVK, hardware vendors and missing third parties.

    Originally posted by qarium View Post
    now tell me where is the leadershipment there ? its a big fat failure.
    Lot of people are not aware that you can force games to use opengl backend under steam. Lot of people are not aware that you can force steam to use older versions of proton or third party generated versions of proton with things changed like locked to old dxvk version so works with old cards.

    Of course there is still lack of developers for vulkan compatibility layers. As in vulkan layers to allow newer vulkan extensions to work on older cards.

    Its more where are the resources and cases of poor user friendliness by steam. Yes game does not run vulkan error no clue that opengl backend is option or that different version of proton is option.

    Yes steam could detect if they wanted to what GPU you have and set default proton version to match. Or valve could decide to fund vulkan layer developers.

    Lot of what you wrote sounds to me case of hitting Valve horrible steam interface and getting a very false appearance of what the problem is. Yes many a day its good thing that the developers of the Linux steam client are not close to me or I might be done for verbal assault cursing them over some of these interface problems..

    Leave a comment:


  • qarium
    replied
    Originally posted by oiaohm View Post
    https://www.phoronix.com/news/Linux-...SYSCTL-SYSCALL
    Do not break userspace does not mean never remove legacy cruft from kernel. There is leadership.

    of course there is leadershipment but you write about the failure we have right now at the bottom of your post about how vulkan means planet obsolescence hits users hard on linux and on windows there is zero impact and windows users on old hardware have much more luck to play games.
    so the leadershipment in the kernel does not compensate for the lag of leadershipment in the vulkan driver space.

    Originally posted by oiaohm View Post
    https://microsoft.github.io/DirectX-...dBarriers.html
    How badly wrong you are. Read this carefully. Yes Windows Direct X 12 still has implicit sync. There are lots of cases Microsoft obeys the rule of "do not break userspace" yes Nvidia windows drivers have not had to implement implicit sync but Microsoft goes and puts a wrapper on top with direct X that does implicit sync so legacy applications work.
    Nvidia with its Linux drivers and userspace has been highly adverse to having wrapper placed on top.
    Nvidia if you want to provide you own made opengl libraries its your responsibility to follow the specification this includes providing Implicit sync. With Nvidia open sourcing their driver for newer cards these have the possibility of using the generic wrappers in the kernel to provide implicit sync where its required in the code base of the Linux kernel and for the syscalls that require implicit sync. So not the code they have to take care of.
    mdedetrich claimed a false agreement. There is a big difference between just providing a driver and providing complete stack.
    Direct X 9 implicit sync.
    Direct X 11 implicit sync and explicit sync in userspace ABI.
    Direct X 12 implicit sync and explicit sync in userspace ABI.
    Microsoft is obeying rule of "do not break user space" here with wrappers putting back legacy functionality. Nvidia linux opengl not having functional implicit sync and saying hey developers update your program so those work this would mean that Direct X 9 and 11 would not work under Windows of Microsoft followed the same rules.
    this honestly really sounds like Nvidia does sapotage Linux and also Nvidia does sapotage OpenGL

    I dropped my last nvidia card in 2007 i know for a long time this nvidia people are evil maniacs ...

    Originally posted by oiaohm View Post
    DKVK not working with older cards because some Vulkan extension is missing does not line up with the windows wrapper implementation you can find this with hardware feature levels and exposed functionality. Direct X 12 only requires a Direct X 11 driver yes Direct X 12 falls back to software implementation of some functionality.
    https://vulkan.lunarg.com/doc/view/1...ion_layer.html
    The Vulkan problem is something else. Vulkan is design that extensions can be added by third parties who are not the hardware vendor by software emulation. The vulkan layers to add newer features to older cards have not been developed at this stage. Microsoft direct X does have cpu emulation layers so newer applications calling newer DX functions the GPU does not support still work and older applications using older functionality like implicit sync the graphics drivers no longer support still work. Yes the do not break userspace stuff.
    So the DKVK not working on older cards on Linux is a 3 way tango between driver vendors, Lack of developers working on vulkan functianality emulation layers and DKVK developers.
    Do be aware that Valve does want to use DKVK on windows as well to get around some applications that depend on directx removed quirks. Yes the vulkan problem of not getting new extensions for old cards effects windows users as well. Yes this includes the lack of cpu emulation layers to add different functions to old cards..
    Vulkan is designed to be better for this than Opengl. But better designed still require developers to be funded to put the time in.
    no driver GUi << This one is interesting. Turns out most of that has been a single russia developer under Windows. Linux world has not been luck enough to have a developer make driver GUI then vendors deciding to pay for that developers time.
    look its all a failure of linux and people don't care what is the reason why it is a failure

    for example i pulled a amd HD6860 out of my mothers computer and replaced it with an intel arc a380 ok do not talk about the intel card talk about the amd hd6870 just to make an example on windows people who play older games Dx9 and dx11 games are just fine with this card and there are windows 10 drivers ok there are no windows 11 drivers but most people i know are happy with windows 10 ok now compare this to linux the same card AMD hd6870 is a hell of a nightmare on linux the dx9 games do not work the dx11 games do not work maybe the openGL games work but very slow.

    now say lets behind this poison AMD hd 6000 series of VLIW4D/5D and now talk about the amd HD7000 series

    its a dx12 card and on windows dx9 games work dx11 games work and dx12 games work...

    the same amd hd7000 card on linux is a nightmare come true because of the lag of vulkan extensions of this old driver to run dx9/dx11/dx12 in proton is a nightmare even if you switch from RadeonSI kernel part manually to AMDGPU kernel part to get the vulkan support but one vulkan extensions not supported and you are out of luck,.,

    and this goes up to AMD rx480/RX590 all these polaris cards people report some vulkan extensions make sure Valve proton does no longer work.

    i have a vega64 and i know 2023 will be the last year of support for vega and then i am in the vulkan extension hell as well.

    at the same time people on windows use vega64 without any problems.

    in the past linux was known for anti-planed-obsolecense caracteristic but today with vulkan on linux you are forced to buy new GPU card every 5-6 years or else stuff will break and stuff will not work...

    now tell me where is the leadershipment there ? its a big fat failure.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by qarium View Post
    because of this lag of leadershipment from people like linus torvalds this stupid rule to not break userspace will end up in more any more legacy cruft.
    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


    Do not break userspace does not mean never remove legacy cruft from kernel. There is leadership.

    Originally posted by qarium View Post
    we maybe don't like it but windows profits from the fact that they drop legacy cruft like win16 or implicit sync... and other stuff.

    How badly wrong you are. Read this carefully. Yes Windows Direct X 12 still has implicit sync. There are lots of cases Microsoft obeys the rule of "do not break userspace" yes Nvidia windows drivers have not had to implement implicit sync but Microsoft goes and puts a wrapper on top with direct X that does implicit sync so legacy applications work.

    Nvidia with its Linux drivers and userspace has been highly adverse to having wrapper placed on top.

    Nvidia if you want to provide you own made opengl libraries its your responsibility to follow the specification this includes providing Implicit sync. With Nvidia open sourcing their driver for newer cards these have the possibility of using the generic wrappers in the kernel to provide implicit sync where its required in the code base of the Linux kernel and for the syscalls that require implicit sync. So not the code they have to take care of.

    mdedetrich claimed a false agreement. There is a big difference between just providing a driver and providing complete stack.

    Originally posted by qarium View Post
    to be honest on the graphic/gpu side linux does not feel competive to windows we amd gpu users have no driver GUi like the people on windows
    and also we have big legacy problem with vulkan extensions for example polaris cards and soon vega cards will have the same problem that amd does no longer develop new vulkan extensions for the old cards the result is that these old cards can not run the vulkan DKVK/Proton layers at the same time on windows in DirectX 9/11/12 everything works well and the people have no legacy problem.​
    Direct X 9 implicit sync.
    Direct X 11 implicit sync and explicit sync in userspace ABI.
    Direct X 12 implicit sync and explicit sync in userspace ABI.
    Microsoft is obeying rule of "do not break user space" here with wrappers putting back legacy functionality. Nvidia linux opengl not having functional implicit sync and saying hey developers update your program so those work this would mean that Direct X 9 and 11 would not work under Windows of Microsoft followed the same rules.

    DKVK not working with older cards because some Vulkan extension is missing does not line up with the windows wrapper implementation you can find this with hardware feature levels and exposed functionality. Direct X 12 only requires a Direct X 11 driver yes Direct X 12 falls back to software implementation of some functionality.


    The Vulkan problem is something else. Vulkan is design that extensions can be added by third parties who are not the hardware vendor by software emulation. The vulkan layers to add newer features to older cards have not been developed at this stage. Microsoft direct X does have cpu emulation layers so newer applications calling newer DX functions the GPU does not support still work and older applications using older functionality like implicit sync the graphics drivers no longer support still work. Yes the do not break userspace stuff.

    So the DKVK not working on older cards on Linux is a 3 way tango between driver vendors, Lack of developers working on vulkan functianality emulation layers and DKVK developers.

    Do be aware that Valve does want to use DKVK on windows as well to get around some applications that depend on directx removed quirks. Yes the vulkan problem of not getting new extensions for old cards effects windows users as well. Yes this includes the lack of cpu emulation layers to add different functions to old cards..

    Vulkan is designed to be better for this than Opengl. But better designed still require developers to be funded to put the time in.

    no driver GUi << This one is interesting. Turns out most of that has been a single russia developer under Windows. Linux world has not been luck enough to have a developer make driver GUI then vendors deciding to pay for that developers time.

    Leave a comment:


  • qarium
    replied
    Originally posted by oiaohm View Post
    https://www.collabora.com/news-and-b...-gap-on-linux/
    No mdedetrich read the above AMD/Intel and Collabora kernel developers don't agree with what you wrote either..
    https://www.kernel.org/doc/html/late...sync_file.html Yes that import and export sync is documented here.
    Yes that says 5.20 but that really Linux kernel 6.0 released 2 October 2022​ yes was merged in kernel 6.0.
    This bit is important. Linux kernel developers have gone the route of Implicit and explicit sync both working with each other. Yes the reason why you can extract the kernel kernel implicit sync explicit fences to user space and have it work in explicit sync is that its implemented on explicit sync.
    mdedetrich yes the AMD and Intel developers believe that the core operations of graphics should be explicit sync but they don't agree that implicit sync should be rendered non functional.
    You have to remember the Linus Torvalds rule here "We do not break user-space". Since the Linux kernel DRM subsystem historically has supported implicit sync it has to remain supporting implicit sync.​
    The hard reality here Nvidia explicit sync only is breach of Linux kernel development rules and makes their opengl implementation non conforming that causes Valve problems even on windows one of the reason why Valve funded porting zink to windows.
    Now also remember you need to pass explicit sync fences between processes when you have Wayland compositor.
    Yes the proposal that has been accepted into the Linux kernel is both implicit sync and explicit sync will play nice with each other.
    Older protocols like X11 and Opengl and Linux kernel framebuffer have written into them that items should be implicit synced.

    Helper to setup the plane_state fence in case it is not set yet. By using this drivers doesn’t need to worry if the user choose implicit or explicit fencing.
    Notice something here. There is a stack of wrapper functions in the Linux kernel in many different places that mainline graphics drivers don't have to care if the sync items are used in implicit or explicit by userspace other parts of the kernel.
    mdedetrich Nvidia path is zero implicit sync support that does not have the agreement of those making Wayland compositors, those wanting to run old application or in fact not backed by AMD or Intel developers. Yes Intel and AMD and Nvidia developers agree the core of graphics drivers should be explicit sync to avoid over sync issues but Intel and AMD developers are not attempting to force everyone to change over to explicit sync. No implicit sync is break legacy applications. Yes Intel and AMD linux kernel developers agree on keeping implicit sync on top of explicit sync for legacy applications.
    Yes Linux kernel having proper way to use implicit sync and explicit sync with each other without shooting each other in foot is 2022 new thing. Linux does not have to go the same route as Windows.
    Nvidia attempting to completely drop implicit sync is really like windows dropping win16 support then intel developer expecting Linux kernel to also remove win16 support. Remember Wine still has win16 support for legacy applications and that is supported by the Linux kernel because of the same Linus Torvalds rule.
    it reallly sounds sane for now but i think this will hurt linux over long time.

    because of this lag of leadershipment from people like linus torvalds this stupid rule to not break userspace will end up in more any more legacy cruft.

    we maybe don't like it but windows profits from the fact that they drop legacy cruft like win16 or implicit sync... and other stuff.

    at some point linux will accumulate more and more of this old legacy cruft in the "Linus Torvalds rule here "We do not break user-space"" space.

    to be honest on the graphic/gpu side linux does not feel competive to windows we amd gpu users have no driver GUi like the people on windows
    and also we have big legacy problem with vulkan extensions for example polaris cards and soon vega cards will have the same problem that amd does no longer develop new vulkan extensions for the old cards the result is that these old cards can not run the vulkan DKVK/Proton layers at the same time on windows in DirectX 9/11/12 everything works well and the people have no legacy problem... on the linux side people with polaris cards are forced to buy new cards or else they can no longer play their games. sad story but true. proton of valve does in fact expect an RDNA2 GPU like the steam deck and they push new vulkan extensions. old cards does not get the extenions and planet obsolecense push these people in front of a running bus.

    linux on the gpu side does not feel competive to windows and with more Linus Torvalds rules this situation will become even worst over time.

    Leave a comment:

Working...
X