Personal computing discussed

Moderators: renee, Hoser

 
cynan
Graphmaster Gerbil
Posts: 1160
Joined: Thu Feb 05, 2004 2:30 pm

Re: Playstation 4

Thu Feb 21, 2013 3:52 pm

Well, if Crysis 3 is any indication, may single core performance won't matter so much.

Crysis + new consoles = dawn of fully realized multithreaded game engines? It's about time. I just wonder where this will leave hyperthreading.
 
Suspenders
Gerbil
Posts: 29
Joined: Wed Jun 18, 2008 3:30 pm

Re: Playstation 4

Thu Feb 21, 2013 6:21 pm

We also have to remember that developers will be probably be able to squeeze a lot more performance out of those Jaguar cores that what we might otherwise guess through the optimization potential that fixed console hardware provides, so I don't really think the APU is too overbalanced towards the GPU.

Also, I'd guess that Sony expects devs to push the GPU compute potential quite a bit, so having that extra beefy gpu will be even more useful than for just pushing the graphics.

We'll see though ;) Fascinating SoC design in any case.
 
codedivine
Gerbil Elite
Posts: 714
Joined: Sat Jan 24, 2009 8:13 am

Re: Playstation 4

Thu Feb 21, 2013 7:25 pm

My understanding is that the latency on GDDR5 is horrible compared to, say, DDR3. Wonder how that is going to effect the CPU side. On the GPU side, this is tolerated by having lots of threads running at the same time. But Jaguar cores do not do multiple threads. Maybe there is a large cache or buffer of some sort?
 
ChronoReverse
Gerbil Elite
Posts: 757
Joined: Wed Dec 12, 2007 4:20 pm

Re: Playstation 4

Thu Feb 21, 2013 7:33 pm

It may be horrible but I'm thinking sheer amount, high bandwidth and direct sharing with the GPU would help.

How badly does GDDR5 fair against DDR3 anyway?
 
codedivine
Gerbil Elite
Posts: 714
Joined: Sat Jan 24, 2009 8:13 am

Re: Playstation 4

Thu Feb 21, 2013 7:41 pm

ChronoReverse wrote:
It may be horrible but I'm thinking sheer amount, high bandwidth and direct sharing with the GPU would help.

How badly does GDDR5 fair against DDR3 anyway?


On GPUs, code optimization documentation usually states latency to be about 300-500 processor cycles. Assuming a 1GHz GPU or 1ns cycle, you get about 300+ ns. On DDR3, my understanding it is of the order of 20ns.

edit: Not sure of those numbers though. May be completely wrong for all I know :P
 
auxy
Graphmaster Gerbil
Posts: 1300
Joined: Sat Jan 19, 2013 4:25 pm
Location: the armpit of Texas

Re: Playstation 4

Thu Feb 21, 2013 8:27 pm

kamikaziechameleon wrote:
AMD's standard for 8 core means its really a 4 core like what bulldozer is.
This CPU is not related in any way to the Bulldozer/Piledriver-style design. This is two quad-core Jaguar parts bolted together. Jaguar is the successor to the Bobcat low-power design used in the E-350/450/1200/1800 "Fusion" APUs. (^・o・^)ノ”
 
Suspenders
Gerbil
Posts: 29
Joined: Wed Jun 18, 2008 3:30 pm

Re: Playstation 4

Thu Feb 21, 2013 8:39 pm

Timothy Lottes, apparently a programmer involved with creating FXAA, had some speculation on the PS4 which covered a lot of ground wrt what programmers might be able to do with low level hardware access. Unfortunately he's pulled his original post, but this site http://www.gameranx.com/updates/id/1232 ... n-console/ has a good overview of what he originally said.

A choice quote:
"The real reason to get excited about a PS4 is what Sony as a company does with the OS and system libraries as a platform, and what this enables 1st party studios to do, when they make PS4-only games. If PS4 has a real-time OS, with a libGCM style low level access to the GPU, then the PS4 1st party games will be years ahead of the PC simply because it opens up what is possible on the GPU."
 
auxy
Graphmaster Gerbil
Posts: 1300
Joined: Sat Jan 19, 2013 4:25 pm
Location: the armpit of Texas

Re: Playstation 4

Thu Feb 21, 2013 8:46 pm

