"The cheese in the rat trap is always free."
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 56 57 58 59 60 61 62 63 64 65 66 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 365
Query Failedsqrt[-1]
Tuesday, July 6, 2010

I just read your article, thanks for the light indexed deferred rendering link.

I was a bit confused about what you were saying where if looking down a row of street lights that lots of the lights would occupy the same screen area.

I can understand this if you have to light translucent objects, but opaque objects would not be an issue.

Or perhaps you do not do a depth pre-pass? (or did not want to)

Was that the case?
Overlord
Wednesday, June 30, 2010

re kyle:
not even close, the itanium doesn't have a multicore architecture (besides those with 2-4 cores) what it does have is multiple sub cores that can do like 3 or so instructions at once, but it can't use them in paralell.
In essence they tried to make the itanium faster by making it to execute large groups of instructions at once, something the newest intel processors solved in a simpler way by combining multiple instructions into a single instruction that is not part of the x86 set.
Either way this makes the itanium large and complicated, perhaps its good for some things, but for most it's better to keep it simple, i bet you can fit like 50 vector cores on the same space as a single itanium core and that has to count for something.
kyle
Wednesday, June 30, 2010

re Overlord:
Something like Itanium?
Imo, we are stuck with x86 forever ...
kyle
Wednesday, June 30, 2010

re Overlord:
Something like Itanium?
Imo, we are stuck with x86 forever ...
sqrt[-1]
Wednesday, June 30, 2010

Just bring on a huge grid of memristors and each application can configure the chip hardware how it wants!

(I actually have no idea - just was amazed at some of the predictions in http://www.youtube.com/watch?v=bKGhvKyjgLY "Finding the Missing Memristor"
Humus
Sunday, June 27, 2010

The obvious downside of that is that it comes with some overhead because in a well written class that initializes everything itself the memory will be written twice at every creation. Also, as you mentioned, it doesn't cover the stack-allocated case, although this problem is more common on big classes who normally are not allocated on the stack. However, the very weak spot of this is reuse of already allocated memory from pool, and in-place creation, which are common things in games for performance reasons.
idinev
Sunday, June 27, 2010

Override new/delete

extern void * _cdecl operator new (size_t size);
extern void * operator new[] (size_t size);
extern void _cdecl operator delete (void * ptr);
extern void operator delete[] (void * ptr);

Zero-initialize in 'new', with a fast memfill func ("rep stosd" may suffice), that's before setting-up the vTable ptr.

Only problematic area will remain the stack-allocated classes.
Overlord
Friday, June 25, 2010

Personally i think the faster x86 CPUs get a few vector processors for each core the better, but then again the reason we still don't have that setup is because of x86.
I would much rather see them invent a new type of processor, one with multiple types of processor cores, like a few general purpose cores, a bunch of vector cores and a lot of SPPUs(Single purpose processing units, really tiny cores that can only do a few things).

And when it comes to flops/watt, if done right such a processor if you only used whats needed would fit the mobile market pretty good as you could often just use a smaller core for the same job
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 56 57 58 59 60 61 62 63 64 65 66 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 365