"The very existence of flame-throwers proves that some time, somewhere, someone said to themselves, You know, I want to set those people over there on fire, but I'm just not close enough to get the job done."
- George Carlin
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 108 109 110 111 112 113 114 115 116 117 118 ... 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 FailedJohn Burnett
Friday, May 22, 2009

Awesome - thanks for sharing! As a sidenote, while looking at the code, it seems like there's a copy/paste bug on line 91? ("const int h = img.getWidth();" should be "getHeight()"?)
Eric Haines
Friday, May 22, 2009

Very cool, thanks! As particles get smaller, the vertex shader eventually becomes more important. Trimming quads is always going to be a win (no extra vertices). Any sense of what the break-even size point is for, say, 8 vertices? It is likely to be slower than a quad if the particle covers very few pixels.

My guess is that particles have to be tiny to make 8 vertices perform worse, but you never know without actual testing... Even then, of course, GPUs vary; but it would still be nice to know, to have some stick in the sand. I hope you'll give it a try and let us know.
Overlord
Friday, May 22, 2009

So how does this stack up with using Discard in the fragment shader?
Jackis
Friday, May 22, 2009

We had been doing crop like this to make general quad with 4 corners (you call it - optimized 4 verts case), saving these 4 values in uniform buffer with texture data for particle system. There's a tool like you did, to calc convex hull and optimal quadliteral.
Then, GS used these values as UVs and as position offsets.
Such approach gave us about 15-20% speedup on high fillrate scenarios.
Micke
Wednesday, May 20, 2009

Actually 3dRealms did not close. They just cut staff. They still develop.
Humus
Sunday, May 17, 2009

Overlord, I wouldn't say that Tim Sweeney was right. He's been predicting that as CPUs became faster the GPU would become irrelevant. But the trend has always been that the GPU has become more and more relevant at the expense of the CPU and the performance gap has widened so much that at this point GPUs are orders of magnitude faster and are now competing for work that has traditionally been done on the CPU. Although I'm sure he takes the Larrabee as proof he was right all along, except that Larrabee is a GPU, although very CPU-like.

BKLA, well, Cell is pretty close to what I imagine future CPUs will be like. Except the SPUs all work in their own little world quite isolated from the rest of the system. In a sense it's a quite GPU-like approach, but I'm not sure it makes sense for CPUs.
A.
Saturday, May 16, 2009

Would you prefer a coherent memory shared by all cores or a more Cell-like model?
BKLA
Saturday, May 16, 2009

>>>"you'll probably see just a few standard cores optimized for highest performance of sequential code. <cut> Then you'll have a large array of simple CPU cores"

Yey! CELL processor is from the future!!!
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 108 109 110 111 112 113 114 115 116 117 118 ... 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