Announcement

Collapse
No announcement yet.

DXVK 1.0.1 Released With Various Game Fixes For Direct3D On Vulkan

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

  • cbrunhaver
    replied
    Yeesh, I had a few typos in there.

    I've worked at both very large and very small companies and invariably they all have their own unique dysfunction. Things at AMD are certainly trending in the right direction. It is a bit sad that, as the progenitor of Vulkan, their linux efforts are behind others.

    The truth is that they need to maintain a windows vulkan driver and RADV being good won't change that. The LLVM compiler and other work bring done by AMD should benefit it as well, and I hope that both solutions get so good that the one with the highest maintenance burden ceases to exist.


    Leave a comment:


  • abott
    replied
    You're dumb to believe that. Internally an issue. Not even a concern outside. Like I said, AMD fucked up internally. They won't say it. But it's reality. It's even based on AMD IP!

    Leave a comment:


  • cbrunhaver
    replied
    This has been explained ad nauseum by Bridgeman and others on this forum. It is a legal minefield to open source things (because of the broken nature of the us patent system regarding software). They have multiple vulkan need to do it because it is their cross platform driver (with a different shader compiler), as the Linux specific bits are only a small part of the total effort.

    As an owner of only amd gpu (fury and 7950) I'm very happy with their big contributions to open source and understand that there are businesses motivations that don't always align with the ideal solution for the Linux platform but they are doing some great things these days and should be cut some slack

    Leave a comment:


  • skeevy420
    replied
    Originally posted by abott View Post
    RADV would have sucked less if AMD had contributed even a few patches to it. But RADV also existed buggy when AMDVLK didn't exist at all, so who cares if it was buggy? Not like AMD had anything to give you, at the time, like they had promised.
    Possibly, but I'm not going to fault AMD for wanting to focus their limited Linux manpower on their OS agnostic AMDVLK over the Linux-specific RADV. They need a driver that works with Windows, Linux, BSD (powers the PS4/probably PS5), OSX, Windows fox Xbox, and probably more; it's just common sense for them to want to focus on AMDVLK and an overall driver stack that's OS agnostic and works the same for everyone. It's a daunting and laudable goal.

    Also, just tested the latest AMDVLK with The Witness and it didn't help at all. Don't ya just love waking up to a Phoronix article that makes you want to go and compile software...

    FWIW, we can make the same complaints about Nvidia, EGLStreams, and the usage of freakin' standards.

    Leave a comment:


  • abott
    replied
    RADV would have sucked less if AMD had contributed even a few patches to it. But RADV also existed buggy when AMDVLK didn't exist at all, so who cares if it was buggy? Not like AMD had anything to give you, at the time, like they had promised.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by abott View Post
    Yet again, people said it was good AMD had their own driver out. In reality, it really fucked everyone by wasting a year doing it. And it wasted what vulkan gave AMD (a chance to base on Linux AND Windows both, but they didn't) and it really screwed the pooch everywhere. If they just documented the nuances and more stuff during that time instead of wasting thousands of hours of work porting it, they could have just helped the community more. Thanks, AMD management. Not the devs fault, it's here and okay to have AMDVLK as long as it never gets worked on outside of AMD. But AMD needs to admit defeat and look to help RADV. It's better.


    Really, really bad managment/guidance from before Vulkan was even really alive internally. This is about supporting mesa and open source, after all, right? AMD failed to provide that even on a completely new driver. I'll assume from here on out, we're all on the same page, right? It looks like I should buy Bas and Tim A. some beers for their work.
    No need to rag on AMDVLK so hard. With my previous GPU a year ago, RADV sucked ass trying to play Mad Max and AMDVLK didn't (both give 60fps smooth with my current GPU). With Retroarch, some of the emulators work better with AMDVLK, some work better with RADV. Neither Vulkan implementation is perfect. I'm just glad that we have options.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by Calinou View Post

    Thanks for mentioning libstrangle! I didn't know there was a program to limit the FPS of any given application on Linux.

    For those who are interested in it, here's the link: https://gitlab.com/torkel104/libstrangle
    There's also another Vulkan-only FPS Limiter, VKGHL: https://github.com/pchome/VkGHL. According to its readme, it supports the same variables that libstrangle does. I stumbled across that one night before last so I've never actually used it. It isn't on the top of my priorities since libstrangle has the same variables and works with both OGL and Vulkan.

    Leave a comment:


  • Calinou
    replied
    Originally posted by skeevy420 View Post
    Just checked before posting and the lagging and slowdowns are gone with DXVK 1.0.1...no need to cap The Witness to 30 fps anymore. Tested by running around the treehouse area like a jackass with both 1.0 and 1.0.1 using the Lutris tkg-4.3 wine build with and without the FPS env variable. That's great, one less hack to play a game. Still gonna use libstrangle for the PICMIP and AF variables though.
    Thanks for mentioning libstrangle! I didn't know there was a program to limit the FPS of any given application on Linux.

    For those who are interested in it, here's the link: https://gitlab.com/torkel104/libstrangle

    Leave a comment:


  • Guest
    Guest replied
    This is an awesome project, and I'm glad it was done. I played Skyrim on Linux, it was amazingly smooth. Witcher 3 still doesn't work well, I'll have to try it out later with this new version and see if anything's changed.

    Also, I'm curious about the Vulkan on Bay Trail - does Bay Trail actually support Vulkan? I had the impression it was the same as the Ivy Bridge GPU, and therefore couldn't run Vulkan. If it can actually support, that would be awesome!

    Leave a comment:


  • abott
    replied
    Yet again, people said it was good AMD had their own driver out. In reality, it really fucked everyone by wasting a year doing it. And it wasted what vulkan gave AMD (a chance to base on Linux AND Windows both, but they didn't) and it really screwed the pooch everywhere. If they just documented the nuances and more stuff during that time instead of wasting thousands of hours of work porting it, they could have just helped the community more. Thanks, AMD management. Not the devs fault, it's here and okay to have AMDVLK as long as it never gets worked on outside of AMD. But AMD needs to admit defeat and look to help RADV. It's better.


    Really, really bad managment/guidance from before Vulkan was even really alive internally. This is about supporting mesa and open source, after all, right? AMD failed to provide that even on a completely new driver. I'll assume from here on out, we're all on the same page, right? It looks like I should buy Bas and Tim A. some beers for their work.

    Leave a comment:

Working...
X