Support NeoGAF

[VFXVeteran]

still pixar didn't use ray tracing till cars on the reflections only, and full ray tracing it wasn't until monster university.

We already have some form of ray traced reflections in real time and even full ray tracing to some degree on some games.

Keep in mind that ray tracing h/w is likely significantly faster than software ray tracing. And the h/w is getting faster at what seems like an exponential rate, if the 4x performance increase is to be believed.

Man, reflections are so easy to do when the reflection vector is coincident with the eye vector. That's really easy and doesn't even need multiple ray-casts. Mirror reflections are unrealistic on anything other than a mirror. Even cars have some roughness on the clearcoat and definitely underneath. I'm sorry I just can't argue about this with you unless you have shown to code these 3d features up yourself. I think you wouldn't be arguing with me if you did because it would be very apparent what GPUs are lacking.

 

[Psykodad]

I get what you are saying there, I'm just not sure why the XSX would be half that RAM pool.

Because if the tech-demo is based on the speed of the SSD of PS5, XSX is slower.

I never said XSX would be using half the RAM pool, technically XSX would need double the RAM, if PS5 is twice as fast.
What I was saying, is that based on the SSD speeds, XSX would only be capable of moving 384MB/s in the same time frame as 768MB/s on PS5.
And if I understood correctly, that's incl compression on PS5. So in order for XSX to match PS5s speed of 768MB/s, they would need to reduce file sizes, correct? Meaning something has to scale down, unless they opt for a RAM-pool of ~1.5Gb to get the same results as PS5.

I don't know where the GPUs come into play and I understand that XSX GPU is more capable obviously, but it's hard to render data that isn't available (yet).

Edit:

Just realized it might not work like that, in that increasing the RAM-pool on XSX won't solve it.
It'll probably be slower, right?
So if that RAM-pool is 768MB/s on PS5, it could still be 768MB on XSX. But since XSX can only fill 384MB/s (exact same data as on PS5) of that RAM/pool, it would take 2sec on XSX to move that data instead, meaning it'll just lag behind.

