Quoting: GuestYou can generate motion vector data just like how video codecs do. Nvidia also has a sdk specifically for this (nvidia optical flow). I know that it has been used to add motion blur. I dont know how good it would look in practice for FSR3, it would depend on the type of game. It would be interesting to see somebody try it, especially as this can be done with the video encoding unit which is separate from the gpu so it shouldn't really affect performance of the game.

Edit: it seems like FSR 3 already has an option for this and is likely how they add FSR 3 to all games on windows with AMD hypr-rx. So technically it should also be possible to do this on linux too, in proton maybe.

I mean, to do it you need a sample over time. How are you going to do it from a single frame? So the game has to feed it to the library. Post processing filters that can be used without game's involvement work with a single frame.

View this comment - View article - View full comments

Quoting: NociferI'm crossing my fingers that it will be possible to compile it as a DLL and so add unofficial FSR3 support to already existing games, like we can do with DLSS.

I don't think it's possible without games actually using it directly. How would temporal anti-aliasing work otherwise? It's not a post processing filter like let's say vkbasalt.

View this comment - View article - View full comments

Quoting: redmcgI recently learnt that you can also configure WineD3D to translate DX10 and DX11 calls to Vulkan. You can do this in the registry (see 'renderer' @ https://wiki.winehq.org/Useful_Registry_Keys [External Link]) or with an environment variable; for example: WINE_D3D_CONFIG=renderer=vulkan.

That's possible, but as above, not worth doing it on Linux due to limited vkd3d features.

View this comment - View article - View full comments

Quoting: HohlraumI'm curious what impact Wayland Wine will have on gamescope?

I guess they might drop using X11 and use Wayland proper with it.

View this comment - View article - View full comments

Quoting: doragasuSomeone should make (maybe somebody has) a vd3d vs VKD3D-Proton vs DXVK for dummies, I am always lost about which one is for which use case.

In very short, vkd3d focuses on Vulkan compatibility that would work on macOS with MoltenVK which limits it a lot. Vkd3d-proton focuses on using all modern Vulkan features so it performs much better. So on Linux it's not even a question what to pick.

A bigger question is why Wine couldn't upstream both and use the limited one only on macOS.

View this comment - View article - View full comments

KDE is more attentive to gaming use cases than Gnome.

View this comment - View article - View full comments

Secrecy of console companies is such a total dinosaur of an idea.

It would be nice for Godot to compete with the likes of Unreal Engine.

View this comment - View article - View full comments

KDE supports it better, yeah. Except some scenarios where cursor breaks it, which I think is being addressed at Wayland protocol level before compositors will fix it. But Gnome just doesn't seem to focus on gaming use cases in general, so it takes them forever to add any adaptive sync support.

View this comment - View article - View full comments

Quoting: tohurinput lag from vsync has squat to do with refresh rate honesly

It has a lot to do with that I'd say. If refresh rate is low (60 Hz) and compositor waits for vertial sync, you'll notice lag. Tearing means compositor doesn't wait and draws even if it will result in jagged image, so you'll see updates before the full refresh cycle even happens, which in practice means lower latency (lag). That kind of scenario benefits from enabling tearing.

Scenario when your refresh rate is 144 Hz and more reduces the period of blanks low enough that you don't notice anything even if compositor waits for it. But more importantly, you need to have adaptive sync (VRR) in order to avoid unnecessary waits. That's an improvement of the old style vsync.

There was a thread about it here: https://www.gamingonlinux.com/forum/topic/5185/

Here is a useful diagram:



I think using Vulkan mailbox present mode above the monitor refresh rate is similar to what AMD means by "enhanced sync".

View this comment - View article - View full comments

Quoting: tohurbruh you clearly haven't compared GNOME vs KDE in this regard.. the Input lag in shooters and the such is bad enough it is noticeable lol. plenty of recent bug reports/ feature request out there to prove it is an issue now

I think Gnome's input lag has nothing to do with refresh rate, they just didn't optimize their own compositor for lower latency unlike KWin developers did. I.e. besides refresh rate delaying drawing, input lag can be caused by simply compositor doing any stuff before it's ready to draw. If you have too much of that - you'll have lag.

So yeah, Gnome might have such issue, but adding tearing won't help it if they don't optimize what they aren't doing efficiently, that's my point.

View this comment - View article - View full comments