From my experience there is no real difference between desktop and laptop GPUs, only that they are slower.
However, since you are doing stuff with the multisampling buffer, maybe that part of the GPU is a bit different? Maybe Humus knows more about that.
Jan.
I don’t think I use the multisample buffer in any real way for this demo. Sure you can enable it via the F1 render menu but it should not really affect the output much. (Perhaps you are thinking of the Humus order independent transparency demo, or perhaps my paper where I discuss ways of handling MSAA - but I don’t implement these in the demo)
If you are using multisampling - perhaps toggling it off via the F1 menu - or check to see if you have it forced on via ATI control panel options? (perhaps even other options via the control panel are being set?
Erm, yes, i thought about those demos, i mixed that up…
Hm, i will check the options, but i just installed Catalyst 8.1 two days ago, it should have the default options set (i usually don’t change them, at all).
I tell you, if i find anything,
Jan.
I am very impressed but this technique. So many lights, so fast and looks so great!
These are my result on a Core 2 Quad at 2.4GHz with a 8800 GT:
640x480 => 450 FPS deferred / 90 FPS non-deferred
800x600 => 360 FPS deferred / 85 FPS non-deferred
1024x768 => 275 FPS deferred / 80 FPS non-deferred
nice one sqrt[-1], one thing though the scene is unrealistic ( unless youre modelling a swarm of fireflys ), typically in games lights are gonna have much larger radiuses
im assuming
A/ the larger the radius the worse this technique will perform + in fact for some senerios this method will be slower due to the extra perpixel shader work.
B/ the greater the chance for error (due to the per light num per pixel limit being exceeded)
is there a way to alter all lights radius at once?
from the lightpositions.h file
i assume the 40 is radius but changing it doesnt alter the lights radius
LightData(vec3(0.000000f,0.000000f,1.000000f), vec3(568.066345f,-247.719604f,174.817795f), 40.000000f),
Yes, the scene is unrealistic - a real scene has more than 5 render calls and typically more than 40,000 polygons. Hence in a real scene this technique would be even better. 
(Especially if you have 100’s of people with torches walking around on terrain)
A) The light radius have very little impact on per-pixel shader work - the only increase is the “invisible” light volume overdraw that is typical of shadow volume and other deferred rendering approaches.
B) While there is a greater chance of error with over draw - there are very few cases where a pixel is influenced by more than one or two lights in a game scene (excluding main ambient and directional lights) So with this technique you can say to your artists - place as many lights as you want, just don’t have more than 4 overlaps. (or less if you want more speed)
Also keep in mind that you can use this for PFX type lights (eg from sparks/plasma gun etc where the overlap count is not critical.
The lightpositions.h file contains all the light position for the static light scene (option via the F1 menu) If you change all the third parameters in this file (as you were doing) that will update the light volume sizes. You can also mess with light placement manually by pressing “E” for editor mode. See the readme.txt for info on this.
If you want to change the size in the moving light scene - see the file App_Utils.cpp in the PFX Spawn method.
Basically this technique came about because in a previous game I was working on, artists were creating huge buildings (10,000’s of polygons) and there might be small flickering street lights that hit the building. Even tho the scissor operation ensured that no extra fragment work was done - the vertex work was huge for each light.
If you change all the third parameters in this file (as you were doing)
this doesnt work for me, ie i change them from 38,39,40 to 338->340 (+ save) but they remain the same size
(edit) wait, i thought it was just a data file, im guessing i have to recompile, a few to many hoops. cheers anyways
every street light was dynamic?!
No, there were only a few problem areas where these lights were causing issues.
ok i see where youre coming from, its more useful for static lights. the stuff im doing 90% of the lights are dynamic (explosions/lazers), its not uncommon for pixels to be shaded by 10+ lights. i know ppl say pick the closest/brightest 4 lights after that u wont notice the difference. but from my testing the difference is easily noticable.
creating shadows for said lights is more of a bottleneck anyways 
ok cause i was so curious i did try out the demo, much less painless than i was expecting kudos to humus + sqrt[-1]
performance is ~7x better with the deferred technique (theres quite a few errors) but on the whole impressive, im not to sure i should do it though as shadow generation per light is more of a bottleneck than the actual light shading, but still nice to be aware of