I don't think we can say for sure if the SSD will play a role or not between resolutions (for Nanite). Texture-wise it would be the same (so no medium vs high; the quality will depend solely on what they ship & resolution, unlike how it is done today), what would change between 1440p and 4K is how the geometric detail gets resolved thanks to more pixels but as far as I know that's more GPU compute dependent rather than having to do with the SSD (and will further be improved in performance by adopting mesh shaders, which they haven't done yet for Nanite). Technically you're feeding the same assets so the hit on the SSD should be the same between 1440p and 4K.

The question is how does Nanite scale with all these aspects of graphics processing, and that's something we don't know (and can't therefore totally answer your question). We still need more details tbh, and hopefully with a direct feed from a PC, then all will be revealed.

Don't get me wrong, I didn't mean the SSDs will play a role in resolutions. Afaik that wouldn't even make any sense, since SSDs are purely for data storage and transfer.

I already know XSX is capable of running games at higher resolution and/or fps.
So resolution can be taken out of the equation for what I'm asking.

That's why I'm curious to see actual comparisons, although the technical discussions are interesting.
As far as I can follow them, that is. Lol

 

[Omega Supreme Holopsicon]

Man, reflections are so easy to do when the reflection vector is coincident with the eye vector. That's really easy and doesn't even need multiple ray-casts. Mirror reflections are unrealistic on anything other than a mirror. Even cars have some roughness on the clearcoat and definitely underneath. I'm sorry I just can't argue about this with you unless you have shown to code these 3d features up yourself. I think you wouldn't be arguing with me if you did because it would be very apparent what GPUs are lacking.

Are you saying 15 years from now if Nvidia keep up 4x per generation improvement we still will have lackluster Ray Tracing?

I expect Nvidia to be able to put a live human on one side, and a realtime human beside, and most anyone not being able to tell by then.

A feat even some of the latest hollywood films like rogue one failed to accomplish.

 

[Three]

No. Because no one knows how it works. Until there is source code where people can play with what it actually does, we are all throwing darts.

Why when Epic have themselves said it wouldn't be possible on 5 year old drives and provided a demo?
The 786MB is for the current view. The information as to what a streaming pool is is out there. The current view needs to get updated (streamed) as the player moves. 786mB is a meaningless number here as to what storage speed you need.

I get what you are saying there, I'm just not sure why the XSX would be half that RAM pool.

It would actually be double the ram pool used because it's slower. It's about swapping data fast. Somebody said this in the thread already I believe. If you can't do it fast enough for a given framerate you need more because you can't swap fast enough to keep up and need to keep things there that are NOT in the view. The aim is to reduce the streaming pool for better memory utilisation and framerate not increase it because you want everything in that pool to not be redundant data. You want everything there used to render the current view and nothing else.

What's more the scaling would be worse on the slower SSD. With higher res you sample more from the textures. The more data you need to stream, virtualised textures remember. If you go by Nanites "a triangle per pixel" approach to virtualised geometry the more data you need to stream for your objects too.

I can totally understand if you limit the player speed or framerate why you might not need a very fast drive. You are GPU bottlenecked at that res but your storage speed requirements are also increasing for that given framerate. The res is dynamic anyway and Epic specifically mention that the GPU can can handle 60.

 

[polybius80]

I expect higher quality assets/textures due to PS5's speed, as XSX has half the speed.
That's also the same reason that answers your second question.

If PS5 can load 768MB/s of data in the RAM pool, I assume XSX would only be able to load 384MB/s, correct?
So either they have to use lower quality assets to reduce the file-sizes and keep up with Ps5's speed, or like others have said, increase the RAM-pool, at which point they would have to make sacrifices elsewhere as they'd be using more RAM (or a mix of added RAM + smaller file-sizes).

But maybe I'm making some error in my line of thinking, so feel free to correct me.

the source sates they require 768 MB space is a quantity not a speed and they will reduce this further so expect the same demo more optimized with a smaller pool by the time UE5 releases, in XSX there is no need to make sacrifices other than have to prefetch more data in RAM, double the pool and thats it, not big deal but people like to exaggerate things

 

[Psykodad]

the source sates they require 768 MB space is a quantity not a speed and they will reduce this further so expect the same demo more optimized with a smaller pool by the time UE5 releases, in XSX there is no need to make sacrifices other than have to prefetch more data in RAM, double the pool and thats it, not big deal but people like to exaggerate things

I've seen people mention the 768MB translated to 768MB/s.
So I went with that.

But yeah, I get that on XSX they could increase the RAM pool, but that does mean that there would be less RAM available for other tasks.
So trade-offs would have to be made nonetheless. And this would mean that there are definitely benefits to the PS5 hardware compared to XSX.

Purely hypothetical ofcourse, as we won't ever know how much this would affect development of any 3rd party game an what results we see.

 

[pawel86ck]

Why when Epic have themselves said it wouldn't be possible on 5 year old drives and provided a demo?
The 786MB is for the current view. The information as to what a streaming pool is is out there. The current view needs to get updated (streamed) as the player moves. 786mB is a meaningless number here as to what storage speed you need.

It would actually be double the ram pool used because it's slower. It's about swapping data fast. Somebody said this in the thread already I believe. If you can't do it fast enough for a given framerate you need more because you can't swap fast enough to keep up and need to keep things there that are NOT in the view. The aim is to reduce the streaming pool for better memory utilisation and framerate not increase it because you want everything in that pool to not be redundant data. You want everything there used to render the current view and nothing else.

What's more the scaling would be worse on the slower SSD. With higher res you sample more from the textures. The more data you need to stream, virtualised textures remember. If you go by Nanites "a triangle per pixel" approach to virtualised geometry the more data you need to stream for your objects too.

I can totally understand if you limit the player speed or framerate why you might not need a very fast drive. You are GPU bottlenecked at that res but your storage speed requirements are also increasing for that given framerate. The res is dynamic anyway and Epic specifically mention that the GPU can can handle 60.

XSX has very fast I/O as well, and thanks to the SFS (hardware implementation) they will need to load 2.5x less data than PS5 in order to achieve the same result. SFS also decrease VRAM requirements for the same texture.

Stanard has also said it's possible to implement SFS in software, buy performance impact was too big, so they had to build HW for it.

SFS will be ported to PC soon as well and I bet RDNA2 / Ampere GPUs on PC will support it on the hardware level.

 

[Three]

XSX has very fast I/O as well, and thanks to the SFS (hardware implementation) they will need to load 2.5x less data than PS5 in order to achieve the same result. SFS also decrease VRAM requirements for the same texture.

Stanard has also said it's possible to implement SFS in software, buy performance impact was too big, so they had to build HW for it.

SFS will be ported to PC soon as well and I bet RDNA2 / Ampere GPUs on PC will support it on the hardware level.

The bolded is completely incorrect. Guess where the 2.5x efficiency comes from?

 

[pawel86ck]

The bolded is completely incorrect. Guess where the 2.5x efficiency comes from?

I dont need to guess, because I have quoted MS engineer who answered this particular question in the first sentence. Only point of reference is unknown, but that's probably 2.5x gains over Xbox One X. Stanard even said thanks to SFS savings XSX 4.8GB/s feels like 12GB/s.

 

[Falc67]

The lighting is completely crude. Watch more CG movies. The filtering of the bump textures smoothes out at sharp angles. The simple conventional filter algorithm in GPUs is pretty old (i.e. box filter). GPUs don't even support Blackman-Harris or Catmil-ROM filtering which gives much better results.

Just because you can't tell the difference doesn't mean there isn't a difference (and one by a LARGE margin).

I also hate when demos use instances of the same geometry to try touting that it can render a shit ton of geometry when the geometry isn't even unique. It's only storing 1 asset in memory and transforming it in the world at different locations.

I found this comment from one of the artists that worked on the assets for the Demo, backs up what you said earlier.

 

[Three]

I dont need to guess, because I have quoted MS engineer who answered this particular question in the first sentence. Only point of reference is unknown, but that's probably 2.5x gains over Xbox One X. Stanard even said thanks to SFS savings XSX 4.8GB/s feels like 12GB/s.

Exactly and where do you think that partial texture comes from. The drive. Why use partially resident textures streamed from the drive to begin with? To reduce memory use. Why do you think the Xbox one x has to keep more resident in memory than the xbox series X? The drive speed. Engines didn't do the things they are doing now because they had slow drives. They couldn't stream as efficiently or fast enough based on the current view like they can now. The reference there is XSX vs X1X games.

 

[Garret Bobby Ferguson]

I understand what you wrote, you just don't like the answer, and that's not my problem.

Oh, and here come the genetic fallacies.

It sounds like you're the one who didn't like the answer lol

 

[lepermessiah]

Welcome to "I am authority", the thread.

 

[sonyfifa]

wow imagine doodle x 2.5 efficiency geometry in action.

 

[polybius80]

I dont need to guess, because I have quoted MS engineer who answered this particular question in the first sentence. Only point of reference is unknown, but that's probably 2.5x gains over Xbox One X. Stanard even said thanks to SFS savings XSX 4.8GB/s feels like 12GB/s.

feels like 12 GB/s?

the problem is compared with what?, against just plain having all textures and their mipmaps in RAM? against partially resident textures? against PRT and SF? the problem is you automatically assume that PS5 or developers in that console cannot use any form of streamed texture management or somehow PS5 a RDNA2 based hardware that have the hardware to report what mips are required and visible and that is what SF use wont provide information to sony api, this is AMD hardware after all, streaming textures and geometry is not a new problem, sony has streaming tech since PS2 to stream from a DVD and we had games with megatextures since back then, SFS is not going to give you 2.5x boost on top of what already can be used just because it can retrieve sub parts from required mip-maps specially as that depends heavily in the artwork so its not a constant in a game

wasnt PRT heavily advertised by MS this gen? was there any impact against PS4 games even in PRT dependent games? no? why? PRT allows to avoids whole mip maps not just part of them

 

[pawel86ck]

feels like 12 GB/s?

the problem is compared with what?, against just plain having all textures and their mipmaps in RAM? against partially resident textures? against PRT and SF? the problem is you automatically assume that PS5 or developers in that console cannot use any form of streamed texture management or somehow PS5 a RDNA2 based hardware that have the hardware to report what mips are required and visible and that is what SF use wont provide information to sony api, this is AMD hardware after all, streaming textures and geometry is not a new problem, sony has streaming tech since PS2 to stream from a DVD and we had games with megatextures since back then, SFS is not going to give you 2.5x boost on top of what already can be used just because it can retrieve sub parts from required mip-maps specially as that depends heavily in the artwork so its not a constant in a game

wasnt PRT heavily advertised by MS this gen? was there any impact against PS4 games even in PRT dependent games? no? why? PRT allows to avoids whole mip maps not just part of them

MS engineer has said they could implement SFS in software, but performance implications were too big, so they build HW for it. Theorethically developers can implement software SFS on PS5, but I dont expect they will do it because of performance impact, and especially when PS5 has really fast I/O anyway.

 

[Panajev2001a]

MS engineer has said they could implement SFS in software, but performance implications were too big, so they build HW for it. Theorethically developers can implement software SFS on PS5, but I dont expect they will do it because of performance impact, and especially when PS5 has really fast I/O anyway.

Again he never said it was compared to PRT, he actually says that PRT is what SFS is based on... again, nowhere it says that they get 2.5x improved efficiency over a PRT based virtual texturing implementation. Some people, in a rotation (it feels like this argument is passed around like the torch at the Olympics), keep bringing this up in the same exact way... ok, not exactly, we would need someone to say that after all you just cut loading times from 2 seconds to 1 second so who cares to cover that side of the fence too .

SF and SFS built on top of it provide an easier implementation path for developers and improve efficiency, but I think you are over estimating both the cost of the current approach by devs and the savings by SFS (which is not free either and MS advices not to make excessive use of it too). Conveniently Sony forgot to implement it because they went the raw speed first and ended up with a costly drive where with just a few smarter engineers they could have gone from 2.4 GB/s to 12 GB/s thus now getting 3-4 GB/s faster than Sony’s solution .

 

[polybius80]

MS engineer has said they could implement SFS in software, but performance implications were too big, so they build HW for it. Theorethically developers can implement software SFS on PS5, but I dont expect they will do it because of performance impact, and especially when PS5 has really fast I/O anyway.

I was talking about SF, SF has certain levels of hardware required to achieve its full functionality, SFS stores a lower mip-map part to use in case no bigger mip-map is available compared to SF so there is not a texture stall in such case and uses a custom filter format it doesnt improve 2.5x over the other tech it require to work properly

SFS uses hardware indicators to decide the mip map parts it require, is fair to assume those are available in modern GPUs in various tiers just like SF, except for a scpecific customization MS asked AMD to do as XBSX is RDNA2-based

 

[Three]

MS engineer has said they could implement SFS in software, but performance implications were too big, so they build HW for it. Theorethically developers can implement software SFS on PS5, but I dont expect they will do it because of performance impact, and especially when PS5 has really fast I/O anyway.

SFS is a single marketing term for a broad range of features but there has been PRT support in hardware for some time. Games didn't stream this much data based on the players view in the past due to drive speed limitations and hence they had a lot of textures not visible in the view frustum still in memory. Now this has changed this gen. There are things on top of PRT that are custom but they are not what is providing a 2.5x boost to memory usage or bandwidth efficiency. The MS engineer specifically states loading whole mips vs loading partial mips. If you think the PS5 would be loading whole mips in a thread where the UE5 demo is not only using virtual textures but also virtual geometry then you are gravely mistaken.

 

[Tschumi]

I would like to see this thread, and it's premise, reexamined in light of the Halo Infinite reveal.

 

[Psykodad]

I would like to see this thread, and it's premise, reexamined in light of the Halo Infinite reveal.

I think it's pretty clear.
Lower quality assets at higher res + higher framerate won't look better.

Case and point Ghost of Tushima vs Halo Infinite.

If UE5 allows PS5 to stream higher quality assets and texture, games will look better, despite possible lower resolution.
To keep up, XSX would need to increase the RAM-pool, potentially forcing devs to make sacrifices in other areas.
Or XSX would have to deal with pop-in and such.

The better GPU capabilities of XSX would be bottlenecked by the SSD-speed compared to PS5.

Halo is an extreme example, but a perfect showcase how Tflops don't tell the whole story, just like Cerny and many devs have stated.