Serious Sam Fusion 2017 Is Working Out Well For RADV Vulkan

[pal666]

Given what little manpower RADV has, I think it also shows that the Vulkan itself is a rather well-designed API for the most part. I mean, it can run pretty much all Linux Vulkan games in existence with merely ~31k lines of code.

it can run zero games without llvm

[VikingGe]

It shows that with DOOM on Nvidia [...]

...with a very powerful Intel CPU and an outdated Kepler card. That's the exact opposite of CPU-bound.

[indepe]

...with a very powerful Intel CPU and an outdated Kepler card. That's the exact opposite of CPU-bound.

So you are saying that the performance difference can be much larger? I would have no reason to disagree.

[dungeon]

Until things became clear GPU bound there is room for improvments

Until there is no minimal and recommended or whatever system requrements for PC games...well, shit will happen

[VikingGe]

So you are saying that the performance difference can be much larger? I would have no reason to disagree.

Well, it does depend on the system. With my old GTX 670, Vulkan was actually performing worse than OGL due to memory allocation issues - 2GB of VRAM just aren't enough for that game at 1080p with Vulkan. In 720p it was slightly better, but I didn't want to play like that. With my RX 480 I ran a test in a simple interior level, GL 70-90 FPS, Vulkan 150-180 FPS. CPU is an old, overclocked Phenom II X6. The game is also very well threaded when using Vulkan.

Now granted, AMD's OpenGL performance on windows is rather poor, but yes, it can definetly help when used properly. Sadly I can't compare with Mesa OpenGL becaue the game requires a compatibility context.

it can run zero games without llvm

You and your annoying one-liners. Of course it can't, but can Mesa's OpenGL functions alone run anything without a backend? No, they can't, yet they have a lot more code. And that's not because Mesa developers are incompetent, that's because the API forces them to implement lots and lots of things that have absolutely nothing to do with GPUs. Error checking, format conversions, all that kind of stuff.

[pal666]

Error checking, format conversions, all that kind of stuff.

it is irrelevant for our discussion. what is relevant is that most of radv code was written by someone else and/or located outside of those 31k lines, they didn't write driver quickly, they wrote small part of driver quickly.

[bridgman]

Until things became clear GPU bound there is room for improvments

Even after that... mostly in the shader compiler area but a lot of other optimizations can also help even when the app under test is GPU-limited.

[duby229]

it is irrelevant for our discussion. what is relevant is that most of radv code was written by someone else and/or located outside of those 31k lines, they didn't write driver quickly, they wrote small part of driver quickly.

You tried pulling the same exact argument about Rust. You were wrong there just as much as you are wrong here. One compiles game code to LLVM-IR and another compiles LLVM-IR to native hardware code. That is fair enough all by itself.

[pal666]

You tried pulling the same exact argument about Rust.

i'm pretty sure that argument was different

You were wrong there just as much as you are wrong here.

of course i wasn't on both occasions, but not everyone is capable to understand that

One compiles game code to LLVM-IR and another compiles LLVM-IR to native hardware code. That is fair enough all by itself.

what is not fair is to compare speed of development of radv with speed of development of radeonsi when radv reuses most of radeonsi work in mesa, in kernel and in llvm backend

[duby229]

i'm pretty sure that argument was different
of course i wasn't on both occasions, but not everyone is capable to understand that
what is not fair is to compare speed of development of radv with speed of development of radeonsi when radv reuses most of radeonsi work in mesa, in kernel and in llvm backend

So thank goodness for radeonsi and llvm. It's a good thing.