Xbox One (Durango) Technical hardware investigation

[DrJay24]

I hate to point out that it's exactly what he meant by double the resolution. 2x the pixels.

In my business, if you double the res or half the res, you are speaking about both vertical and horizontal resolutions independently. That is something entirely different than doubling the number of pixels, which could be done many many ways. Going from 720P to 1080P is not "doubling the resolution", it is just a different resolution that just happens to be near 2x.

But we are not sure what he meant, he was not explicit, we could just assume.

 

[Rurouni]

OT post
For me, double the resolution meant exactly that... double the ppi... Basically doubling both the v and h resolution is what I call double the resolution. 720p to 1080p is roughly double the pixel count. If I ask (in my job) for double the resolution from 720 and I get 1080 instead of 1440, I would be really annoyed.

 

[Silent_Buddha]

OT post
For me, double the resolution meant exactly that... double the ppi... Basically doubling both the v and h resolution is what I call double the resolution. 720p to 1080p is roughly double the pixel count. If I ask (in my job) for double the resolution from 720 and I get 1080 instead of 1440, I would be really annoyed.

Except 1440, assuming 2560x1440, is quadrupal the resolution. Why do you think 3840x2160 is considered Quad HD and not Double HD when it's only a doubling in each direction of 1920x1080. It certainly isn't 4x720p (5160x2880). After all going from 1920x1080 to 3840x2160 is 4 times the area, ergo 4 times the resolution.

While I'm sure some people think of it the way you do, I'd say it's just as common if not more so to think of it the other way.

Regards,
SB

 

[Rurouni]

The problem is that the ppi/dpi is not doubling. So when you expect 300ppi (from 150) and you've got 212, that's a big problem. You can't expect people to count in their head what's twice the pixel count.
Quad HD is exactly that.. 4x the pixel count of Full HD. 4x in the density of an area. The problem is that in my work, we don't talk density as an area, we talk as a length. That's why there's this dpi/ppi stuff.

Edit: I do understand that in this context, 720p to 1080p is doubling the resolution. I just gave my view on how doubling the resolution can mean something else. I would prefer to call it double the pixel count, but that just me.

 

[Laa-Yosh]

I hate to point out that it's exactly what he meant by double the resolution. 2x the pixels.

Thanks, also because I LOLd when reading your post

Edit: I'm also guilty of usually mixing the two concepts, ie. doubling the dimensions of an image (quadruples pixels) or doubling the number of pixels. That's because I'm a half art / half tech guy at my job, sorry if it's confusing people.

 

[Laa-Yosh]

Do you at all need to fit every render target into the ESRAM, but maybe some of them? Maybe render them to the ESRAM at a time, and move them to main memory - blending as you go, while the next render target is rendered? edit: The Data move engines could help with that, unlike Xbox360, gpu wouldn't be busy copying things to main ram.

Your speculation is probably right IMHO, that's exactly how it'd work on the X1. Keep what you're working on in that 32MB and shuffle the other buffers around accordingly.

Since the PS4 has only one memory pool, a render can win next to nothing by fitting its buffers into a small memory space, as long as the memory traffic is optimized. Maybe it can help to keep memory space low, but a 100 MBs here or there is not nearly as important as it was on the PS3.

 

[Gubbi]

Speaking of render targets, there was a slide in Shadow fall post mortem that talked about GPU memory allocations, and the render targets weighed at 800MB. That's more than current gen total ram, I don't know what to make of that number, can anybody explain why it would be so high? I'm guessing they keep and re-use quite a bit of rendered elements.

I'm guessing a zero snuck onto the end of 80. 5x RGBAf (4x16bit) rendertargets @1920x1080 is 80MB. That still seems like a lot. They are either doing something stupid (using wide formats where narrower ones could suffice) or they are doing something clever (ie. new). Skimmed the presentation, they seem to cast the final buffer to 32bit RGBf prior to post processing because of bandwidth/performance concerns.

The shadow buffers are 32bit because they are essentially depth buffers rendered from the lights' POV. The 2k x 2k resolution seems high and is probably because they can, ie. filling Z-buffers is something the PS4 is good at with 32 ROPs.

Cheers

 

[Grall]

edit: The Data move engines could help with that, unlike Xbox360, gpu wouldn't be busy copying things to main ram.

The "data move engines" is just a fancy name for a mechanism which has existed in computers basically since time immemorial, a DMA channel. GPUs have been able to DMA stuff independently of the other work that they do since forever.

 

[eVolvE]

Considering this http://www.phoronix.com/scan.php?page=news_item&px=MTI1MDE it sounds a lot like MS has just renamed another already available part of AMDs technology. What's described there sounds remarkably similar to what MS is calling their "data move engines". Sorry if this was already known to the wide audience, it is however news to me that this tech is widely available in Radeon cards since HD 2000 series. It seems I was really fooled by MS PR-talk

 

