"The radical right wants everyone to be treated equally. The radical left want everyone to be treated until they become equal."
- Fredrik Y. Törn (m)
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 133 134 135 136 137 138 139 140 141 142 143 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 381 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438
Query FailedHumus
Monday, May 31, 2010

Filip: Well, even with big particles the main bottleneck is going to be ROPs anyway, so spend those transistors on a few more ROPs instead please.

Dan: I don't know about main RAM, I would have to double check, but you can do arbitrary writes to video memory at least. We used that feature in JC2 for a depth buffer conversion pass to trade performance for memory. It was very tricky to transform from one swizzled surface format to another differently swizzled one and keep both reads and writes fairly linear in memory. If you don't do that, performance drops to nearly a halt. It took me a week to get it working, but in the end I was ended up very close to theorethical max bandwidth.
jon w
Monday, May 31, 2010

720p? 540p with 2xAA for the win!
(Yeah, I'm looking at you, Gears...)
Dan
Monday, May 31, 2010

I heard the 360 had certain shader instructions to write stuff directly to main RAM. Is that true? Couldn't it be abused for this purpose?
valoh
Sunday, May 30, 2010

Imo the main design fail is that the EDRAM is GPU write only. Imagine you could directly sample from EDRAM, then the design would really shine or at least would make you forget the tiling pain. Do the image processing completely in EDRAM without touching the main bus and use it as large texture cache for texture heavy batches. Ok, and you would want hw resolves independent of the GPU, so that you can resolve and render in parallel.
Filip
Sunday, May 30, 2010

Oh you're so right.. the pain of "tiling", render-resolve logic and other stuff. I've been saying for years now that EDRAM is pain in the ass and a bad idea, but people usually don't agree.
The only good thing is the fill rate with big particles and similar stuff, but I'd still prefer writing to main RAM directly (and have some more shader transistors instead of EDRAM).

But who could predict that the deferred rendering was going to become mainstream?
vince
Saturday, May 29, 2010

EDRAM truly is a pain - certainly my least favorite thing about the 360 (the relatively small amount of L2 for 3 cores might be #2).

One option is just not to do MSAA and do anti aliasing in a post process. If you're using floating point render targets for any given stage this may be the better option on the PS3 and D3D9 anyway (for those of us still stuck supporting D3D9).

If you go this route a lot of other things become simpler -- for example you can do a depth prepass, keep a full depth buffer in EDRAM at all times, but do tiling for just your color targets, which can be useful if you need MRTs for a g-buffer, for example.
fmoreira
Saturday, May 22, 2010

probably the most famous sprite ever made xD
Josh -yosh64
Saturday, May 22, 2010

Reavenk has beat me to it, I was actually up very late into the morning last night (I'm from Australia) when I logged onto Google and to my surprise there was Pacman. Played a few games and was quite fun, was actually wondering what it was all about and now I know .
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 133 134 135 136 137 138 139 140 141 142 143 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 381 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438