Quoting: Alm888I absolutely hope it gets rejected.

The last thing I want in the distro I use is some 3rd-party fork instead of upstream version. Otherwise WINE won't have any patches from Fedora anymore, as (rumor has it) DXVK does not play nice with WINE, outright conflicting with its libraries.

You can down-vote me to hell (well, except you can't ;) ), but I am firmly on WINE's side in their conflict.

DXVK guy is nobody and nothing without WINE (he can go sell his library to Windows users for all I care; I've heard it works on Windows™), he is in no position to bring incompatibility in a piece of software that: a) existed long before he even started his project; and b) enabled a lot of critical Windows™ applications to work in Linux (Winamp with its plug-ins, many of which have no Linux alternative, custom-built game resources extractors, banking software).

Prioritizing some custom upsetream-incompatible library over vanilla version is like a tail wagging a dog!

Everyone who absolutely WANTS DXVK-version can go to… Steam and install Proton™!!!

Wow wow wow!, you went from 0 to a 100 km/h in less than .1 seconds :p

I suggest you to read the Fedora proposal:

Quoting: Fedora ProposalDXVK is available as a wine-dxvk package since Fedora 31. wine-dxvk package uses alternatives system for following wine dll files: d3d9, d3d10.dll and d3d11.dll .

Should this proposal be accepted, a Pull Request will be merged into the wine-dxvk package which ensures it gets set as default backend only on systems with Vulkan support. wine-dxvk will then get added as "Recommends: wine-dxvk" into the wine package itself.

Users can run 'dnf reinstall wine-dxvk' after changing hardware configuration to get alternatives to use DXVK or wined3d updated.

So, it's not that wine+dxvk (which seems to be an already available option) will completely replace wine but that it will be the default option from now on for system that have a GPU that supports Vulkan API.

BTW, I think that this are the guys to blame for this blasphemy: Frantisek Zatloukal & Michael Cronenworth

View this comment - View article - View full comments

Working fine with Mesa 20.1.2 -- RX 580, Epic graphics, 55-60 fps (vsync activated by default). There is some stuttering here and there while compiling shaders but it's normal.

View this comment - View article - View full comments

Quoting: TheRiddick

Quoting: ShmerlSo it doesn't increase quality,

I don't think you understand whats going on one bit. But 'when' everyone is doing similar things as to what DLSS does, I'll watch you eat your own hat! :)

Also as someone pointed out, native everything would be great, but lets face it, unless a magical fairy comes down from the silicon heavens and unleashes a compute power revolution, then we aren't going to see CPU's or GPU's for the consumer handle future graphics very well without some way to 'optimize' performance at higher resolutions or fps.

In saying that DLSS2.0 has shown that in areas a 1440p image can look better then 2160p, its not universal but it CAN look decently better in areas.

The elephant in the room here is that this features will probably never work/be used on Linux. I understand that Nvidia has the feature in their Linux driver now but, how you will be able to use it if all games that support it are Windows only? Do you think that Nvidia will work on wine in order to give support?

The same can be said for RT on Linux. AFAIK there is only game that supports RT on Linux.

So, from a Linux market point of view, aren't all this gimmick features?

View this comment - View article - View full comments

Quoting: HamishYeah, it seems that what exactly triggers the game to crash is variable. I have had it crash at different points with different Mesa versions.

I ended up finishing the game (no idea about the story, I should have start by the first one :P) and didn't get any crash. I used the default Mesa packages from Ubuntu 18.04 (i.e. Mesa 19.2.8). Are you sure that the issue is related to Mesa?

BTW, I played Steam version.

View this comment - View article - View full comments

Quoting: HamishFor what it is worth, I found with Requiem that the game will crash when you pick up the first audio log from Eloff Carpenter.

I've installed the game and finished the snow level (I'm now in the Alien facility... if I can call it that way XD). You get the crash when you open the log of the first level?

View this comment - View article - View full comments

Quoting: HamishThat output is from my trying to use the DEBUG_CFLAGS in makepkg.conf, not from when I was exporting my own values in the PKGBUILD. Here is the relevant Meson log for that:
Project name: mesa
Project version: 20.1.2
Using 'CC' from environment with value: 'gcc -m32'
Using 'CFLAGS' from environment with value: '-O0'
Using 'LDFLAGS' from environment with value: '-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
Using 'CPPFLAGS' from environment with value: '-D_FORTIFY_SOURCE=2'
None of 'CC_LD' are defined in the environment, not changing global flags.

And Penumbra still crashes.

I'm not sure if will help, but try removing "-01" from LDFLAGS and the same for link time optimizations (set b_lto to false)

View this comment - View article - View full comments

