The X1X should run it at at least 1440p @60fps. Bungie is full of crap and there's nothing they can say for anyone to take them seriously. They should just be truthful about it and say it's 100% parity issues they locked it to 30 frames. There should be 2 options for X1X users: 1440p 60fps or 4k 30fps. After leaving MS they've been a massive joke in the gaming industry which looks like they're continuing it through their second game.
If my GTX 970 can run Destiny 2 1080p @60fps then the X1X should be able to as well.
@madrocketeer said:
Actually, the X1X's GPU is a souped-up Radeon RX 580, with more shaders, more TMUs and slighter higher clock. It is therefore about parity with or slightly better than the GTX 970.
The issue definitely seems to be the CPU. They're tiny and slow clocked. From what I can gather, the PS4's SOC consist of two quad-core Jaguars, each one about 3.1 mm2. A Haswell i5 is 177 mm2 (though this admittedly includes the integrated GPU), and clocked at at least 2.7 GHz. Even the X1X's Jaguar is clocked only at 2.3 GHz.
FALSE,
The following diagram is Polaris 10 for RX-480 which is the same for RX-580
Notice RX-480/RX-580 lacking updates to both Rasterizer and Render Backend(RBE). X1X's graphics pipeline was updated e.g. Rasterizer has conservation occlusion and RBE has 2MB render cache updates. There's 60 graphics pipeline changes for X1X.
Most of Polaris updates are for compute shaders and associated L2 cache e.g. 2MB from 1MB.
From http://www.anandtech.com/show/11740/hot-chips-microsoft-xbox-one-x-scorpio-engine-live-blog-930am-pt-430pm-utc#post0821123606
12:36PM EDT - 8x 256KB render caches
12:37PM EDT - 2MB L2 cache with bypass and index buffer access
12:38PM EDT - out of order rasterization, 1MB parameter cache, delta color compression, depth compression, compressed texture access
X1X's GPU's Render Back Ends (RBE) has 256KB cache each and there's 8 of them, hence 2 MB render cache.
X1X's GPU has 2 MB L2 cache, 1 MB parameter cache and 2MB render cache. That's 5 MB of cache.
https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf
The old GCN's render back end (RBE) cache. Page 13 of 18.
Once the pixels fragments in a tile have been shaded, they flow to the Render Back-Ends (RBEs). The RBEs apply depth, stencil and alpha tests to determine whether pixel fragments are visible in the final frame. The visible pixels fragments are then sampled for coverage and color to construct the final output pixels. The RBEs in GCN can access up to 8 color samples (i.e. 8x MSAA) from the 16KB color caches and 16 coverage samples (i.e. for up to 16x EQAA) from the 4KB depth caches per pixel. The color samples are blended using weights determined by the coverage samples to generate a final anti-aliased pixel color. The results are written out to the frame buffer, through the memory controllers
GCN version 1.0's RBE cache size is just 20 KB. 8x RBE = 160 KB render cache (for 7970)
AMD R9-290X/R9-390X's aging RBE/ROPS comparison. https://www.slideshare.net/DevCentralAMD/gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah
16 RBE with each RBE contains 4 ROPS. Each RBE has 24 bytes cache.
24 bytes x 16 = 384 bytes.
X1X's RBE/ROPS has 2048 KB or 2 MB render cache.
X1X's RBE has 256 KB. 8x RBE = 2048 KB (or 2 MB) render cache. X1X has hold more rendering data on the chip when compared to Radeon HD 7970 and R9-290X/R9-390X.
http://www.eurogamer.net/articles/digitalfoundry-2017-project-scorpio-tech-revealed
We quadrupled the GPU L2 cache size, again for targeting the 4K performance."
X1X GPU's 2MB L2 cache can be used for rendering in addition to X1X's 2 MB render cache.
When X1X's L2 cache (for TMU) and render cache (for ROPS) is combined, the total cache size is 4MB which is similar VEGA's shared 4MB L2 cache for RBE/ROPS and TMUs.
@ronvalencia said:
@madrocketeer said:
Actually, the X1X's GPU is a souped-up Radeon RX 580, with more shaders, more TMUs and slighter higher clock. It is therefore about parity with or slightly better than the GTX 970.
The issue definitely seems to be the CPU. They're tiny and slow clocked. From what I can gather, the PS4's SOC consist of two quad-core Jaguars, each one about 3.1 mm2. A Haswell i5 is 177 mm2 (though this admittedly includes the integrated GPU), and clocked at at least 2.7 GHz. Even the X1X's Jaguar is clocked only at 2.3 GHz.
FALSE,
The following diagram is Polaris 10 for RX-480 which is the same for RX-580
Notice RX-480/RX-580 lacking updates to both Rasterizer and Render Backend(RBE). X1X's graphics pipeline was updated e.g. Rasterizer has conservation occlusion and RBE has 2MB render cache updates. There's 60 graphics pipeline changes for X1X.
Most of Polaris updates are for compute shaders and associated L2 cache e.g. 2MB from 1MB.
From http://www.anandtech.com/show/11740/hot-chips-microsoft-xbox-one-x-scorpio-engine-live-blog-930am-pt-430pm-utc#post0821123606
12:36PM EDT - 8x 256KB render caches
12:37PM EDT - 2MB L2 cache with bypass and index buffer access
12:38PM EDT - out of order rasterization, 1MB parameter cache, delta color compression, depth compression, compressed texture access
X1X's GPU's Render Back Ends (RBE) has 256KB cache each and there's 8 of them, hence 2 MB render cache.
X1X's GPU has 2 MB L2 cache, 1 MB parameter cache and 2MB render cache. That's 5 MB of cache.
https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf
The old GCN's render back end (RBE) cache. Page 13 of 18.
Once the pixels fragments in a tile have been shaded, they flow to the Render Back-Ends (RBEs). The RBEs apply depth, stencil and alpha tests to determine whether pixel fragments are visible in the final frame. The visible pixels fragments are then sampled for coverage and color to construct the final output pixels. The RBEs in GCN can access up to 8 color samples (i.e. 8x MSAA) from the 16KB color caches and 16 coverage samples (i.e. for up to 16x EQAA) from the 4KB depth caches per pixel. The color samples are blended using weights determined by the coverage samples to generate a final anti-aliased pixel color. The results are written out to the frame buffer, through the memory controllers
GCN version 1.0's RBE cache size is just 20 KB. 8x RBE = 160 KB render cache (for 7970)
AMD R9-290X/R9-390X's aging RBE/ROPS comparison. https://www.slideshare.net/DevCentralAMD/gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah
16 RBE with each RBE contains 4 ROPS. Each RBE has 24 bytes cache.
24 bytes x 16 = 384 bytes.
X1X's RBE/ROPS has 2048 KB or 2 MB render cache.
X1X's RBE has 256 KB. 8x RBE = 2048 KB (or 2 MB) render cache. X1X has hold more rendering data on the chip when compared to Radeon HD 7970 and R9-290X/R9-390X.
http://www.eurogamer.net/articles/digitalfoundry-2017-project-scorpio-tech-revealed
We quadrupled the GPU L2 cache size, again for targeting the 4K performance."
X1X GPU's 2MB L2 cache can be used for rendering in addition to X1X's 2 MB render cache.
When X1X's L2 cache (for TMU) and render cache (for ROPS) is combined, the total cache size is 4MB which is similar VEGA's shared 4MB L2 cache for RBE/ROPS and TMUs.
This actually made sense as a reply, congrats.
@madrocketeer said:
@endofaugust said:
@ronvalencia said:
(Usual graphs and diagrams overload)
This actually made sense as a reply, congrats.
Yeah, but does he really have to do it in the form of 4-browser-page graphs and diagrams ocular assault? I mean, I did read all of that, and I was able to sum it up as; "You're wrong. The X1X's GPU has updated graphics pipeline, the rasterizer has conservation occlusion and the render backends have 2 MB of cache, compared to GCN 1.0's 160 KB, among other improvements. Combine that with the GPU's 2 MB L2 cache, and the X1X has 4 MB of total cache, which is more similar to the Vega." Simple as that. Throw in a few links as sources and - Bam! - point made.
If he had posted that instead, I would have just said well shave my backside and call me "Served," because I stand corrected. Still, my point remains: these consoles are ridiculously GPU-heavy, and that's where their limitations lie. I was even sort of praising the X1X's GPU in my original post.
But no, I had to sift through all of that mess to see what he was saying. He even repeated a few of his points for... ...some reason? This is why I typically don't bother to reply to ronvalencia's posts any more. Too tired of reading them.
X1X was mostly designed for Digital Foundry's XBO resolution gate, hence GPU heavy. X1X's CPU quad core layout follows Ryzen CCX layout instead of flat layout.
X1X's CPU has some improvements over stock Jaguar.
https://en.wikipedia.org/wiki/Translation_lookaside_buffer
A Translation lookaside buffer (TLB) is a memory cache that is used to reduce the time taken to access a user memory location
The TLB is sometimes implemented as content-addressable memory (CAM). The CAM search key is the virtual address and the search result is a physical address. If the requested address is present in the TLB, the CAM search yields a match quickly and the retrieved physical address can be used to access memory. This is called a TLB hit. If the requested address is not in the TLB, it is a miss, and the translation proceeds by looking up the page table in a process called a page walk. The page walk is time consuming when compared to the processor speed, as it involves reading the contents of multiple memory locations and using them to compute the physical address. After the physical address is determined by the page walk, the virtual address to physical address mapping is entered into the TLB
Performance implications
The CPU has to access main memory for an instruction cache miss, data cache miss, or TLB miss. The third case (the simplest one) is where the desired information itself actually is in a cache, but the information for virtual-to-physical translation is not in a TLB. These are all slow, due to the need to access a slower level of the memory hierarchy, so a well-functioning TLB is important. Indeed, a TLB miss can be more expensive than an instruction or data cache miss, due to the need for not just a load from main memory, but a page walk, requiring several memory accesses.
Log in to comment