Timothy Lottes wrote:
If PS4 has a real-time OS ... then the PS4 1st party games will be years ahead of the PC simply because it opens up what is possible on the GPU.
Oh, come on! I said this exact same thing a couple of years ago in regard to real-time OSes on consoles, and people told me I was stupid. (ノಠ益ಠ)ノ"A real-time OS would be horrible for games!", I was told. How irritating. ( ̄へ ̄)
 
lilbuddhaman
Gerbil First Class
Posts: 140
Joined: Sat May 10, 2008 8:23 pm

Re: Playstation 4

Mon Feb 25, 2013 3:56 pm

If PS4 has a real-time OS, with a libGCM style low level access to the GPU, then the PS4 1st party games will be years ahead of the PC simply because it opens up what is possible on the GPU.


Anything that would be doable with the PS4 would be doable with the PC ... libgcm (from what I've read) is merely a low-level opengl implementation. As shown by Valve's work with linux/opengl ports of the Source engine, the benefits are reachable and there; they just need to be capitalized on. Also, low-level coding = harder...so don't expect most 3rd parties to jump on it.

I'm excited for PS4, not that I'm going to buy one, but for what it means for possible PC ports.
I am jaded. I am cynical.
 
codedivine
Gerbil Elite
Posts: 714
Joined: Sat Jan 24, 2009 8:13 am

Re: Playstation 4

Mon Feb 25, 2013 4:49 pm

lilbuddhaman wrote:
If PS4 has a real-time OS, with a libGCM style low level access to the GPU, then the PS4 1st party games will be years ahead of the PC simply because it opens up what is possible on the GPU.


Anything that would be doable with the PS4 would be doable with the PC ... libgcm (from what I've read) is merely a low-level opengl implementation. As shown by Valve's work with linux/opengl ports of the Source engine, the benefits are reachable and there; they just need to be capitalized on. Also, low-level coding = harder...so don't expect most 3rd parties to jump on it.

I'm excited for PS4, not that I'm going to buy one, but for what it means for possible PC ports.


As far as I know, most shipping games on PS3 did not use OpenGL but rather used libgcm. A few games did ship with OpenGL, but for the most part the OpenGL library was only there for you to start your port.
 
sschaem
Gerbil Team Leader
Posts: 282
Joined: Tue Oct 02, 2007 11:05 am

Re: Playstation 4

Mon Feb 25, 2013 4:50 pm

lilbuddhaman wrote:
If PS4 has a real-time OS, with a libGCM style low level access to the GPU, then the PS4 1st party games will be years ahead of the PC simply because it opens up what is possible on the GPU.


Anything that would be doable with the PS4 would be doable with the PC ... libgcm (from what I've read) is merely a low-level opengl implementation. As shown by Valve's work with linux/opengl ports of the Source engine, the benefits are reachable and there; they just need to be capitalized on. Also, low-level coding = harder...so don't expect most 3rd parties to jump on it.

I'm excited for PS4, not that I'm going to buy one, but for what it means for possible PC ports.


not everything... check what game developers have to say

The #1 issue with PC gaming is API overhead. Batching proved to be terrible on PC compared to consoles.
"On consoles, you can draw maybe 10,000 or 20,000 chunks of geometry in a frame, and you can do that at 30-60fps. On a PC, you can't typically draw more than 2-3,000 without getting into trouble with performance, and that's quite surprising - the PC can actually show you only a tenth of the performance if you need a separate batch for each draw call. "

http://www.bit-tech.net/hardware/graphi ... -directx/1


from http://timothylottes.blogspot.com/ shows you some of the stuff that AMD put in their GPU thats console only.

"Now lets dive into what isn't provided on PC but what can be found in AMD's GCN ISA docs,

Dual Asynchronous Compute Engines (ACE) :: Specifically "parallel operation with graphics and fast switching between task submissions" and "support of OCL 1.2 device partitioning". Sounds like at a minimum a developer can statically partition the device such that graphics can compute can run in parallel. For a PC, static partition would be horrible because of the different GPU configurations to support, but for a dedicated console, this is all you need. This opens up a much easier way to hide small compute jobs in a sea of GPU filling graphics work like post processing or shading. The way I do this on PC now is to abuse vertex shaders for full screen passes (the first triangle is full screen, and the rest are degenerates, use an uber-shader for the vertex shading looking at gl_VertexID and branching into "compute" work, being careful to space out the jobs by the SIMD width to avoid stalling the first triangle, or loading up one SIMD unit on the machine, ... like I said, complicated). In any case, this Dual ACE system likely makes it practical to port over a large amount of the Killzone SPU jobs to the GPU even if they don't completely fill the GPU (which would be a problem without complex uber-kernels on something like CUDA on the PC).

Dual High Performance DMA Engines :: Developers would get access to do async CPU->GPU or GPU->CPU memory transfers without stalling the graphics pipeline, and specifically ability to control semaphores in the push buffer(s) to insure no stalls and low latency scheduling. This is something the PC APIs get horribly wrong, as all memory copies are implicit without really giving control to the developer. This translates to much better resource streaming on a console.

Support for upto 6 Audio Streams :: HDMI supports audio, so the GPU actually outputs audio, but no PC driver gives you access. The GPU shader is in fact the ideal tool for audio processing, but on the PC you need to deal with the GPU->CPU latency wall (which can be worked around with pinned memory), but to add insult to injury the PC driver simply just copies that data back to the GPU for output adding more latency. In theory on something like a PS4 one could just mix audio on the GPU directly into the buffer being sent out on HDMI.

Global Data Store :: AMD has no way of exposing this in DX, and in OpenGL they only expose this in the ultra-limited form of counters which can only increment or decrement by one. The chip has 64KB of this memory, effectively with the same access as shared memory (atomics and everything) and lower latency than global atomics. This GDS unit can be used for all sorts of things, like workgroup to workgroup communication, global locks, or like doing an append or consume to an array of arrays where each thread can choose a different array, etc. To the metal access to GDS removes the overhead associated with managing huge data sets on the GPU. It is much easier to build GPU based hierarchical occlusion culling and scene management with access to these kind of low level features.

Re-used GPU State :: On a console with low level hardware access (like the PS3) one can pre-build and re-use command buffer chunks. On a modern GPU, one could even write or modify pre-built command buffer chunks from a shader. This removes the cost associated with drawing, pushing up the number of unique objects which can be drawn with different materials.

FP_DENORM Control Bit :: On the console one can turn off both DX's and GL's forced flush-to-denorm mode for 32-bit floating point in graphics. This enables easier ways to optimize shaders because integer limited shaders can use floating point pipes using denormals.

128-bit to 256-bit Resource Descriptors :: With GCN all that is needed to define a buffer's GPU state is to set 4 scalar registers to a resource descriptor, similar with texture (up to 8 scalar registers, plus another 4 for sampler). The scalar ALU on GCN supports block fetch of up to 16 scalars with a single instruction from either memory or from a buffer. It looks to be trivially easy on GCN to do bind-less buffers or textures for shader load/stores. Note this scalar unit has it's own data cache also. Changing textures or surfaces from inside the pixel shader looks to be easily possible. Note shaders still index resources using an instruction immediate, but the descriptor referenced by this immediate can be changed. This could help remove the traditional draw call based material limit.

S_SLEEP, S_SETPRIO, and GDS :: These provide all the tools necessary to do lock and lock-free retry loops on the GPU efficiently. DX11 specifically does not allow locks due to fear that some developer might TDR the system. With low level access, the S_SLEEP enables placing wavefront to sleep without busy spinning on the ALUs, and the S_SETPRIO enables reducing priority when checking for unlock between S_SLEEPs.

S_SENDMSG :: This enables a shader to force a CPU interrupt. In theory this can be used to signal to a real-time OS completion of some GPU operation to start up some CPU based tasks without needed the CPU to poll for completion. The other option would be maybe a interrupt signaled from a push buffer, but this wouldn't be able to signal from some intermediate point during a shader's execution. This on PS4 might enable tighter GPU and CPU task dependencies in a frame (or maybe even in a shader), compared to the latency wall which exists on non-real-time OS like Windows which usually forces CPU and GPU task dependencies to be a few frames apart.

Full Cache Flush Control :: DX has only implicit driver controlled cache flushes, it needs to be conservative, track all dependencies (high overhead), then assume conflict and always flush caches. On a console, the developer can easily skip cache flushes when they are not needed, leading to more parallel jobs and higher performance (overlap execution of things which on DX would be separated by a wait for machine to go idle).

GPU Assembly :: Maybe? I don't know if GCN has some hidden very complex rules for code generation and compiler scheduling. The ISA docs seem trivial to manage (manual insertion of barriers for texture fetch, etc). If Sony opens up GPU assembly, unlike the PS3, developers might easily crank out 30% extra from hand tuning shaders. The alternative is iterating on Cg, which is possible with real-time profiling tools. My experience on PC is micro-optimization of shaders yields some massive wins. For those like myself who love assembly of any arch, a fixed hardware spec is a dream.

...
"
 
derFunkenstein
Gerbil God
Posts: 25427
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Re: Playstation 4

Tue Feb 26, 2013 3:14 pm

Wall of text crits you for 32768 damage. You die.
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
Twittering away the day at @TVsBen
 
lilbuddhaman
Gerbil First Class
Posts: 140
Joined: Sat May 10, 2008 8:23 pm

Re: Playstation 4

Tue Feb 26, 2013 3:55 pm

Still kicking...barely. What needs to change for DX to support those missing functions, and why are they not supported? Seems like there would be good reason why both OpenGL and DX would ignore them, right?
I am jaded. I am cynical.
 
JohnC
Gerbil Jedi
Posts: 1924
Joined: Fri Jan 28, 2011 2:08 pm
Location: NY/NJ/FL

Re: Playstation 4

Tue Feb 26, 2013 3:59 pm

derFunkenstein wrote:
Wall of text crits you for 32768 damage. You die.

:lol:
Gifter of Nvidia Titans and countless Twitch donation extraordinaire, nothing makes me more happy in life than randomly helping random people
 
Captain Ned
Global Moderator
Posts: 28704
Joined: Wed Jan 16, 2002 7:00 pm
Location: Vermont, USA

Re: Playstation 4

Tue Feb 26, 2013 6:14 pm

derFunkenstein wrote:
Wall of text crits you for 32768 damage. You die.

Nah, I think he got dysentery.
What we have today is way too much pluribus and not enough unum.
 
mortifiedPenguin
Gerbil Elite
Posts: 812
Joined: Mon Oct 08, 2007 7:46 pm

Re: Playstation 4

Wed Feb 27, 2013 1:17 pm

Captain Ned wrote:
Nah, I think he got dysentery.
Character count indicates he may have been bitten by a snake 8107 times instead.

Now to contribute to the discussion... what do you guys think it will look like? Hardly the most important of details compared to what it can do but I think it might be a fun one to speculate upon.
2600K @ 4.8GHz; XSPC Rasa/RX240/RX120 Phobya Xtreme 200; Asus P8Z68-V Pro; 16GB Corsair Vengeance 1333 C9; 2x7970 OC w/ Razor 7970; Force GT 120GB; 3x F3 1TB; Corsair HX750; X-Fi Titanium; Corsair Obsidian 650D; Dell 2408WFP Rev. A01; 2x Dell U2412m
 
lilbuddhaman
Gerbil First Class
Posts: 140
Joined: Sat May 10, 2008 8:23 pm

Re: Playstation 4

Wed Feb 27, 2013 1:36 pm

I imagine even with low-power parts that it will run way hotter than they want, and therefore they'll have to make it a big PC-like box
I am jaded. I am cynical.
 
jihadjoe
Gerbil Elite
Posts: 835
Joined: Mon Dec 06, 2010 11:34 am

Re: Playstation 4

Wed Feb 27, 2013 1:49 pm

lilbuddhaman wrote:
Still kicking...barely. What needs to change for DX to support those missing functions, and why are they not supported? Seems like there would be good reason why both OpenGL and DX would ignore them, right?


Probably an agreement between everyone to buy exactly the same kind of GPU. =)

This console efficiencty talk (plus the Oregon Trail references) remind me of the good old DOS days when a lot of stuff was coded to metal, or at the very least assembly. Even learner's programming languages like BASIC allowed direct memory access using PEEK and POKE. We might not have had a lot of computing power, but by golly programmers were good and they made the most use of what was available.
 
mortifiedPenguin
Gerbil Elite
Posts: 812
Joined: Mon Oct 08, 2007 7:46 pm

Re: Playstation 4

Wed Feb 27, 2013 2:07 pm

lilbuddhaman wrote:
I imagine even with low-power parts that it will run way hotter than they want, and therefore they'll have to make it a big PC-like box
That's a good point. I doubt we'll see anything quite as big as an HTPC with a full ATX motherboard but my guess is that it'll be as big or bigger than the first gen PS3. Definitely larger than the current "slim" model.
2600K @ 4.8GHz; XSPC Rasa/RX240/RX120 Phobya Xtreme 200; Asus P8Z68-V Pro; 16GB Corsair Vengeance 1333 C9; 2x7970 OC w/ Razor 7970; Force GT 120GB; 3x F3 1TB; Corsair HX750; X-Fi Titanium; Corsair Obsidian 650D; Dell 2408WFP Rev. A01; 2x Dell U2412m
 
sschaem
Gerbil Team Leader
Posts: 282
Joined: Tue Oct 02, 2007 11:05 am

Re: Playstation 4

Wed Feb 27, 2013 2:35 pm

From the ps4 spec we have, it seem that it will require a smaller PSU then the original PS3. (ps3 was rated at 380 watt)

A 7850 is 130 max TDP (Thats for the whole board). The jaguar core alone are ridiculousness low.

It would be surprising is the PS4 is rated much above 180 watt
 
auxy
Graphmaster Gerbil
Posts: 1300
Joined: Sat Jan 19, 2013 4:25 pm
Location: the armpit of Texas

Re: Playstation 4

Wed Feb 27, 2013 5:12 pm

lilbuddhaman wrote:
I imagine even with low-power parts that it will run way hotter than they want, and therefore they'll have to make it a big PC-like box
... why?「(°ヘ°) "Even though you put new tires on it, one of them's still going to explode." (」゚ペ)」
mortifiedPenguin wrote:
That's a good point. I doubt we'll see anything quite as big as an HTPC with a full ATX motherboard but my guess is that it'll be as big or bigger than the first gen PS3. Definitely larger than the current "slim" model.
ヽ(´~`;)

I think it's probably going to be slightly larger than the Wii U. No reason to be larger. You can fit components more powerful than this (3960X and SLI 580M) in a machine 1/2 the size of the PS3 slim; no reason they can't fit this into something very small. ( ̄ェ ̄;)
 
JohnC
Gerbil Jedi
Posts: 1924
Joined: Fri Jan 28, 2011 2:08 pm
Location: NY/NJ/FL

Re: Playstation 4

Wed Feb 27, 2013 5:39 pm

If it'll run hotter than planned - they can always just make an extra hole in teh case and stick another large Delta fan into it :wink: Or "learn from the Best in industry" and re-design/improve the stock heatsink in a next model revision while making it easier and less expensive for people to return their overheated first-gen models for repair :wink: So yea, no real need to make an "original Xbox-huge" enclosure.
Gifter of Nvidia Titans and countless Twitch donation extraordinaire, nothing makes me more happy in life than randomly helping random people
 
auxy
Graphmaster Gerbil
Posts: 1300
Joined: Sat Jan 19, 2013 4:25 pm
Location: the armpit of Texas

Re: Playstation 4

Wed Feb 27, 2013 5:51 pm

JohnC wrote:
they can always just make an extra hole in the case and stick another large Delta fan into it :wink:
I lol'd! (*≧▽≦)ノシ)) Wait, that's deliberately obnoxious trolling! ヽ(゚Д゚)ノ :cockbean:

jihadjoe wrote:
This console efficiency talk (plus the Oregon Trail references) remind me of the good old DOS days when a lot of stuff was coded to metal, or at the very least assembly.
You know, I'm too young to remember these days, but I have a very keen understanding of the performance and scaling of microprocessors, and looking at what was done in those days -- you know, consider that Doom ran just fine on a 33Mhz 386 with 4Mbytes of RAM, and Quake was perfectly happy on a 75Mhz 486 with 8Mbytes ... I mean, that's just amazing considering how weak those processors are. ━Σ(゚Д゚|||)━

Compare them to something like Battlefield 3, which certainly is an order of magnitude more complex, and yet the hardware required to play it is four orders of magnitude more complex (4.2 billion transistors for an Ivy Bridge quad + GF100 chip vs. 275,000 in an 80386)... it's hard to think that we've really come all that far ... (ノдヽ)
On a tangentially related note, I've always wondered what you could do with something like the 80486 design die shrunk to, say, 22nm...

Who is online

Users browsing this forum: No registered users and 1 guest
GZIP: On