PC Gaming

8765 readers

507 users here now

For PC gaming news and discussion. PCGamingWiki

Rules:

Be Respectful.
No Spam or Porn.
No Advertising.
No Memes.
No Tech Support.
No questions about buying/building computers.
No game suggestions, friend requests, surveys, or begging.
No Let's Plays, streams, highlight reels/montages, random videos or shorts.
No off-topic posts/comments, within reason.
Use the original source, no clickbait titles, no duplicates. (Submissions should be from the original source if possible, unless from paywalled or non-english sources. If the title is clickbait or lacks context you may lightly edit the title.)

founded 2 years ago

MODERATORS

EXiLExJD@lemmy.ca

UncleBadTouch@lemmy.ca

KairuByte@lemmy.dbzer0.com

Intel researchers create a method for AI-generating frames in games without added input latency (www.pcgamer.com)

submitted 1 week ago by alessandro@lemmy.ca to c/pcgaming@lemmy.ca

27 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] sp3tr4l@lemmy.zip 1 points 1 week ago (1 children)

... I mean, in an academic sense, if you possess the ability to implement the method, sure you can make your own code and do this yourself on whatever hardware you want, train your own models, etc.

But from a practical standpoint of an average computer hardware user, no, you I don't think you can just use this method on any hardware you want with ease, you'll be reliant on official drivers which just do not support / are not officially released for a whole ton of hardware.

Not many average users are going to have the time or skillset required to write their own inplementations, train and tweak the AI models for every different game at every different resolution for whichever GPUs / NPUs etc the way massive corporations do.

It'll be a ready to go feature of various GPUs and NPUs and SoCs and whatever, designed and manufactured by Intel, reliant on drivers released by Intel, unless a giant Proton style opensource project happens, with tens or hundreds or thousands of people dedicates themselves to making this method work on whatever hardware.

...

I think at one point someone tried to do something like this, figuring out how to hackily implement DLSS on AMD GPUs, but this seems to require compiling your own dlls, and is based off of such a random person's implementation of DLSS, and is likely quite buggy and inefficient compared to an actual Nvidia GPU with official drivers.

https://github.com/PotatoOfDoom/DLSS/tree/981fff8e86274ab1519ecb4c01d0540566f8a70e

https://github.com/PotatoOfDoom/CyberFSR2

https://docs.google.com/spreadsheets/d/1XyIoSqo6JQxrpdS9l5l_nZUPvFo1kUaU_Uc2DzsFlQw/htmlview

Yeah, looks like a whole bunch of compatibility issues and complex operations for a 'i just want play game' end user to figure out.

...

Also hey! Your last bit there about the second patent I listed seems to describe how they're going to do the real time moderation between which frames are fully pipeline rendered and which ones are extrapolated: use the described GPU kernel operation to estimate pipeline frame rendering times along with a target FPS/refresh rate, do extrapolation whenever FPS won't hit target FPS.

... Which would mean that the practical upshot for an average end user is that if they're not using a GPU architecture designed with this method in mind, the method isn't going to work very well, which means this is not some kind of magic 'holy grail', universal software upgrade for all old hardware (I know you haven't said this, but others in this thread have speculated at this)...

And that means the average end user is still in a state of comparing cost vs performance/features of an increasingly architecture divergent selection of future GPUs/NPUs/SoCs/APUs.

And also the overhead of doing the calculation of predicting pipeline render times vs extrapolated frame render times is not being figured in with this paper, meaning that the article based on the paper is at least to some extent overstating this method's practical quickness to the general public.

...

I think the disconnect we are having here is that I am coming at this from a 'how does this actually impact your average gamer' standpoint, and you are coming at it from much more academic standpoint, inclusive of all the things that are technically correct and possible, whereas I am focusing on how that universe of technically possible things is likely to condense into a practical reality for the vast majority of non experts.

Maybe 'propietary' was not exactly the technically correct term to use.

What is a single word that means 'this method is a feature that is likely to only be officially, out of the box supported and used by specific Intel GPUs/NPUs etc until Nvidia and/or AMD decide to officially support it out of the box as well, and/or a comprehensive open source team dedicates themselves to maintaining easy to install drivers that add the same functionality to non officially supported hardware'?

Either way, I do enjoy this discussion, and acknowledge that you seem to be more knowledgeable in the technicalities than myself.

[–] tekato@lemmy.world 1 points 1 week ago

I mean, in an academic sense, if you possess the ability to implement the method, sure you can make your own code and do this yourself on whatever hardware you want, train your own models, etc.
But from a practical standpoint of an average computer hardware user, no, you I don't think you can just use this method on any hardware you want with ease, you'll be reliant on official drivers which just do not support / are not officially released for a whole ton of hardware.
Not many average users are going to have the time or skillset required to write their own inplementations, train and tweak the AI models for every different game at every different resolution for whichever GPUs / NPUs etc the way massive corporations do.
It'll be a ready to go feature of various GPUs and NPUs and SoCs and whatever, designed and manufactured by Intel, reliant on drivers released by Intel, unless a giant Proton style opensource project happens, with tens or hundreds or thousands of people dedicates themselves to making this method work on whateverhardware.

Yes, this was never intended for the average user, the average user doesn’t even understand what is being explained in the paper. This is for video game studios to include with their games, or driver and OS developers to implement this system wide. The user gets provided a working product as usual. How many users do you think go and play with the FSR code which is totally open source? Not many (I’m inclined to say zero).

I think at one point someone tried to do something like this, figuring out how to hackily implement DLSS on AMD GPUs, but this seems to require compiling your own dlls, and is based off of such a random person's implementation of DLSS, and is likely quite buggy and inefficient compared to an actual Nvidia GPU with official drivers.

I’m not aware of somebody trying DLSS on AMD, but I don’t think it will ever work. Anyways, this is precisely why this isn’t intended for the average user, because even the average developer doesn’t know how to work these things. There’s very few people who know what to do with the information that was provided, as is the case with most academic papers.

Which would mean that the practical upshot for an average end user is that if they're not using a GPU architecture designed with this method in mind, the method isn't going to work very well, which means this is not some kind of magic 'holy grail', universal software upgrade for all old hardware (I know you haven't said this, but others in this thread have speculated at this

Yes, new technologies are never guaranteed to work with old hardware. That’s just how things are unfortunately.

And also the overhead of doing the calculation of predicting pipeline render times vs extrapolated frame render times is not being figured in with this paper, meaning that the article based on the paper is at least to some extent overstating this method's practical quickness to the general public.

The real-time arbitration is not the focus of this paper so that’s expected. Here they describe the framework, and the patent is just a particular use case for it.

I think the disconnect we are having here is that I am coming at this from a 'how does this actually impact your average gamer' standpoint, and you are coming at it from much more academic standpoint, inclusive of all the things that are technically correct and possible, whereas I am focusing on how that universe of technically possible things is likely to condense into a practical reality for the vast majority of non experts.

I guess that makes sense.

What is a single word that means 'this method is a feature that is likely to only be officially, out of the box supported and used by specific Intel GPUs/NPUs etc until Nvidia and/or AMD decide to officially support it out of the box as well, and/or a comprehensive open source team dedicates themselves to maintaining easy to install drivers that add the same functionality to non officially supported hardware'?

Unfortunately that’s the case with any advanced technology, no matter how open it is. We depend on companies who are willing to pay somebody to figure it out.