VKD3D 1.3 Being Prepared For Release

[Quackdoc]

This is all just flat out wrong. Basically none of vkd3d-proton is upstreamed ever and saying that "it's just a bunch of hacks" is pretty infuriating as it's simply not true.
It's an actual implementation of D3D12 on top of Vulkan using the latest features, any 'hacks'/per-game profiles that exist are there simply to work around genuine game bugs... y'know like actual drivers do.

If you are going to write 2 paragraphs trying to explain something, at least get it fucking right.

You have my sincere apologies.

I didn't mean to say that the code itself gets contributed upstream. but that there are a small number upstream commits are based on code from vkd3d-proton and that some devs who work on vkd3d-proton also occasionally contribute upstream. I also recall seeing other commits similar to what get merged in vkd3d-proton, but I supposed I was mistaken and was correlating two separate things. If I am wrong about the scale of cooperation I will gladly correct what I said. the combination the three made the impression that there was closer workings then there actually is and is what I meant by "work gets up streamed".

I didn't mean to imply that game specific fixes are a bad thing. Mesa does game specific fixes, and looking at change logs it's evident that AMD and Nvidia do as well for their windows counterparts. working around game bugs is a critical part of the job, If hacks aren't the right term for it I am not sure what the correct term would be. for me a hack has always been a specific change in the general program to do something else. I don't think that making a game work should be on the driver devs. to my group of peers, game specific changes, Kernel quirks, etc. would all be "hacks" designed to make up for the shortcomings of something else.

I also meant game related... changes that for instance, may reduce performance in more specialized applications. or apps that are broken that they don't benefit from fixing but upstream does. I don't necessarily mean d3d12 "compute" would be off the table. (DirectML for instance is something that could vkd3d-proton could supposedly benefit from though i don't know of any games that uses it but MS does advertise it). things like VEAI, I wouldn't try to use proton for, but rather upstream is what I meant.

again, you have my apologies, if you can elaborate on the corrections to be made I will gladly edit my post to reflect them, if not ill just point towards your comment.

[JoshuaAshton]

lots of work gets upstreamed. but since people don't understand the difference between the two ill explain it. Wine is used in commercial and enterprise (like crossover) software . this means they have stability obligations to keep. even on staging branch. You can think of "wine-staging (vkd3d included)" as a testing branch, and vkd3d-proton as a rolling release branch. but even without obligations, the end goal is still accuracy.

there is another distinction, vkd3d-proton houses a bunch of hacks that will never get accepted upstream that greatly help gaming performance. but can hurt conformance. which means this would actively be a bad think for wine to upstream. (as their goal is conformance) (Think of android emulation or early dolphin emulation where their are Emu and EMU-MMJ)



VEAI is actually pretty darn good. it all has it's uses (mainly for AMD LOL) but it also has somethings it beats out on, somethings it looses on. with AI upscaling there is no "best answer" just "this one worked the best for this input"

but there are other examples but none that I remember, so maybe not good ones

This is all just flat out wrong. Basically none of vkd3d-proton is upstreamed ever and saying that "it's just a bunch of hacks" is pretty infuriating as it's simply not true.
It's an actual implementation of D3D12 on top of Vulkan using the latest features, any 'hacks'/per-game profiles that exist are there simply to work around genuine game bugs... y'know like actual drivers do.

If you are going to write 2 paragraphs trying to explain something, at least get it fucking right.

[brucethemoose]

Alright, I think I saw it mentioned before and will look into that.



I use both of these already in mpv, though I barely see any difference with FSRCNNX, not sure if it's worth it? Anime4K is awesome, but it'd be too much for non anime stuff...

I'll take a look at the discord. As for the 3 options above, hmmm are they to be used together or am I misunderstanding that?


Thanks guys!

Nah, 2 of the links are standalone GUI apps, the other is a database of ESRGAN models that do different things, which they are designed to work with.


Personally I use VapourSynth to manipulate videos with esrgan and other NNs, but its not quite so straightforward.

[Cybmax]

Thank you Quackdoc. That was very informative. I had no idea that there were quirks in Proton that deprecate conformity. I see that things are much more complicated than I realized.

Think of it like this: A formula1 racing team uses new experimental technology - experimental turbos, NOS, suspension, engines revving at 15K rpm and whatever.. to win a race. Many of these "new experimental technologies" make their way back to the factory PRODUCTION cars eventually... But only after all the rigorous testing needed for a production car released for the average population.

They DO share their "codebase", and you can say the F1 factory racing teams contribute upstream patches... but you will only get it on the latest production car after it has been through a lot of tests, and sometimes this means it will NEVER see the light of day (Be it maintenance or safety issues)

Sometimes a 1-line "hack" in wine-proton that gets a game working requires huge changes to upstream wine to get released.

[geearf]

give ESRGAN a try, there are a few varients to choose from, I think right now the popular one is real-esrgan

Alright, I think I saw it mentioned before and will look into that.

Yeah, see the links I posted above:



As well as the gameupscale discord


FSRCNNX and Anime4K in MPV are very good for real time scalers though. The ones linked above are much slower.

I use both of these already in mpv, though I barely see any difference with FSRCNNX, not sure if it's worth it? Anime4K is awesome, but it'd be too much for non anime stuff...

I'll take a look at the discord. As for the 3 options above, hmmm are they to be used together or am I misunderstanding that?


Thanks guys!

[brucethemoose]

Wow that software is amazing!
Is there a native equivalent or a FOSS one?
I use a bunch of shaders with mpv, but it doesn't seem like they come close to this.
I also have some pictures/videos I took with a bad camera that I'd very much like to improve as much as possible.

Yeah, see the links I posted above:

(see this, this, and this)

As well as the gameupscale discord


FSRCNNX and Anime4K in MPV are very good for real time scalers though. The ones linked above are much slower.

[Quackdoc]

Wow that software is amazing!
Is there a native equivalent or a FOSS one?
I use a bunch of shaders with mpv, but it doesn't seem like they come close to this.
I also have some pictures/videos I took with a bad camera that I'd very much like to improve as much as possible.

give ESRGAN a try, there are a few varients to choose from, I think right now the popular one is real-esrgan

[geearf]

Off the top of my head, would be topaz labs VEAI. but thats all I can think of atm lol. but its a good one imo

Wow that software is amazing!
Is there a native equivalent or a FOSS one?
I use a bunch of shaders with mpv, but it doesn't seem like they come close to this.
I also have some pictures/videos I took with a bad camera that I'd very much like to improve as much as possible.

[Quackdoc]

Perhaps there should be 2 separate "modes" under the same project? Or are Proton's/dxvk's hacks too spicy to even exist in the Wine codebase?

not really, while dxvk/proton have similar trajections, but they don't exactly align, keeping them separate projects IMO would be for the best. keeping them separate distinct things give's a degree of freedom to dxvk that might otherwise not be possible.

don't forget that DXVK is laser focused on a single thing. I think it's best for DXVK to remain independent, IMO dxvk has likely been able to flourish so much because it is it's own thing

[brucethemoose]

same situation with dxvk. everyone complains about wanting dxvk to be upstream wine d3d implementation, but both dxvk devs and wine devs say that it will never happen, because dxvk makes compromises that wine cannot accept for technical reasons.

Perhaps there should be 2 separate "modes" under the same project? Or are Proton's/dxvk's hacks too spicy to even exist in the Wine codebase?