On this one: isn’t amd moving to DLL based? So they can upgrade the FSR relatively easy for a title without requiring a patch?
Direct3D feature levels discussion
- Thread starter DmitryKo
- Start date
Yes, but not sure wether that applies to this or not.
DirectSR is not an upscaler technique it's a standard wrapper API like Nvidia Streamline, for the various temporal upscalers. FSR2 is shipped with DirectSR runtime as the default implementation.
Since it will ship with FSR2 in it you can call it "an upscaler technique".
Well it needs to be the worst one because it’s also the most widely supported one.
As to why ship anything at all - that’s a good question. I can’t imagine Nvidia and Intel being happy with FSR. Or Microsoft for that matter. My guess is it was a compromise to maximize adoption since there is no requirement for IHVs to explicitly support FSR in their hardware/drivers.
I don't think that there's a sizeable difference in h/w support between FSR2 and XeSS DP4a. FSR2 could work better on some really old and/or slow GPUs but we're still talking about some 10-20% of difference most likely. The choice of FSR2 for an API coming in 2025 is a weird one as by that moment even AMD may add some sort of ML processing to their future FSR versions.
Yeah. The API shouldn't have a "standard implementation" in it. As it stands now it just seem to give AMD a sort of a competitive edge since they won't need to include FSR2 into their drivers.
But the "adoption" will still happen on the driver side for ~90% of the market.
arandomguy
Regular
It seems like the option would either be FSR2, really likely a fork of FSR2, or MS developing their own solution or Nvidia/Intel proposing their own open (actually open, not just in name) agnostic solution.
There needs be clarification here in that XeSS isn't actually open in code or license at this point despite the marketing points.
I'm also not sure if a ML solution can be open enough in that someone is going to have to be responsible for training.
So would MS want to develope and train their own ML model?
There needs be clarification here in that XeSS isn't actually open in code or license at this point despite the marketing points.
I'm also not sure if a ML solution can be open enough in that someone is going to have to be responsible for training.
So would MS want to develope and train their own ML model?
Neither is DirectX. Something integrated in it doesn't have to be "open".
Short lived advantage if AMD hopes to play in the ML space or update shader based FSR in the future.
Yeah either way Nvidia and Intel will continue to do their thing.
One benefit of the bundling is that devs don’t need to worry about testing individual 3rd party implementations when developing their games. They can just test with the built-in crappy upscaler that works on everything.
That's a good point. Is MS thinking of making DirectX open source so the implementation will be transparent? Last thing we need is another Starfield moment.
arandomguy
Regular
FSR2 being open source and license is pertinent for practical reasons and not ideological ones (I actually dislike that narrative with open source branding).
DirectX being closed is fine of course for MS because they own it.
So the equivalent would be if Intel were willing to hand over XeSS to MS. Something I suspect Intel probably wouldn't want to do.
"if it ain´t broke, don´t fix it "
Last edited:
All IHVs regularly license tech to MS to be included into DX (or Windows for that matter), there is nothing new in this.
Regardless of what the AMD rep said, MS slides say there will be more than just FSR2 "built-in" - they were in plural.
Also pretty damn sure the included FSR2 is bog standard version too, and when you support DXSR you support it and any other DXSR compatible solution regardless if it ships with DXSR or IHV drivers, no extra magic no burying deep within DXSR code or whatever
Also pretty damn sure the included FSR2 is bog standard version too, and when you support DXSR you support it and any other DXSR compatible solution regardless if it ships with DXSR or IHV drivers, no extra magic no burying deep within DXSR code or whatever
arandomguy
Regular
I'm guessing we're just not seeing the same issue here.
There's differing levels of licenses and IP transfer. If Intel controls and is in charge of developing XeSS and XeSS were the "standard" model this does not give MS the same level of control as MS outright owning the technology or a permissive open source license. I doubt AMD and Nvidia would be happy with that option either. Let's not beat around the bush, we see this type of reluctance to adopt competitor technology all the time, it's not a direct money issue but because it helps push something towards a standard than can act as a poison pill which can be rug pulled at anytime.
Would Intel want to completely hand over XeSS at that level to MS as in ceding all control of it going forward?
I'm also not seeing the angle here that having FSR2 as the base model conveys some sort of advantage to AMD and bias against the other IHVs. What would the alternative proposal from other IHVs even be? Do they even care?
Let's look at Nvida for instance, does Nvidia want to push DLSS as the base model? If they did want to develop a lower quality path they've had ample opportunity and leverage to do so. Yet there overall strategy indicates they aren't interested in priotizing their software advantages as some sort of mass commodity.
Intel did develop the DP4A path of XeSS but that seems more like they needed more benefits to push XeSS itself as they themselves have low market leverage due to the being the newest entrant and low market presence. DirectSR would address that issue without Intel having to essentially give away XeSS to competitor's customers.
I know the caveat here is that it's likely from the user side people without Intel hardware or not the latest (well at this point rather dated) Nvidia hardware want something better than FSR2 for "free" basically, but that isn't really the issue for either IHV.
FSR2 is the most widely supported. While technically XeSS Dp4a edition runs on most cards it also comes with a pretty decent performance penalty in my experience.
My hot take (at least, in hardware enthusiast circles): FSR2 isn't THAT bad and 95% of the time I forget I'm running it vs something like DLSS. I actually tested this on myself today in Warzone, I forgot I switched from DLSS to FSR2 to try it out. The only way I eventually remembered was the game actually doesn't expose a sharpening slider for FSR2 so I noticed my image seemed more sharpened than usual (I usually run DLSS with 0 sharpening). Granted this is at 4k Performance on a TV about 6 feet away, so your milage may vary if you are running 1440p on a monitor less than a foot away.
I agree. It was only a few short years ago that AAA games were shipping with no upscaling solution at all, or their own basic internal upscalers. It still happens now on occasion and likely happens far more often on less high profile games.
FSR2 is a big improvement over those scenarios in most cases so having it as a minimum baseline is a great thing IMO. As you say FSR2 is generally pretty decent, especially in its quality form at higher resolutions and it tends to get a bad rap either from overly aggressive use in consoles or from focusing on corner cases where it does fair poorly, at least in comparison to better upscalers. There is then.the runaway narrative that's its generally terrible and should die a quick death which I disagree with.
And if I understand how DirectSR is to work, then if its implemented, DLSS and XeSS will automatically be available to Mvidia and Intel users respectively if their hardware supports it (implemented from driver side), as will any future superior version of FSR to AMD users where supported.
So FSR2 will only be the absolute baseline/safety net upscaler for anyone with hardware that doesn't support anything better. That's a win/win IMO.
Sadly, no since they stopped offering builds for the dynamically linked version of the library because most game developers prefer to implement it as a static library when it makes dependency management and compatibility support simpler for them. That being said, you can still build the library yourself if you want the alternate DLL form ...