Hmm... so what's the point behind AMDVLK then? Is there any reason why it should continue to be maintained?
Announcement
Collapse
No announcement yet.
RADV vs. AMDVLK Vulkan Drivers Continue Stiff Performance Battle
Collapse
X
-
Originally posted by sarmad View PostHmm... so what's the point behind AMDVLK then? Is there any reason why it should continue to be maintained?
Edit: Similar story with HipHop / HHVM and PHP 6/7 performanceLast edited by helland; 18 April 2018, 03:26 PM.
- Likes 9
Comment
-
Once the CPU bound issues are resolved eventually, AMDVLK and RADV will merge with AMDVLK effectively absorbing the bits that make sense. Or people can keep them separate with AMDVLK absorbing the bits and expanding its overall lead as the code base matures and the cross-platform strategy steadily matures with shared optimizations.
Comment
-
Hey AMD, why not just climb on-board RADV for the Linux target? That's were all the cool kids want to be.Last edited by Xaero_Vincent; 18 April 2018, 04:04 PM.
- Likes 2
Comment
-
Originally posted by marek View PostValve seems to lead RADV development and Feral also contributes to it. That might indicate what game developers care about.
In industry it is normal that everbody does his job, so game developers should do game development and driver developers should do driver development... these might only share ideas and bugs of course
Do you want perfect driver? Cool, then game developers should be like any other user, yes like any other. Just share ideas (and code) and bugs, ideas and bugs... and pretty much nothing else
Real game developers won't touch your driver, they would only say "please implement this or that, please fix this or that, etc..".Last edited by dungeon; 18 April 2018, 07:22 PM.
Comment
-
-
Originally posted by tomtomme View PostGuys. Most of you seem to forget that amdvlk has a big userbase on windows.
As a developer, why would I bother with it? Everyone and their mother targets RADV on Linux. It's part of Mesa so people usually have it installed anyway (if not, there's a package for it), it works reasonably well, it's actively being tested with a lot of Vulkan games, and if you have a problem with it, it's easy to get in touch with the devs and get things fixed (unless it's an LLVM bug, but AMDVLK runs into those as well). If you need support for a new Vulkan extension, annoy them for a bit and eventually you'll get your extension implemented.
It's not a bad thing that AMDVLK exists as an open-source driver, quite the contrary. To AMD's credit, they *do* take bug reports seriously and fix them in a resonable amount of time. But I really don't see why the average Linux gamer would start using it over RADV.
Originally posted by SethDusek View PostMaybe if they follow the vulkan spec properly instead of doing driver-specific hacks, that AAA game will work fine on pretty much any driver?
Spoiler: It isn't. Just recently I spent one and a half days debugging this little issue in RADV which broke FInal Fantasy 14. On the Nvidia side of things, this small bug popped up a few days ago which prevents some games from running.
No CTS test or real-world application have triggered those bugs before so nobody noticed them until now. And you'll always stuble across issues like that. Especially since we're not talking about an old API like D3D11 here that has been around for almost a decade with a massive user base. This is Vulkan, 2 years old, used almost exclusively for Linux gaming and mobile devices.Last edited by VikingGe; 18 April 2018, 06:50 PM.
- Likes 3
Comment
-
Originally posted by tomtomme View Post
But amdvlk is largely Amds windows driver. Only very limited manpower is needed to drop the new windows Vulkan driver code every week once the Linux build system for the driver was up and running. Legal review was likely what took them so long
I'm curious if the legal reviews still and will persist for AMDVLK? bridgman do you guys still have to go through those reviews before your code drops or is it non-existant now?
Comment
Comment