Unreal Engine 5, [UE5 Developer Availability 2022-04-05]

[eastmen]

Those 200$ Samsung phones are the equivalent of using a Switch as a primary home console.

Looking at a 3090 it already struggles trying to add multiple ray traced effects to last gen visuals. Usually requiring 1080p-1440p to attain 60 fps. If we assume the next 3 shrinks before we cap out at 1 nm each allow the typical 50% performance improvement we end up with a GPU nearly 3.5x as fast as the 3090. I don't think that speedup is nearly enough to get us away from relying primarily on rasterization. What if these new GPUs keep increasing their power draw as Ampere did? Where do consoles slot in on the performance scale? What if prices continue to rise every generation and the GPU performance at a mass market price point continues to decrease? All of these are legitimate issues.

Yes but the point is there is a market from the low end to the ultra high end. It doesn't exist in the console world. So lets say your right. Lets say we get to the last micron shrink and we are stuck. Why can't there be that $200 cheap console and then that $1,000 ultra high end console the size of a mini fridge ?

When we hit a wall things will expand in size again because we will still need performance. In my office for example everyone has a surface book 3 that they bring to and from work. in the future if we can't shrink it , then cpu sizes will get larger and then devices will get larger. I can see us going back to having a desktop that can deal with the power and cooling requirements needed for larger hotter chips.

As for your thoughts on raytracing and if we will get good enough performance... well there is always smarter ways to do something. We don't know if the technology currently being used for raytracing is the optimal way of doing it. So you can see much bigger gains in the future over just adding more ray tracing units.

 

[techuse]

Yes but the point is there is a market from the low end to the ultra high end. It doesn't exist in the console world. So lets say your right. Lets say we get to the last micron shrink and we are stuck. Why can't there be that $200 cheap console and then that $1,000 ultra high end console the size of a mini fridge ?

When we hit a wall things will expand in size again because we will still need performance. In my office for example everyone has a surface book 3 that they bring to and from work. in the future if we can't shrink it , then cpu sizes will get larger and then devices will get larger. I can see us going back to having a desktop that can deal with the power and cooling requirements needed for larger hotter chips.

As for your thoughts on raytracing and if we will get good enough performance... well there is always smarter ways to do something. We don't know if the technology currently being used for raytracing is the optimal way of doing it. So you can see much bigger gains in the future over just adding more ray tracing units.

Because that high end market will never be profitable enough for developers to focus on it. Large devices consuming exorbitant levels of power while exhausting massive amounts of heat will never appeal to the mass market like current consoles do.

 

[eastmen]

Because that high end market will never be profitable enough for developers to focus on it. Large devices consuming exorbitant levels of power while exhausting massive amounts of heat will never appeal to the mass market like current consoles do.

Moores law never broke down before , it may have slowed but never stopped. If we get to a point where hardware doesn't get faster every 18-24 months due to a new shrink then of course large devices will get popular again since it will be the only way to get more performance.

Some one watching porn might not need it but anyone doing any type of work on their device will want to maximize performance. If your job is video editing then your going to want to get render times down as thats more money out of your pocket. So your going to spend to get the best performance you can get.

 

[Shifty Geezer]

...but anyone doing any type of work on their device will want to maximize performance. If your job is video editing then your going to want to get render times down as thats more money out of your pocket. So your going to spend to get the best performance you can get.

Because that high end market will never be profitable enough for developers to focus on it. Large devices consuming exorbitant levels of power while exhausting massive amounts of heat will never appeal to the mass market like current consoles do.

Counter point needs to be that, yes, mainstream gamers will move to large $1000 devices as the only way to get their gaming fix.

 

[Andrew Lauritzen]

I'm not certain if some of these features you mentioned in your presentation are ever going to materialize among any of the shading languages ...

So I won't speak to these specific points because it gets too close to NDA type lines. Suffice it to say over the past decade at Intel, EA and now Epic I have been highly involved in discussions with all of these parties.

That being said, have you thought about contingency plans yet if you don't see some of these features ever being exposed in any shading languages ?

If you'll permit me a minor soapbox, the "it's too hard, all we can do is the status quo" has been the excuse for over a decade now. We as an industry absolutely could have done more in that time, but industry forces always end up prioritizing what wins existing benchmarks or what can go in a shiny marketing deck, control panel override or similar with pretty pictures.

The reality is whenever UE5 ships it is going to force the issue. Nanite uses a persistent threads style kernel as part of its culling that is - how shall we say - at the edge of what is spec-defined to work. I don't think anyone likes the situation and no one really wants to commit to it for future compatibility but it's not really a choice anymore. No one can claim they weren't warned that we needed better solutions, so at this point I've lost all my sympathy for the IHVs who now might have to consider various workarounds to keep it working in the future. That, alas, is the failure of the market-driven model of GPU/API development. It is by its very nature too reactive and even in cases where we have plenty of warning about things that are going to be necessary it's too easy for people to keep saying "well that isn't really possible - it would involve actual work and hardware!" until a forcing function arrives. Nanite - and to some extent raytracing if we ever want hit shaders to actually run efficiently - are likely to be that in the near term. /soapbox

 

