Announcement

Collapse
No announcement yet.

Wine Vulkan Preps For v1.1 Support With Licensing Issues Resolved

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

  • sdack
    replied
    Originally posted by VikingGe View Post
    Reading your above comment, you weren't going to do that anyway.
    You mean regarding EVE Online? No, but I've told you already in the issue thread.

    The launcher passes a crypto key to the game client and so cannot be started manually to run an apitrace. It's also an MMO and the gamemaker has watch dogs in the client that trigger a flag with the account. So I first had to send them an email to give them a heads up and then tried it with the dlls by varis1. To go further would I now have to write a wrapper and catch the crypto key. Otherwise would you already have a trace. I just don't want to force it at this point. I'll just wait for a newer driver and see if others have more luck. It is a none pressing issue and neither you or DXVK are important. Like I said, having it directly in WINE would be nice. DXVK is only a curiosity and frankly don't I see you as the man who will take it any further than where it is now.
    Last edited by sdack; 05 June 2018, 02:47 PM.

    Leave a comment:


  • VikingGe
    replied
    Originally posted by sdack
    *lol* No. Your code, your responsibility and any bugs in it are all yours, too. Nor are your bugs my issue, but they are everyone's issue who use DXVK.
    And this is why it should be in your interest as well to help me get these bugs fixed as soon as possible. Instead you're lecturing me how I'm supposed to buy, install and set up every single game in existence and guess what your issues might be, instead of asking people to spend half an hour on trying to record an apitrace that I can work with directly.

    There's a reason why this issue got fixed and yours didn't.

    Originally posted by sdack
    I certainly cannot help you since you've banned me from your issues section.
    Reading your above comment, you weren't going to do that anyway.

    Originally posted by sdack
    But go ahead, make your bugs the fault of all those who take the time to report the issues to you.
    Of course, asking for help is "blaming my bugs on the user".

    Originally posted by sdack
    Seeing how you're trying to dodge the license problem can we agree that wine-vulkan getting stuck on Vulkan 1.0 would have been an problem.
    I'm not trying to dodge it, I'm saying that just building it as a wine module doesn't solve the issue all by itself (in fact you can build it with winegcc with some modifications, and it has been done), working around that would have required putting even more effort in by using native Vulkan libraries directly. But the same thing could have been done with the current code base, it's just that it would have been a major hassle either way.

    Yes, having to wait even longer would have been a problem, it has been a big enough problem already and that's exactly why I'm glad it has been finally resolved, as stated in my first comment on this thread.

    Leave a comment:


  • sdack
    replied
    Originally posted by VikingGe View Post
    If you don't provide what I need to reproduce and debug an issue, I can't fix your issue, and that's your fault and nobody else's.
    *lol* No. Your code, your responsibility and any bugs in it are all yours, too. Nor are your bugs my issue, but they are everyone's issue who use DXVK. But go ahead, make your bugs the fault of all those who take the time to report the issues to you. I certainly cannot help you since you've banned me from your issues section.

    Seeing how you're trying to dodge the license problem can we agree that wine-vulkan getting stuck on Vulkan 1.0 would have been an problem. So pretend all you want how it's a non-issue, but we both know you only got lucky that the license was updated as quickly as it did. I can only imagine how glad you must have been that it didn't end in some legal license nonsense. I know I was glad to see it change this fast and to work out so well. I then don't care for excuses. You don't owe me anything.
    Last edited by sdack; 05 June 2018, 10:29 AM.

    Leave a comment:


  • VikingGe
    replied
    Originally posted by sdack View Post
    If you cannot work on your code then that's your fault ands nobody else's.
    If you don't provide what I need to reproduce and debug an issue, I can't fix your issue, and that's your fault and nobody else's.

    Originally posted by sdack
    Feel free to explain to me how it's not stupid.
    Thunderbird explained that already on the last page. Learn to read.

    Originally posted by sdack
    And while you're at it, say if you had to wait for the license dispute to settle before you could hope to use Vulkan 1.1, or if you could have used 1.1 or parts of it if you had directly implemented it as a WINE component.
    Implementing it as a Wine component alone does not imply that it wouldn't rely on Wine's Vulkan code. If you were to use the Linux Vulkan loader directly, you'd still have to wire up the WSI stuff to somehow work with it (because, believe it or not, Linux drivers don't implement Win32 WSI extensions), while at the same time maintaining Windows compatibility because that's actually useful for debugging purpose (yes, people are actually doing that).

    Originally posted by sdack
    To point to WINE as a defense when somebody points out a flaw in your code design just shows how petty you are.
    Except that high wineserver overhead is actually a known issue and it doesn't even matter which D3D backend you're using. But yeah, let's complain about something that *maybe* reduces your framerate by 0.1 FPS and is an absolute non-issue in practice, because that totally makes sense.

    If you were complaining about a flaw in my code design, fine, but you're complaining about a non-issue.

    Leave a comment:


  • sdack
    replied
    Originally posted by VikingGe View Post
    Except that you're not criticizing anything. ... I don't need people like you.
    Yes, I am and you hate it. And who cares if you can work on your DXVK? People don't care for you, they care for their games. That's why they're using it, and not because of you. And that's also why I made the report and gathered more info so those who use it can have a better time. Nobody cares who you are or who you need, VikingGe. If your code has bugs and you cannot work on it then that's your fault and nobody else's.

    Regarding me calling others stupid, and I'll quote myself:
    And how would it make a project more sensitive to a specific wine version than they already are when you remove a layer? Only if you're stupid really.
    Feel free to explain to me how it's not stupid.

    And while you're at it, say if you had to wait for the license dispute to settle before you could hope to use Vulkan 1.1, or if you could have used 1.1 (or parts of it) if you had directly implemented it as a WINE component and not used wine-vulkan.

    Seems to me wine-vulkan has created an additional dependency, but maybe you're right and I'm the one being stupid for thinking it.
    Last edited by sdack; 05 June 2018, 08:46 AM.

    Leave a comment:


  • VikingGe
    replied
    Except that you're not criticizing anything. You haven't made any constructive suggestions on how to make anything better. The only thing you did is make claims that are blatantly false (the thing about winevulkan causing performance issues). I'm working with this code every day, you aren't, yet you're acting like you know it better that I do.

    You're just shittalking, literally calling people "stupid" right at the start of the discussion, and have no idea what you're even talking about.

    That said, banning you from my github is no loss. You haven't really contributed much besides a bug report that is lacking essential info so I can't even work on it. I don't need people like you.
    Last edited by VikingGe; 05 June 2018, 07:46 AM.

    Leave a comment:


  • sdack
    replied
    Originally posted by aksdb View Post
    Otherwise don't tell other people how to do their own projects.
    Well, that's the thing, isn't it? I never told him how to do it. He came to the forum and made a fool of himself all on his own. And now that it's been said does he not know how to deal with it. He could have just agreed and not cared for it any further. Yet he is quite upset about it. Funny.

    And yes, DXVK is a step forward. But lets not act like it was the greatest step ever or that it was perfect. People will drop it like a turd the moment someone puts something similar directly into WINE. So you might want to keep it real. Or go nuts and go angry, whatever keeps you happy.

    At the same time are people getting paranoid when Microsoft buys GitHub, while projects such as DXVK produce Windows DLLs and distributes these as binaries over GitHub as a solution for Linux.

    Best part is, after I've been helping out at GitHub with DXVK on some issues has he banned me from it now. I haven't said a single bad word about him or his project there, only been helping others with it, and because he got baited and trigger here on Phoronix has he banned me from making further comments on issues. Hilarious. What a petty character he turns out to be. Goes mad on criticism.

    VikingGe Did I make you sad? I'm so sorry...
    Last edited by sdack; 05 June 2018, 07:33 AM.

    Leave a comment:


  • notaz
    replied
    Originally posted by sdack View Post
    You need numbers first? Seriously? It's obvious nonsense to implement DXVK as a Windows DLL instead of a WINE DLL. You really don't get this? That's so sad.
    How is this obvious for an API designed to reduce number or calls? The cycles wasted in occasional calls is unlikely to have measurable perf impact, so please enlighten us with some proof with some testcase at least. Talk is cheap, show us the numbers.

    Leave a comment:


  • aksdb
    replied
    Originally posted by sdack View Post
    You need numbers first? Seriously? It's obvious nonsense to implement DXVK as a Windows DLL instead of a WINE DLL. You really don't get this? That's so sad.
    If you pay someone to do work, you can enforce policies and rules all you want. As long as you don't put VikingGe under contract, just let him do what he does, the way he likes to do it. Nobody works on anything in his free time if he doesn't get anything out of it. I wouldn't use C either, simply because I would have close to zero fun in doing so.

    So if you think you can do better: GO AHEAD! Otherwise don't tell other people how to do their own projects.

    @VikingGe: thanks for your work. DXVK is really a big step forward and makes me pretty hopeful that I can (finally) ditch the dual boot Windows much sooner than I feared.

    Leave a comment:


  • sdack
    replied
    Originally posted by VikingGe View Post
    So, if you're so confident about winevulkan having a substantial impact on DXVK performance, where are your numbers to prove it?

    Why aren't you ranting about wine's implementation of synchronization primitives instead which actually kills performance in certain games?
    You need numbers first? Seriously? It's obvious nonsense to implement DXVK as a Windows DLL instead of a WINE DLL. You really don't get this? That's so sad.

    To point to WINE as a defense when somebody points out a flaw in your code design just shows how petty you are. Nothing great about you after all. Just another solo artist, a one-trick-pony.

    Nobody is forcing you to use it.
    *lol* Let's start with the question of who is using it under Windows. Maybe then perhaps we can ask why they would feel forced to use it, but you're definitely an idiot when this is your answer.
    Last edited by sdack; 05 June 2018, 04:35 AM.

    Leave a comment:

Working...
X