Quoting: HamishI have tried exporting my own CFLAGS in the PKGBUILD containing just the "-O0" flag and with that I can get the lib32-mesa package to build, but Penumbra will still crash when using these builds. I have also tried using the Meson c_args option to set the "-O0" flag to no good effect. I have also tried setting the various "-mno-sse" flags which again do nothing.

But the output of meson configuration shows a mixture of flags (In the output of your first comment you can clearly see that DEBUG_CFLAGS has been appended to CFLAGS). I suggest you to clear your env. variables and start from scratch.

View this comment - View article - View full comments

Quoting: HamishAttempting to build Mesa as described before now just results in this error:
Build started at 2020-07-05T10:15:07.706677
Main binary: /usr/bin/python
Build Options: -Db_lto=true -Db_pie=true -Db_ndebug=true -Dplatforms=x11,wayland,drm,surfaceless -Ddri-drivers=i915,i965,r100,r200,nouveau -Dgallium-drivers=r300,r600,radeonsi,nouveau,virgl,svga,swrast,iris -Dvulkan-drivers=amd,intel -Dvulkan-overlay-layer=true -Dvulkan-device-select-layer=true -Dswr-arches=avx,avx2 -Ddri3=true -Degl=true -Dgallium-extra-hud=true -Dgallium-nine=true -Dgallium-omx=disabled -Dgallium-opencl=icd -Dgallium-va=true -Dgallium-vdpau=true -Dgallium-xa=true -Dgallium-xvmc=false -Dgbm=true -Dgles1=false -Dgles2=true -Dglvnd=true -Dglx=dri -Dlibunwind=true -Dllvm=true -Dlmsensors=true -Dosmesa=gallium -Dshared-glapi=true -Dvalgrind=false -Dprefix=/usr -Dlibdir=/usr/lib32 -Dlibexecdir=lib -Dsbindir=bin -Dauto_features=enabled -Dbuildtype=plain -Dwrap_mode=nodownload '--native-file crossfile.ini'
Python system: Linux
The Meson build system
Version: 0.54.3
Source dir: /home/hamish/Downloads/lib32-mesa/src/mesa-20.1.2
Build dir: /home/hamish/Downloads/lib32-mesa/src/build
Build type: native build
Program python found: YES (/usr/bin/python)
Running command: /usr/bin/python bin/meson_get_version.py
--- stdout ---
20.1.2
--- stderr ---


None of 'PKG_CONFIG_PATH' are defined in the environment, not changing global flags.
None of 'PKG_CONFIG_PATH' are defined in the environment, not changing global flags.
Project name: mesa
Project version: 20.1.2
Using 'CFLAGS' from environment with value: '-march=x86-64 -mtune=generic -O3 -pipe -fno-plt -g -fvar-tracking-assignment -O0 -fdebug-prefix-map=/home/hamish/Downloads/lib32-mesa/src=/usr/src/debug'
Using 'LDFLAGS' from environment with value: '-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
Using 'CPPFLAGS' from environment with value: '-D_FORTIFY_SOURCE=2'

mesa-20.1.2/meson.build:21:0: ERROR: Unable to determine dynamic linker

Which is kind of annoying as I never got around to completing Requiem yet.

Can you share the content of "crossfile.ini"? Also, your CFLAGS have -O3 and -O0 at the same time.

View this comment - View article - View full comments

Quoting: Ehvis

Quoting: x_wingThe game works. The only problem is an erroneous deploy on Steam + a bug on the content selection. The attitude makes me remember by a lot to Garry Newman.

I tried it a week or two ago and it crashed on startup with no immediately clear indication of what the problem was.

Open your game directory, rename/remove "Supraland/Content/Paks/Supraland-WindowsNoEditor.pak" and the game will run flawlessly.

View this comment - View article - View full comments

Quoting: constI would have highly prefered had people asked the dev to move the linux build to a beta repo. The way it went, I am quite angry on the loud people who demanded the developer to remove the linux version all together. Switching to Proton is a matter of 2 clicks, but after removing the native version no one can use it any more. That's a decision loud people from the community have tailored and now those who have a different opinion can only live with.
Yes, with that atitute, we will only have proton in a few years. We are ok with developers ignoring the platform alltogether. We celebrate those that *even by luck* create good ports. We even celebrate those that ignore us but implement a Vulkan renderer.
But a developer who supported us for years doesn't release his newest title to linux or has issues to continue support?. Grab your forks.

But hey, maybe Valve will save us. Amazing community.

I agree with you in some points of the general attitude of the community. BUT the behavior of the dev is far from professional at this point and the way he has been handling the situation is completely nonsense. Anyway, I give you the point that in the past many from the community were more supportive to guys like Garry, which had a way worst behavior than this guy.

View this comment - View article - View full comments