[Shifty Geezer]

In short, you're saying we need devs to create mindblowing software with new paradigms that break current GPUs and their paradigms and forces IHVs to come up with different hardware to run them. We need a new Crysis!

 

[trinibwoy]

The reality is whenever UE5 ships it is going to force the issue. Nanite uses a persistent threads style kernel as part of its culling that is - how shall we say - at the edge of what is spec-defined to work. I don't think anyone likes the situation and no one really wants to commit to it for future compatibility but it's not really a choice anymore. No one can claim they weren't warned that we needed better solutions, so at this point I've lost all my sympathy for the IHVs who now might have to consider various workarounds to keep it working in the future.

Are you referring to this snippet from the Nanite paper?

“Unfortunately, blocking algorithms like this rely on scheduling behavior that is not defined by D3D or HLSL. The crucial property that needs to be guaranteed is that once a thread group has started executing, and thus could have taken a lock, it should continue to be scheduled and not be starved indefinitely.”

The harder problem seems to be the random memory access required for truly flexible code. In your Siggraph talk you mentioned limitations of current apis due to static register and LDS allocation and the implications for occupancy and performance.

Dynamic state allocation is what CPUs do right? And that means big caches and lots of flushing and loading of registers. It’s a win for developer productivity but is it a win for overall performance?

 

[Lurkmass]

If you'll permit me a minor soapbox, the "it's too hard, all we can do is the status quo" has been the excuse for over a decade now. We as an industry absolutely could have done more in that time, but industry forces always end up prioritizing what wins existing benchmarks or what can go in a shiny marketing deck, control panel override or similar with pretty pictures.

The industry also likes to minimize redundant implementations or features too ...

The reality is whenever UE5 ships it is going to force the issue. Nanite uses a persistent threads style kernel as part of its culling that is - how shall we say - at the edge of what is spec-defined to work. I don't think anyone likes the situation and no one really wants to commit to it for future compatibility but it's not really a choice anymore. No one can claim they weren't warned that we needed better solutions, so at this point I've lost all my sympathy for the IHVs who now might have to consider various workarounds to keep it working in the future. That, alas, is the failure of the market-driven model of GPU/API development. It is by its very nature too reactive and even in cases where we have plenty of warning about things that are going to be necessary it's too easy for people to keep saying "well that isn't really possible - it would involve actual work and hardware!" until a forcing function arrives. Nanite - and to some extent raytracing if we ever want hit shaders to actually run efficiently - are likely to be that in the near term. /soapbox

I think you might be underestimating exactly how much inertia is needed for the industry to arrive at a consensus. The industry has just started thinking that buffer pointers and texture handles were good ideas. Mobile GPU vendors don't even agree that implementing 64-bit atomic operations on textures is a good idea but I don't imagine that your team really cares about making Nanite compatible for them. In 5 years, I don't envision any major advances to shading languages and that goes in common for desktop vendors as well.

As far as forcing a solution, are you expecting hardware vendors to quickly react ? How do you propose that to happen ? Are you planning on adding vendor specific code to show performance advantages to convince other vendors to follow the same path ? Are you expecting a vendor to clearly come out on top by a significant margin even without special code paths ? If the answer to the last two questions turns out to be negative then you haven't really made a case as to why the industry should standardize these features ...

Are you referring to this snippet from the Nanite paper?

“Unfortunately, blocking algorithms like this rely on scheduling behavior that is not defined by D3D or HLSL. The crucial property that needs to be guaranteed is that once a thread group has started executing, and thus could have taken a lock, it should continue to be scheduled and not be starved indefinitely.”

It sounds like independent thread scheduling could be helpful since it enables starvation-free algorithms on GPUs ...

 

[Andrew Lauritzen]

I think you might be underestimating exactly how much inertia is needed for the industry to arrive at a consensus.

Oh trust me I don't underestimate it. I'm absolutely aware of how the forces of press and marketing interact to stall progress As I noted, my name is on a lot of these specs and I've probably been involved with the majority of discussions of this stuff from at least two angles (IHV, ISV). Hell I've even been the person telling ISVs why something is a bad direction because it is expensive to implement in hardware and wouldn't it be much nicer if they could just express everything as pure streaming operations? But "it's hard" isn't ultimately an excuse to do things in a stupid way. We're nearing the limit of what brute force will give us and increasingly transistors put into allowing more cleverness rather than making GFXBench run 15% faster and calling it a day are going to pay off much more in the future.

The industry has just started thinking that buffer pointers and texture handles were good ideas. Mobile GPU vendors don't even agree that implementing 64-bit atomic operations on textures is a good idea but I don't imagine that your team really cares about making Nanite compatible for them.

... and 5 years ago when those conversations were happening it was an interesting discussion. Not to put too fine a point on it now, but I think the burden of proof of being able to do something similar or better than Nanite without 64-bit atomics is now very clearly in the ballpark of those saying they don't need to do it.

