Quoting: 14If Cyberpunk 2077 was coming to Linux, I would be looking at that RX 6800 instead of a PS5.

If it's not, it will work with vkd3d-proton eventually. But I'll probably wait until it's discounted. RX 6800 or RX 6800XT will still be quite useful for it.

View this comment - View article - View full comments

Quoting: mawhrin-skelAlso, and brace yourselves, but G-SYNC works out of the box in Linux. FreeSync doesn't, and it can barely be said to work *at all* with its "only-up-to-90 Hz" limitation.

Never had any problems with adaptive sync. I'm using LG 27GL850. Adaptive sync is fine up to 144 Hz and LFC works fine as well.

Gsync can't work out of the box unless your monitor has some proprietary module in it. That's an instant no go for me.

View this comment - View article - View full comments

Quoting: x_wingI suggest you to read my second paragraph... but at this point I think that you don't care about what others understands for native applications.

Well, I explained my idea of non native quite clearly before. That's what I was referring to.

View this comment - View article - View full comments

I think I explained it above, but let's clarify further:

Native:

application → abstraction → system API → …. → hardware

Non native:

application → abstraction → foreign system API → translation → system API …. → hardware

View this comment - View article - View full comments

SDL is an abstraction that sits above windowing subsystem.

Higher level abstractions don't make things non native, but if you need translate one lower level abstraction to another one because the first isn't supproted, that makes things non native.

I.e. DirectX is native on Windows. It's not native on Linux, so you need to plug all DirectX logic into Vulkan one if you aren't rewriting your code to use Vulkan one directly but used DirectX directly.

Let's say you wrote your code using gfx-rs that can target both Vulkan and DirectX. Then you don't need to replug anything. You are already using an abstraction that can work with both. I hope that explains the difference which I meant.

Basically, abstractions can be helpful. Translating things is a shortcut when you don't want to rewrite them (even if in higher abstractions). Translations add performance cost. Abstractions don't need to, in theory.

View this comment - View article - View full comments

Quoting: Avehicle7887Time for some GPU Porn: https://phonemantra.com/gigabyte-and-sapphire-unveil-reference-radeon-rx-6800-and-rx-6800-xt/ [External Link]

Looks like I'm going with the Sapphire 6800XT all the way.

I wonder how custom designs from Sapphire will look like. Reference design is already on the level of what they used to make as custom before.

View this comment - View article - View full comments

Non tative means taking totally foreign (especially lock-in oriented) API like DirectX and re-plugging it to work with native one.

If you need to translate lock-in, I'd surely call it non native, VM or not.

View this comment - View article - View full comments

Quoting: x_wingIMO, going very high in PSU wattage is not always the best for efficiency as your computer will probably by idling more than 50% of the time (or more than 90% if you keep it always on... like me) and you will probably get better efficiency with a certificated PSU that has a wattage more in line with your total system consumption.

I got 750W one and so far it was enough. You can get good quality efficient PSU to reduce power wasting:

https://seasonic.com/prime-ultra-titanium [External Link]

View this comment - View article - View full comments

Yeah, in the end what does it matter, if it performs well and is supported by developers. It's actually good they are using open source tools like dxvk, instead of closed ones like Feral do.

View this comment - View article - View full comments

You could use dxvk without Wine, yes. But it's still wrapping, not a fully native renderer. That's why Feral ones aren't really native either.

By native renderer I mean one that doesn't need translating DX abstractions into Vulkan ones (on whatever stage, at compile time, at runtime etc.).

View this comment - View article - View full comments