SlickShoesRUCrazy
Member
rrod was caused by the change from regular solder to led free solder. that change was last minute.
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
VGLeaks: Durango GPU detailed
- Thread starter phosphor112
- Start date
rrod was caused by the change from regular solder to led free solder. that change was last minute.
Clay Davis
Member
thanks. sounds like a mistake they won't be / shouldn't be making again.
SlickShoesRUCrazy
Member
should be a more acceptable amount of defective units this time around.
Angelus Errare
Banned
If their goal is 2013 launch, you're not getting a different GPU. You might get clock speed updates, but people expecting completely new hardware at this point are...naive. Depending on yields they might increase some aspects or decrease them. But please don't go around thinking you're going to see a drastic change in GPU for Durango. It's just not going to happen.
And if PS4 does get 8GB of GDDR5 it wasn't a last minute thing on Sony's part and would have been something they considered way in advance. Going from 4GB -> 8GB isn't the same as going from 2GB->4GB. Getting 8GB would require a larger bit bus (8GB on 256bit? lulz), which means new memory controller, which means 'new' CPU design. If they're aiming for 2013 they either already had this planned or there won't be 8GB...my money is on the latter.
But it's hardware was finalized way before that. That's the important part of the discussion, when it entered production doesn't mean nearly as much and isn't proof of the notions people are throwing out.
Aren't you cherry picking now by restricting the comparison? Wy are resolution and textures at parity? They are capable of movement too. Eg if dynamic resolutions are used, PS4 might be running at 1920x1080/30 and Durango at 1440x1080/30. And vice versa,neuralgia might be able to easily utilise higher res textures or more variety of textures due to more memory
It's a tech speculation thread, what are we supposed to do? We haven't seen the controllers, games, OS, price. So we are playing with numbers while we wait.
Any speculation on potential performance is subject to change when the two companies show their wares.
If earlier Sony devkits had system ram and VRAM, I wonder if that means they have the architecture already in place to add some DDR3 ram back on to bring it more in line with Durango?
Didn't someone say that recent devkits have 8GB GDDRR5? So in theory, they already have a unit they could ship based on the devkit, they wouldn't need to re-engineer (but just take the cost hit)
Didn't someone say that recent devkits have 8GB GDDRR5? So in theory, they already have a unit they could ship based on the devkit, they wouldn't need to re-engineer (but just take the cost hit)
Beer Monkey
Member
I fully expect them to be a wash but if I'm wrong I'll be buying them both at launch as long as they are both backwards compatible.
I liked most of the discussion but these fan wars are getting tedious.
I liked most of the discussion but these fan wars are getting tedious.
googleplex
Member
Apparently it does. It's been stated that the alpha, beta and final kits are all pretty similar.
gollumsluvslave
Member
Until I hear something from a 3rd party technical authority I trust such as Tim Sweeney or John Carmack weigh on on the consoles (which won't happen until after E3 i'd imagine at earliest), then everything is just a bit of fun IMO, and I take everything with a massive pinch of salt.
Of course, it's always the launch lineup that will sway me or not to buy a new console Day 1, and that will be no different this time.
Show (not tell, or even leak!) me what I'm getting for my hard-earned green!
E3 is looking like a doozy this year!
The final sony machine will not have 8GB of GDDR5 if they want to launch this year, or even early next.
The earlier dev kits had separate ram because they were DESKTOP COMPUTERS
Target
systemfehler
Member
So I guess not much changed in the last year. I doubt MS had any troubles reaching that target - unless there have been "cost" constraints to reach a certain retail launch price or something.
I just wonder if MS is really in the last steps of launching a console 2013 shouldn't there be more information out like with the PS4. Surely a lot of developers must have updated devkits by now.
it wasnt really a mistake, it was forced due to new regs
I wasn't citing differences between consoles per say, I was citing differences in dev kits from early last year, to the end of last year. And why devs called the x3 'omg x3 is teh bestest ever' when the ps4 target implied a greater [possible] level than x3 on paper - had they reached their high end targets.
And btw they must be well into the latter stages of getting a 1000 small parts working nicely together. Bug testing the shit out of it, by now I reckon. It's one thing to have design wins on paper [well on computer simulations i guess], but then getting those to achieve that in the real world, on the factory floor, is a whole another matter. Floor plans, leakages, temperamental cores for the cpu side alone is hard enough without adding last hour delays from one of one hundred + suppliers into the mix. And this whilst rushing to market against a huge competitor must be terrifying.
I hope both achieve what they targeted to get out of these machines. We don't need another 'bulldozer' from AMD.
Heck maybe that's why devs said what they supposedly said earlier on. Microsoft dev kits had Intel Xeons replicating 8 cores, plus dsp simulations, whilst Sony had Amd APUs. When in reality they were targeting similar levels of processing power all along. I kid, I kid. (I don't think that came across last time I said something similar). Devs aren't that stupid.
Chuck Norris
Banned
People expecting drastic changes seem to be forgetting one thing - Durango is due to be unveiled in a number of weeks. It's too late for drastic changes. Everything will have been locked down for months in preparation
The Orbis unveil can't come quick enough. If it's impressive we can hope the Durango matches or exceeds it. If Durango does not at least those spec hungry folk will have Orbis to fall back on.
If the Orbis unveil is unimpressive... hmm. Things go crazy and depressed for those same spec hungry folk I guess unless Durango pulls it out the bag and is impressive spec-wise.
EDIT: I just realised that was a pointless post.
If the Orbis unveil is unimpressive... hmm. Things go crazy and depressed for those same spec hungry folk I guess unless Durango pulls it out the bag and is impressive spec-wise.
EDIT: I just realised that was a pointless post.
You should make of it nothing because that's exactly what it is, this far in the game they BETTER have a GPU picked or else its a very long wait till Durango.
It is incorrect.
The best summary of Durango GPU, well if you take the Vgleaks article as a given
http://www.extremetech.com/gaming/147577-xbox-720-gpu-detailed-merely-a-last-gen-radeon
Some really interesting points regarding the cache and bandwidth.
http://www.extremetech.com/gaming/147577-xbox-720-gpu-detailed-merely-a-last-gen-radeon
Some really interesting points regarding the cache and bandwidth.
brain_stew
Member
Who says people on this forum are using VG Leaks as their only source to verify these leaks?
Well do we have other sources of detailed leaks?
brain_stew
Member
Just to be exact, supposing you're referring to Lherre, he stated the (target) specs didn't change. The dev kits obviously have (for example from the dual Intel Xeon to the 8 core by AMD + audio dsp).
His post:
Maximilian E.
AKA MS-Evangelist
Not really
That sounds like they're mulling over different power supplies, not that the chip isn't final.
Makes me think MS has hardware mock ups with the power supply as both an external brick and as an in-box alternative, plus probably a few different implementations of each.
The original Xbox was in-box, the 360 has always been a power brick.
They also could be trying something different like an external PSU that plugs into the system and Kinect separately, which would suggest that Kinect 2 uses more power than what a single USB port can provide and MS didn't want to create a new powered port just to run pass through.
How MS powers the Xbox 720 will be really interesting. With all the heavily rumored DVR and media features it's going to need a pretty high level of "always on" functionality, but I'm sure MS doesn't want it to be sucking down a ton of juice 24/7.
iamshadowlark
Banned
Can't read, anything about the sauce?
Edit: Read it. So it is basically just an alternate path for data when the main ram is at capacity.
Edit 2: with Jpeg decoding
Up to you
Kill Your Masters
Member
Can you please post a summary or just paste a bit in quotes (at work, can't access it
)Here:Can you please post a summary or just paste a bit in quotes (at work, can't access it
World Exclusive: Durango’s Move Engines
Moore’s Law imposes a design challenge: How to make effective use of ever-increasing numbers of transistors without breaking the bank on power consumption? Simply packing in more instances of the same components is not always the answer. Often, a more productive approach is to move easily encapsulated, math-intensive operations into hardware.
The Durango GPU includes a number of fixed-function accelerators. Move engines are one of them.
Durango hardware has four move engines for fast direct memory access (DMA)
This accelerators are truly fixed-function, in the sense that their algorithms are embedded in hardware. They can usually be considered black boxes with no intermediate results that are visible to software. When used for their designed purpose, however, they can offload work from the rest of the system and obtain useful results at minimal cost.
The following figure shows the Durango move engines and their sub-components.
The four move engines all have a common baseline ability to move memory in any combination of the following ways:
From main RAM or from ESRAM
To main RAM or to ESRAM
From linear or tiled memory format
To linear or tiled memory format
From a sub-rectangle of a texture
To a sub-rectangle of a texture
From a sub-box of a 3D texture
To a sub-box of a 3D texture
The move engines can also be used to set an area of memory to a constant value.
DMA Performance
Each move engine can read and write 256 bits of data per GPU clock cycle, which equates to a peak throughput of 25.6 GB/s both ways. Raw copy operations, as well as most forms of tiling and untiling, can occur at the peak rate. The four move engines share a single memory path, yielding a total maximum throughput for all the move engines that is the same as for a single move engine. The move engines share their bandwidth with other components of the GPU, for instance, video encode and decode, the command processor, and the display output. These other clients are generally only capable of consuming a small fraction of the shared bandwidth.
The careful reader may deduce that raw performance of the move engines is less than could be achieved by a shader reading and writing the same data. Theoretical peak rates are displayed in the following table.
The advantage of the move engines lies in the fact that they can operate in parallel with computation. During times when the GPU is compute bound, move engine operations are effectively free. Even while the GPU is bandwidth bound, move engine operations may still be free if they use different pathways. For example, a move engine copy from RAM to RAM would not be impacted by a shader that only accesses ESRAM.
Generic lossless compression and decompression
One move engine out of the four supports generic lossless encoding and one move engine supports generic lossless decoding. These operations act as extensions on top of the standard DMA modes. For instance, a title may decode from main RAM directly into a sub-rectangle of a tiled texture in ESRAM.
The canonical use for the LZ decoder is decompression (or transcoding) of data loaded from off-chip from, for instance, the hard drive or the network. The canonical use for the LZ encoder is compression of data destined for off-chip. Conceivably, LZ compression might also be appropriate for data that will remain in RAM but may not be used again for many frames—for instance, low latency audio clips.
The codec employed by the move engines is LZ77, the 1977 version of the Lempel-Ziv (LZ) algorithm for lossless compression. This codec is the same one used in zlib, glib and other standard libraries. The specific standard that the encoder and decoder adhere to is known as RFC1951. In other words, the encoder generates a compliant bit stream according to this standard, and the decoder can decompress certain compliant bit streams, and in particular, any bit stream generated by the encoder.
LZ compression involves a sliding window and operates in blocks. The window represents the history available to pattern-match against. A block denotes a self-contained unit, which can be decoded independently of the rest of the stream. The window size and block size are parameters of the encoder. Larger window and block sizes imply better compression ratios, while smaller sizes require less calculation and working memory. The Durango hardware encoder and decoder can support block sizes up to 4 MB. The encoder uses a window size of 1 KB, and the decoder uses a window size of 4 KB. These facts impose a constraint on offline compressors. In order for the hardware decoder to interpret a compressed bit stream, that bit stream must have been created with a window size no larger than 4 KB and a block size no larger than 4 MB. When compression ratio is more important than performance, developers may instead choose to use a larger window size and decode in software.
The LZ decoder supports a raw throughput of 200 MB/s compressed data. The LZ encoder is designed to support a throughput of 150-200 MB/s for typical texture content. The actual throughput will vary depending on the nature of the data.
JPEG decoding
The same move engine that supports LZ decoding also supports JPEG decoding. Just as with LZ, JPEG decoding operates as an extension on top of the standard DMA modes. For instance, a title may decode from main RAM directly into a sub-rectangle of a tiled texture in ESRAM. The move engines contain no hardware JPEG encoder, only a decoder.
The JPEG codec used by the move engine is known as ISO/IEC 10918-1, which was the 1994 JPEG committee standard. The hardware decoder does not support later standards, such as JPEG 2000 (wavelet encoding) or the format known variously as JPEG XR, HD Photo, or Windows Media Photo, which added a number of extensions to the base algorithm. There is no native support for grayscale-only textures or for textures with alpha.
The move engine takes as input an entire JPEG stream, including the JFIF file header. It returns as output an 8-bit luma (Y or brightness) channel and two 8-bit subsampled chroma (CbCr or color) channels. The title must convert (if desired) from YCbCr to RGB using shader instructions.
The JPEG decoder supports both 4:2:2 and 4:2:0 subsampling of chroma. For illustration, see Figures 2 and 3. 4:2:2 subsampling means that each chroma channel is ½ the resolution of luma in the x direction, which implies a footprint of 2 bytes per texel. 4:2:0 subsampling means that each chroma channel is ½ the resolution of luma in both the x and y directions, which implies a footprint of 1.5 bytes per texel. The subsampling mode is a property of the compressed image, specified at encoding time.
In the case of 4:2:2 subsampling, the luma and chroma channels are interleaved. The GPU supports special texture formats (DXGI_FORMAT_G8R8_G8B8_UNORM) and tiling modes to allow all three channels to be fetched using a single instruction, even though they are of different resolutions.
JPEG decoder output, 4:2:2 subsampled, with chroma interleaved.
In the case of 4:2:0 subsampling, the luma and chroma channels are stored separately. Two fetches are required to read a decoded pixel—one for the luma channel and another (with different texture coordinates) for the chroma channels.
JPEG decoder output, 4:2:0 subsampled, with chroma stored separately.
Throughput of JPEG decoding is naturally much less than throughput of raw data. The following table shows examples of processing loads that approach peak theoretical throughput for each subsampling mode.
Peak theoretical rates for JPEG decoding.
System and title usage
Move engines 1, 2 and 3 are for the exclusive use of the running title.
Move engine 0 is shared between the title and the system. During the system’s GPU time slice, the system uses move engine 0. During the title’s GPU time slice, move engine 0 can be used by title code. It may also be used by Direct3D to assist in carrying out title commands. For instance, to complete a Map operation on a surface in ESRAM, Direct3D will use move engine 0 to move that surface to main memory.
iamshadowlark
Banned
Can you please post a summary or just paste a bit in quotes (at work, can't access it
They are fixed function DMA units. Four of them total with 3 fully dedicated to the application(game) and one shared between the system and app. Max throughput of 25.6GBs and can be used in parallel. Where it gets weird is the comment about how all four combine for the max throughput of one.
Stealth: Beaten
Kill Your Masters
Member
Thanks. So it gets more complicated? Wizard jizz? Is MS pulling some kind of PS3 in terms of complexity?
no, because MS will have full documentation/debug/software for devs, and its still dx based, sony had jack shit for a long time lol
Another one bites the dust, I wonder at this pace how many ILs he'll (Can Crusher) end up on ..
Going off-topic slightly, but I couldn't believe when Marcus Beer said that while he was working at a publisher they got the PS3 dev kits with the instructions but they were in Japanese and when contacted Sony basically told them to fuck off and translate it your selves. It astonishes me how much hubris Sony displayed early this gen, and it's fortunate they have learned from that..
Can Crusher
Banned
I didn't say it was explicit, I said it was obvious what it was being implied.
Also yes, he will be wrong because he says that old Durango info is making new Orbis info look better. When in fact, if nothing has changed there is no old info vs new info. There's just target vs target, and so info age doesn't factor.
But I agree with you, he can and probably is trolling, I've said as much before. But he is implying what he's implying and he's saying what he is saying.
Thank you for apologizing, I think neither of us is really looking to offend one another.
Man once again you are just twisting reality. You are just making yourself look like a terrible poster, keep doing it if you like it.
iceatcs
Junior Member
Likely false talk only coming out the dark hole.
It went to wrong direction on the documentation because IBM made most of them, not ideal for game developers.
And who says all sources are reliable, especially since usually it is one fake source that it all starts with and is referenced by all the other sources
Wanna bet? ;-)
Similar threads
- Poll