Anyways we don't need to retread this discussion here, I was just trying to give some context for the other folks. Suffice it to say trust me, I'm well aware of how the industry, IHV and standards bodies work here. And while depressing in some ways, Nanite being a thing has all of a sudden bumped up the priority of some of these discussions again.

 

[Lurkmass]

Oh trust me I don't underestimate it. I'm absolutely aware of how the forces of press and marketing interact to stall progress As I noted, my name is on a lot of these specs and I've probably been involved with the majority of discussions of this stuff from at least two angles (IHV, ISV). Hell I've even been the person telling ISVs why something is a bad direction because it is expensive to implement in hardware and wouldn't it be much nicer if they could just express everything as pure streaming operations? But "it's hard" isn't ultimately an excuse to do things in a stupid way. We're nearing the limit of what brute force will give us and increasingly transistors put into allowing more cleverness rather than making GFXBench run 15% faster and calling it a day are going to pay off much more in the future.

I wouldn't necessarily describe the reactive development of programming models to be stupid because improvements to shading languages are always secondary to improving performance in benchmarks for IHVs. ISVs have to present a compelling argument as to why introducing feature xyz will give superior end results for IHVs in benchmarks. I think the reason why the industry takes a conservative approach to advances in graphics is because IHVs believe that ISVs don't know any better hence the siloing from each other.

... and 5 years ago when those conversations were happening it was an interesting discussion. Not to put too fine a point on it now, but I think the burden of proof of being able to do something similar or better than Nanite without 64-bit atomics is now very clearly in the ballpark of those saying they don't need to do it.

Anyways we don't need to retread this discussion here, I was just trying to give some context for the other folks. Suffice it to say trust me, I'm well aware of how the industry, IHV and standards bodies work here. And while depressing in some ways, Nanite being a thing has all of a sudden bumped up the priority of some of these discussions again.

64-bit atomics was arguably a low hanging fruit if we don't consider mobile vendors at all since AMD and Nvidia supported this feature years ago with Intel being the only real holdout left. I think everyone is curious to observe what will happen in the immediate future after the release of UE5 and when we start doing performance comparisons between different vendors but it's still too early to be optimistic about these contentious features before we have results. If performance does end up being competitive in Nanite, I am anticipating that other hardware vendors will naturally stick to their own schedules rather changing it which can mean that these discussions could be stalled again.

 

[PSman1700]

In short, you're saying we need devs to create mindblowing software with new paradigms that break current GPUs and their paradigms and forces IHVs to come up with different hardware to run them.

Thats a problem since the current generation consoles just have been released, their going to be around for another 6 or 7 years to come, atleast.

 

[Johnny Awesome]

That depends how mindblowing the software is.

 

[trinibwoy]

That depends how mindblowing the software is.

3dmark could fill this role of showing us what the future holds even if it’s running at unplayable frame rates on current hardware. But instead of pushing the envelope we get ugly and uninspired benchmarks that do nothing to drive progress or change the game.

 

[Remij]

3dmark could fill this role of showing us what the future holds even if it’s running at unplayable frame rates on current hardware. But instead of pushing the envelope we get ugly and uninspired benchmarks that do nothing to drive progress or change the game.

I miss the days when Nvidia and AMD themselves would release tech demos pushing the state of the art and allowing users to run and test them.

Like cmon Nvidia/AMD... give us some shiny new tech demos to show off!

 

[davis.anthony]

I miss the days when Nvidia and AMD themselves would release tech demos pushing the state of the art and allowing users to run and test them.

Like cmon Nvidia/AMD... give us some shiny new tech demos to show off!

You and me both, I remember seeing the Toy Shop demo for ATI and it was mind blowing.

 

[cwjs]

Didnt nvidia release marbles?

 

[PSman1700]

You and me both, I remember seeing the Toy Shop demo for ATI and it was mind blowing.

It sure was. NV/AMD (and even others like matrox etc) had their tech demos that blew minds. Today those things arent a thing anymore somehow. Even console manufacturers had their tech demos, PS2 had find my own way for example and many more.

 

[snc]

3dmark could fill this role of showing us what the future holds even if it’s running at unplayable frame rates on current hardware. But instead of pushing the envelope we get ugly and uninspired benchmarks that do nothing to drive progress or change the game.

one of the reason is that years ago it was so much easier to show jaw dropping tech demo that could utilize hardware power, now you need plenty of people working long time to deliver quality and its maybe just too expensive, and benchmark can be ugly and still good in measuring performance

 

[trinibwoy]

one of the reason is that years ago it was so much easier to show jaw dropping tech demo that could utilize hardware power, now you need plenty of people working long time to deliver quality and its maybe just too expensive for just, and benchmark can be ugly and still good in measuring performance

Yes it comes down to economics which is understandable. UE5 has some promising tech that probably can and will bring current hardware to its knees. Hopefully we get more demos soon either from Epic or enterprising independent developers.

 

[snc]

Hopefully we get more demos soon either from Epic or enterprising independent developers.

I hope we get soon some games :d