I'd say a combination of the two would be the best way to do it. Use the eDRAM for tile cache and scene buffer storage, but don't intend on storing the entire scene each frame. Then have a separate unit that deals with merging calculated data with the external framebuffer.Ailuros said:one option was eDRAM and the other TBDR. Both sound equally unlikely at this stage.
R600 nugget...
- Thread starter Joe DeFuria
- Start date
Caching the framebuffer has the possibility to get really inefficient if there's little or no coherency in the location (or size) of the followup triangles in the rendering.
Optimizing for this screnario would be extremely hard -> developers won't do it -> the solution end up performing bad.
Tiling has a more predictable performance (especially on a unified shading architecture), and it requires minimum developer work.
Optimizing for this screnario would be extremely hard -> developers won't do it -> the solution end up performing bad.
Tiling has a more predictable performance (especially on a unified shading architecture), and it requires minimum developer work.
IF this would be true now we'd have a GPU+edram in ours PC.Chalnoth said:
I completely disagree, it would not be efficient as the hw will have to flush tiles from edram all the time, or you can capture all you data set or you quickly lose. You should also factor all the extra work the hw have to do in order to write tiles to edram and to external memory too, when it could write a tile just one time to external ram and forget it. Moreover you should alsdo consider all the die area edram eat and that could be devoted to other features.
If an IHV decide to sacrifice some ALUs or pixel pipelines to have some edram on board they will make sure ALL data will fit in their fast memory pool, this 's why R500 will render a tile at time and it's not using edram as a cache.
Chalnoth said:I'd say a combination of the two would be the best way to do it. Use the eDRAM for tile cache and scene buffer storage, but don't intend on storing the entire scene each frame. Then have a separate unit that deals with merging calculated data with the external framebuffer.Ailuros said:one option was eDRAM and the other TBDR. Both sound equally unlikely at this stage.
A modern TBDR wouldn't store the entire frame at a time.
No, because you still have the problem where you have to reduce the number of pipelines in the GPU to make room for the eDRAM. Then there's the added issue that you may not be able to clock the part as high. So this solution will only make sense if memory bandwidth becomes a really large burden.nAo said:
Jawed
Legend
It's looking pretty certain now that ATI's GPU + EDRAM architecture for R500 consists of 2 chips.
I dare say the key thing was to create an architecture for a GPU which enables this split, in order to free the GPU from otherwise being restricted, as you say, by on-die EDRAM.
ATI's patents on this architecture go back to 1998, with the current form determined in 2000. I dare say it's been a matter of waiting until such an architecture can meet the constraints of the PC gaming business, with the support for legacy games and coding techniques creating a sizable overhead in GPU resources.
We don't know what the die area for 10MB of high performance EDRAM is - we only know that low-power EDRAM would consume about 225mm squared at 90nm. (Bad memory alert: breakfast still settling, maybe it's 150mm squared, anyway whatever it is, it's a big package).
Looking forwards to a PC GPU with EDRAM, it would prolly need 32MB of RAM to cater for the high end PC resolutions. Either that or it would be forced to settle for rendering a frame in portions (I won't call them tiles, because we're talking about a half or quarter of the frame).
Jawed
I dare say the key thing was to create an architecture for a GPU which enables this split, in order to free the GPU from otherwise being restricted, as you say, by on-die EDRAM.
ATI's patents on this architecture go back to 1998, with the current form determined in 2000. I dare say it's been a matter of waiting until such an architecture can meet the constraints of the PC gaming business, with the support for legacy games and coding techniques creating a sizable overhead in GPU resources.
We don't know what the die area for 10MB of high performance EDRAM is - we only know that low-power EDRAM would consume about 225mm squared at 90nm. (Bad memory alert: breakfast still settling, maybe it's 150mm squared, anyway whatever it is, it's a big package).
Looking forwards to a PC GPU with EDRAM, it would prolly need 32MB of RAM to cater for the high end PC resolutions. Either that or it would be forced to settle for rendering a frame in portions (I won't call them tiles, because we're talking about a half or quarter of the frame).
Jawed
Martin Eddy
Regular
incurable said:
Definately 225 mm².
Jawed said:
You are right about that it's nothing like the (IIRC) 16x8 pixel tiles on PVR chips.
The reason you want as large tiles as possible is that you don't want to store the vertex shader results in RAM (due to both bandwith and memory constraints) - but this means that each "drawable" is transformed at worst (n+1) times - where n is the number of tiles that "drawable" touches.
Still you will see it called tiles - so the confusion is unavoidable.
(*) a drawable is a mesh or anything else drawn with a single draw call
madmartyau said:
Where did you get this 225 mm2 from ?
If you surf to NEC website:
http://www.necelam.com/edram90/index.php?Subject=Home
you can calculate:
0.22 um2 / bit * 1024 * 1024 * 10 * 8 => ~ 18 mm2, add the sense amps, row & column drivers etc.. for 10 MB
all in 90 nm technology....
Breakfast was more important this morning, lol.
Up to Series3 tile size on the PowerVR is 32*16 pixxels. Anything upwards from there splits the scene into macro tiles AFAIK and then into micro tiles again.
You can call it a macro tile IMHO.
***edit: Just for reference:
http://www.beyond3d.com/forum/viewtopic.php?p=8942&highlight=macro+tile#8942
Link
madshi said:
LCD+LED will arrive rather soon in much cheaper tv's then the Sony Qualia:
LG 42 LP1
Though this isn't the LCD+LED HDR display that Democoder was talking about (dripping wet ???
) but neither is the Qualia. You need this for the hdr part:http://www.cs.ubc.ca/~heidrich/Projects/HDRDisplay/
DevilsRejection
Newcomer
I made a thread about this in hardforum:
yes im killdfurby
http://www.hardforum.com/showthread.php?t=903400
ah i fucking love google news
look what I found:
http://www.digitimes.com/news/a20050418PR200.html
article dated April 19, 2005
yes im killdfurby
http://www.hardforum.com/showthread.php?t=903400
ah i fucking love google news
look what I found:
http://www.digitimes.com/news/a20050418PR200.html
article dated April 19, 2005
so, if XBox 360 supports 1920x1080i, but at the same time they say that every game designed for it should be designed to work at least 1280x720 (as 720p), how the scaler works to keep image quality as high as possible?
first thing that came to my mind was that they most likely output 1920x540 frames as interleaved. This would be achieved by downscaling from 720 to 540 and upscaling 1280 to 1920. This keeps output aspect ratio correct as the image has been originally rendered with square pixels. Also, it's known that human eye likes vertical lines and is less sensitive for color changes on those lines.
does this make any sense, or should I get me coat?
first thing that came to my mind was that they most likely output 1920x540 frames as interleaved. This would be achieved by downscaling from 720 to 540 and upscaling 1280 to 1920. This keeps output aspect ratio correct as the image has been originally rendered with square pixels. Also, it's known that human eye likes vertical lines and is less sensitive for color changes on those lines.
does this make any sense, or should I get me coat?
