TW3 in Wine/esync+dxvk

amdgpu/llvm

aco:

Not bad! It produced around +3 fps for me on average (+3.6% improvement) in the busy street in Novigrad.

GPU: Sapphire Pulse Vega 56
Resolution: 1920x1200.
CPU: AMD Ryzen 7 2700X.

I had to use llvm 8.0.1 though, since 9.0 snapshot currently causes a GPU hang. So would be interesting to compare with 9.0 once it will be fixed.

I don't have blender installed currently, but if you have some instructions how to do it (specific scenario?) I can try.

Plus, I'm not sure how recent Blender is in Debian testing now, due to freeze (it will end soon though).

I was wondering, should we clear the shaders cache?

I was wondering, should we clear the shaders cache?

Mesa does it by the version, so I'd say no need. New build will have a different version.

I think it's currently only active for radv, so OpenGL benchmarks will need to wait.

They plan to enable it for radeonsi, but now focus on radv.

Q: Is it radv-only or will RadeonSI work?
A: radv for now, but we intend to look at RadeonSI once things are farther along.

@Shmerl

I'm having troubles compiling. What flag should I pass to -dri-drivers?? seems that part is failing? just swrast is ok??

I used my usual Mesa build script (except using the relevant git repo for the source instead of upstream one). It built fine without setting any dri-drivers.

The relevant part ($arch_dir is my variable):

-Ddri-drivers= \
-Ddri-drivers-path="${arch_dir["64"]}" \
"-Dvulkan-drivers=amd" \

I usually only build radeonsi and radv, so not sure what's going on with Nine.

You can see how Debian builds stock Mesa here: https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=amd64&ver=19.1.1-1&stamp=1561995279&raw=0

I used that as a starting point for my script.

Since it's just for testing purposes, you can skip everything but radv altogether. Don't replace your regular Mesa with it. Just run the game on demand with the built one placed in dedicated location. That's what I do.

Well, using on-demand Mesa is very flexible, you can build whatever variant you want and run any game with it for testing purposes. No need to wait for packages.

Just tried Mesa-aco with X4: Foundations, and it works briefly, but then causes a GPU hang. I also didn't manage to make Mesa Vulkan overlay work with it for some reason. Did anyone try that?

for me Batman Arkham Knight has some freezes with dxvk. But overall, testing a few games with DXVK, framerates do increase notably.

Feel free to post comparison benchmarks here, so developers could take a look.

Also, please report any bugs like freezes here.

The overlay works for me just fine. But I used the PKGBUILD from the Aur in Arch Linux.

It works with X4? Interesting. Weird that it doesn't work for me. I'm using GOG version of the game. I wonder if it somehow prevents Vulkan layers from working?

You asked specifically about X4, I missed that part. Early in the morning. I tried it, but the results are the same, game starts, no overlay and than the game crashes quite fast.

Yeah, the hang is ACO related, but I was interested in why the overlay is not showing up. I.e. same thing happens with regular Mesa (except no hang). Anyway, it's really off-topic for ACO testing. I opened a Mesa bug.

I was wondering, should we clear the shaders cache?

I would like to see benchmarks with an empty shader cache, since this compiler was specifically designed with low compilation latency in mind :)

changing XDG_CACHE_DIR or whatever it is called should be enough, AFAIK, if you don't want to get rid of your old cache.

Just tried Mesa-aco with X4: Foundations, and it works briefly, but then causes a GPU hang. I also didn't manage to make Mesa Vulkan overlay work with it for some reason. Did anyone try that?

for me Batman Arkham Knight has some freezes with dxvk. But overall, testing a few games with DXVK, framerates do increase notably.

Could those freezes be due to building up the shader chache?

What mesa version is this ACO shader compiler forked from. Is it 19.1.X or the unreleased 19.2?
Doing comparisons against the wrong mesa version won't mean anything.

What mesa version is this ACO shader compiler forked from. Is it 19.1.X or the unreleased 19.2?
Doing comparisons against the wrong mesa version won't mean anything.

It's 19.2, AFAIK. In order to do a useful test, you should always run tests using the same compiled libraries with llvm and without it. From my point of view, that's the only way to get a fair results to compare.

Anyone tested Dying Light yet? The game is working OK, but everything is predominately gray (new compiler on/off doesn't matter) with this Mesa build:

I have my answer. Commit 6cc213b3c123a636baf07511c8e17ca32fb5da5a
to be exact. Which is 19.2-git.

So I tried compiling Mesa myself for the first time. Before I used the ppa referenced in the news article on GoL. I used your script @Shmerl but that did not work. I built the newest version of meson 0.51 but it kept looping endlessly on regenerating build files. Then I figured it is due to the compiler option meson --native-files and I deleted that.

Interesting. I'm still on Meson 0.49. Did newer Meson remove --native-files option? That part was needed to set correct llvm version when building, since my script supports choosing that.

Once Debian testing will get unfrozen (soon) and packages will refresh, I'll update my script if anything will be broken.

After that everything compiled and I tried launching vulkaninfo and games with LD_LIBRARY_PATH and VK_ICD_FILENAMES referenced to the build but all die saying bad driver.
What am I missing?

Not sure. How does the resulting ICD file look like? Does it point to the right location of .so? If not, place it where you want it, and manually edit the ICD JSON to point to the right place.