1 thread per CU would mean a very low gpu utilization (like 1/32 or 1/64). thats not usable.
What I donât understand in the dynamic resolution performance RT mode is how does the engine decides on whether to output higher resolution or higher frame rates
With uncapped frame rates, resolution should be fixed
Yeah, but I mean they donât need to match a SPU thread to a whole CU, one CU would probably be enough for all SPEs at once and then some.
But even then they are probably better off issuing the SPE instructions as gpu compute jobs so the gpu scheduler fills it in other workloads.
1 Like
I think Iâve read that it isnât as simple as flicking a switch to unlock the framerate for some games, since other aspects would be tied to it. Maybe it was someone explaining why FPS boost isnât applicable to every game, since it might break that stuff if the frame rate goes too high? I clearly donât know enough about this 
Yes, with some games the physics, animations, and other systems are tied to the framerate and the game would break if the framerate changed from the default.
But a lot of games try to separate the two because sometimes you need physics faster than 30 hertz or 60 hertz. Games that run at multiple frame rates like 30/60 FPS depending on the options would have that separation. So with those games itâs not a problem.
2 Likes
Thanks for your expert opinion! Glad to see I wasnât totally off-base 
As far as you know, does the former have any advantages the latter wouldnât? That is to say, is there a balancing act of sorts that would keep some developers from going with the option that allows for framerate uncapping/multiplication?
I donât believe this will work.
A GPU scheduler which has to schedule 6 threads is severly underutilized. As is the whole GPU. I donât believe this will work. Iirc some RPC3S devs argued similar against this idea.
Thatâs a question for an actual expert! 
I can think of a couple reasons:
- for older consoles it may be inefficient on the hardware architecture to have an asynchronous setup between all systems, especially visuals with the rest. The overhead in running a system is also a consideration.
- If youâre working on a game on older consoles where fluctuating sub 30 FPS frame rates are a reality, having every system tied to the graphics may be less jarring for the player. So for example if your game runs from 20 to 30 FPS and it averages around 22 to 25 FPS. In that case you want the game physics and animations to slow down when the game slows down to 15 to 20 FPS. As a player, when the game slows down to a slideshow you donât want the game to take all of your inputs at 30 Hertz because your player ends up somewhere other than you intended. Game will feel like it has âslowdownâ but gameplay wise thatâs preferable to have your player do unpredictable things while the visuals are at a lower framerate.
Nowadays with hardware even as old as a 360, itâs better practice to have everything run asynchronously, not just for flexibilityâs sake for faster framerates in the future but also for game feel. The modern Gran Turismo series polls player inputs 1000 times a second. Many games like pinball titles calculate physics hundreds of times per second so objects wonât phase through each other.
2 Likes
Wow, thanks so much for your detailed but approachable answer (or educated guess)! This is very interesting, and I appreciate that you broke it down so someone whoâs only passingly familiar with the concepts could grasp it. 
The scheduler wouldnât just have the threads from the 6 gpus jobs, Iâm talking about issuing them in the async compute queue along with graphics and what not which would keep the gpu occupied (well, not quite because itâs still Ps3 level graphics)
And it definitely do work because thatâs what Ms is doing for BC on xbox. All VMX128 are issued to the gpu instead of the cpu (and while on 360 there was no need to use them to assist the gpu as much as there was on Ps3, many devs did, specially skinning meshes with physics)
Where did you read this?
XSX, PC. But thatâs not mentioned in the thumb title.
The Unity engine does not support RayTracing for Xbox Series consoles, yet.
Why exactly is that? Is Xbox development for RT support it stalled? or are they just planning on adding it later?
Unity is slow is all
How much slower are we talking about though? Because what if others skip on their engine for not having the same feature set as say UE5 in the same or relatively short timeframe?
idk. Itâs probably not that far behind but Unityâs HDRP has been a mess for years.
Sorry to hear, the unity demos are really good looking, so I was always thinking it would be the one engine used as much as UE5.
They have been placing their focus in other areas. Namely their multithreaded data-centric processing instead of visual splendor like RayTracing. I think itâs now called DOTS. Where as UE5 is still very single-thread bound, hence the recent DF articles and videos about being very CPU-limited. So each engine prioritized different areas to focus on and improve.
1 Like
I mean it is still extremely popular for newcomers indies and mobile devs. Unity only started trying to become more premiere with graphical fidelity starting in like.. idk 2017? 2018? But their initiatives have been finnicky and kind of a mess, in part due to them not actually creating a game like Epic does with their own software. They just announced that one platformer game as an example project though so itâs a start.
1 Like