[Grall]

MS data move engines can do some bitmap format conversion stuff (scaling too, perhaps? I don't recall), and one of them at least also do some compression stuff also. That should not be present in AMDs DMA hardware. The fundamental moving of data from one place to another is not revolutionary though, or even moving while performing processing. The Commodore Amiga had DMA channels that did just that back in 1985.

 

[Betanumerical]

MS data move engines can do some bitmap format conversion stuff (scaling too, perhaps? I don't recall), and one of them at least also do some compression stuff also. That should not be present in AMDs DMA hardware. The fundamental moving of data from one place to another is not revolutionary though, or even moving while performing processing. The Commodore Amiga had DMA channels that did just that back in 1985.

They do JPEG decompression + LMZ decode, LMZ encode,last 2 only and all do tiling.

Doesn't seem that big a leap to see where they come from imo.

 

[scently]

They do JPEG decompression + LMZ decode, LMZ encode,last 2 only and all do tiling.

Doesn't seem that big a leap to see where they come from imo.

It doesn't need to be exceptional for it to be useful. They added more of the DMA units, increased the amount of bandwidth they can saturate and also added some functionality to them. It is necessary given the architecture and design decisions they have made.

 

[Gipsel]

They do JPEG decompression + LMZ decode, LMZ encode,last 2 only and all do tiling.

Tiling is also done by the normal DMA engines, they only added the compression/decompression. The two DMEs which can't de-/compress have exactly the same feature set as the DMA engines on current AMD GPUs.

 

[hesido]

@Gubbi : Thanks a lot for the insight.

The "data move engines" is just a fancy name for a mechanism which has existed in computers basically since time immemorial, a DMA channel. GPUs have been able to DMA stuff independently of the other work that they do since forever.

I thought that would be the case but when I was reading Humus's post about EDRAM, he says:

Each render target operation is immediately followed by a resolve operation copying the data to video memory. During this copying phase the GPU is busy just copying rather than rendering. If the rendering was targetting a video memory buffer to begin those writes to memory would be nicely interleaved with the rendering work that the GPU does and no resolve would be necessary, so once the rendering is done all that's needed is to flush whatever data is residing in the backend cache to memory and you're done.

But I'm guessing this may also be due to the fact that since EDRAM was so small, I guess you would have to finish your work and move stuff before you can start working on new stuff inside the EDRAM, but since Xbox One has 32MB, this may change, so the GPU wouldn't have to wait for its result to be transferred to main ram. Like you say, this wouldn't be because of the "data move engines" having new features but simply because there's more ESRAM (But not really much, actually)

 

[Scott_Arm]

Their data move engines are additional DMA on top of what is available in the GPU, no?

 

[dumbo11]

Their data move engines are additional DMA on top of what is available in the GPU, no?

AFAICT DME is a superset of GCN's DMA. If the GPU had an additional 2 DMA units, then it would logically have 6 DMEs?

http://www.vgleaks.com/world-exclusive-durangos-move-engines/

 

[Gipsel]

Their data move engines are additional DMA on top of what is available in the GPU, no?

AFAICT DME is a superset of GCN's DMA. If the GPU had an additional 2 DMA units, then it would logically have 6 DMEs?

http://www.vgleaks.com/world-exclusive-durangos-move-engines/

Two of the DMEs are the normal two DMA engines (just using a slightly different name) also available on Radeon GPUs. They added the two DMEs with the de-/compression capabilities (only these two support a superset of the standard DMA engine features).

In the following picture DME0 and DME1 are the normal ones, the additional DME2 und DME3 support further functionality.

 

[upnorthsox]

So how would you see that working? Would you be calling the move engines specifically that meet your requirements or would the jobs be identified in a pool be requirements and then selected by the ME that could meet them? Or something else entirely?

 

[expletive]

Two of the DMEs are the normal two DMA engines (just using a slightly different name) also available on Radeon GPUs. They added the two DMEs with the de-/compression capabilities (only these two support a superset of the standard DMA engine features).

In the following picture DME0 and DME1 are the normal ones, the additional DME2 und DME3 support further functionality.

So what do the XBO-specific DME's 'improve' or reduce the need for?

 

[onQ]

Two of the DMEs are the normal two DMA engines (just using a slightly different name) also available on Radeon GPUs. They added the two DMEs with the de-/compression capabilities (only these two support a superset of the standard DMA engine features).

In the following picture DME0 and DME1 are the normal ones, the additional DME2 und DME3 support further functionality.

So how would you see that working? Would you be calling the move engines specifically that meet your requirements or would the jobs be identified in a pool be requirements and then selected by the ME that could meet them? Or something else entirely?

So what do the XBO-specific DME's 'improve' or reduce the need for?

I have a feeling that the extra Move Engines are there for Kinect & the OS. (well the JPEG part anyway)